Google, Microsoft, Yahoo Join Forces To Create New Encrypted Email Protocol

An anonymous reader writes: A group of independent security researchers and major Silicon Valley tech giants have submitted a proposal for a new email protocol called SMTP STS (Strict Transport Security). In theory, this new extension looks like the HSTS (HTTP Strict Transport Security) extension to HTTPS. Much like HSTS, SMTP STS brings message confidentiality and server authenticity to the process of starting an encrypted email communications channel. HSTS works alongside HTTPS to avoid SSL/TLS downgrades and MitM attacks. to avoid SSL/TLS downgrades and MitM attacks. The biggest names on the contributors list include Microsoft, Google, Yahoo, LinkedIn, and Comcast. Last year, Oracle also submitted a similar proposal called DEEP (Deployable Enhanced Email Privacy).

Comments

"Transport" != "end-to-end"

[QuietLagoon]

The emails are still in plain text inside the email servers en route, unless the email sender and recipient use end-to-end encryption.

Re:"Transport" != "end-to-end"

[fph il quozientatore]

The emails are still in plain text inside the email servers en route, unless the email sender and recipient use end-to-end encryption.

This. We need one-click client-side e-mail encryption, usable by everyone. Like PGP but without the key management complications and the scary mojibake added to the e-mail body.

Re:Storage

[Junta]

The storage of content and transmission of content are separate concerns. A standard protocol to cover transmission of messages should not be concerned with the storage of it.

Don't blame email!

[s.petry]

I get really tired of this, because it's completely backward and wrong. Email is fine, and it does exactly what it was intended to do. Route messages from source to destination. People like you want email to be something different, but always arbitrary because there is no solution which works to encrypt out of the box which can not be tampered with. You want secure, that's fine but don't make an insecure protocol for mail routing the answer.

Use email for email. Attach encrypted files using what ever format you want, and you have control of the encryption. Stop demanding that generic "email" does it all for you, because if you trust any of the companies listed in TFA to give you bullet proof security, you are a tool.

Re:Don't blame email!

[Dutch Gun]

The current e-mail protocols were designed at a time when everybody on the internet was expected to play nice. It could use an upgrade for today's significantly more hostile environment. There's really no reason we shouldn't have an upgraded protocol with more security and better authentication built in.

Nothing against the brilliant minds that created some of these early protocols, but they simply couldn't foresee some of the modern security and privacy issues the current internet has to deal with. We've also learned a thing or two about encryption and secure protocols in the last few decades, and upgraded protocols accordingly, right? I think it's a good time to try to introduce an upgraded e-mail standard. Whether it takes hold or not is a question, but with some of the big names apparently behind it, I don't see why not.

BTW, if you're going to reject out of hand a proposal for a new standard because of the names of the companies involved, then you're not thinking things through clearly. This would be an open standard, meaning it's possible for security specialists to vet and declare the protocol safe and secure, just like we do with TLS and other modern protocols. It seems like it would be rather tricky to hide secret backdoors in an open standard.

Re:Don't blame email!

[Dutch Gun]

You don't like SMTP don't use it! Go make your own protocol

/facepalm. That's what we're discussing here.

Re:Storage

[MobileTatsu-NJG]

Yeah, I was going to say: If Google actually did do their job correctly they wouldn't be able to monetize GMail.

Re: Storage

[Z00L00K]

Encryption of messages is not prevented by this technology, it's two completely different uses.
  - SMTP STS is used for validating the server channel to prevent spoofed servers. It doesn't care about the message content.
  - Encrypted messages already exists and encrypts the message body, but that will require that both sender and receiver have exchanged some information. However these messages don't care about the channel used.

For best result you need both.

But I also see problems here:
  - the SMTP STS requires certificates provided by a Certificate Authority (CA), and lately it has been revealed that not every CA is especially good at handling this.
  - It will also require a good implementation of revocation of certificates.
  - The management of the certificates may be costly, both the certificate and the management of it.

Overall it will drive cost, and that may be what kills this idea.

PGP, since 1991. key servers. If people cared

[raymorris]

> How do you send email to random people encrypted?
> Your solutions work for internal email, but not external.

This problem was solved in 1991, in terms of the technical implementation and protocol. The "problem" is that few people care about receiving encrypted email, so they don't publish a key to use for sending them email. Maybe if email clients made it super-easy more people would do it.

Here's a brief description of how PGP/GPG works. Wherever I publish my email address, I also publish my public key, which I generated. To send me an email, you can either use my address and my public key, or you can let your email client retrieve the key for you, from a key server. Since the email is encrypted with my public key, it can only be decrypted by my private key.

Personally, I publish my public key on the "Contact Us" page of my web site and on the public key servers.

The protocol works fine. The problems are that email clients don't make it super-easy for you to generate and publish a key, or to send PGP email using the recipient's key. That's a UI problem, not a protocol problem.