3 ms·

> It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to

> It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear. SMTP has the exact same mechanisms, as does IMAP. HTTPS does not protect data at rest, and it doesn't protect data from the service provider, it never promised to. There is functionally no difference between the SMTP/IMAP and HTTPS security models.

tptacek 9y ago
You're confusing client-server secure transport with secure messaging, which is not at all the same thing. Yes: you can ensure a specific SMTP (or IMAP) client connection is encrypted with TLS. But email is store-and-forward. What you can't do is ensure that a given message is encrypted at every hop, let alone end-to-end, where only the sender and receiver can read it. Obviously, that's the point of layering OpenPGP on top of email. But, like I said: that's opt-in, with plaintext as a default. We would never accept that design in a secure messenger system.
tonyarkles 9y ago
I disagree, while also agreeing that IMAPS/SMTP-with-TLS is a huge improvement. The big difference between HTTPS and SMTP is that there's an implicit extra hop. I go to send you an email. I connect to my outgoing mail server over SMTP-with-TLS, and anyone monitoring my connection cannot see the content of the message. Awesome! Likewise, you retrieve the message using IMAPS, and anyone monitoring your connect cannot see the content. Great! But in between, there's absolutely no guarantee that my email provider sent it to your email provider over SMTP-with-TLS. It could very well have traveled completely cleartext, at which point it was harvested and archived by the NSA, with neither of our email providers having handed it over to them.
- microcolonel 9y ago
  > But in between, there's absolutely no guarantee that my email provider sent it to your email provider over SMTP-with-TLS. Don't accept non-STARTTLS traffic. Google doesn't, you shouldn't have to either. STARTTLS is widely available, and simply needs to be configured. Encouraging everyone to configure STARTTLS correctly is the easiest win we'll have. And I hope you don't take what I said to mean that IMAPS and SMTP over TLS are a proper message encryption system. I simply meant that HTTPS doesn't do anything right that IMAPS or SMTP over TLS don't also. Clearly there needs to be a standard way of advertising, distributing, transitioning, and retiring keys for email addresses. It needs to be robust, in continuity with existing infrastructure (probably domainkeys signed), straightforward (maybe signed proof of sender keys in a header), and possible to delegate in a way which meets the requirements of mailing lists. It also needs to be robust against malicious MTAs who could otherwise silently spoof senders and misrepresent their keys (double signing?). A system with these properties would also solve the problematic interactions between DMARC and mailing lists which prevent almost everyone from deploying an appropriate DMARC policy today. If somebody is working on this I'd like to know about it.
  - tonyarkles 9y ago
    Google won't accept inbound mail (from an MTA, not an MUA) that doesn't do STARTTLS? If that's true, I'm both impressed (at their resolve to make the Internet a better place), and concerned that messages from old ISPs that haven't upgraded in a decade won't ever reach my GMail account.
    - jlgaddis 9y ago
      Google does accept it. To do otherwise would violate the RFCs. They won't accept an e-mail from a user ("submission") without STARTTLS, however. An MUA must negotiate the encrypted channel before even being allowed to authenticate. AFAIK, this is pretty much a universal requirement on the {IMAP4,POP3}-over-TLS ports (993,995/TCP) -- it definitely is on the mail servers I run.
      - tonyarkles 9y ago
        Right, but that was my entire point. Just because both users/MUAs are using STARTTLS has no bearing on whether the message is sent in the clear across the internet from MTA to MTA. That's where STARTTLS is worse than HTTPS. With an HTTPS request, there's a pretty good chance that the messages are getting from source-to-destination without ever traversing the Internet in cleartext (modulo MitM with forged certificates)
        jlgaddis 9y ago
        Sorry, you misinterpreted my reply. I agree with you completely. I replied mostly to point out that microcolonel's statement that > Don't accept non-STARTTLS traffic. Google doesn't, ... is incorrect -- as you doubted: > If that's true, I'm both impressed ...
        tonyarkles 9y ago
        Oh! Apologies, didn't notice that you weren't the parent. Cheers :)

tptacek 9y ago

You're confusing client-server secure transport with secure messaging, which is not at all the same thing. Yes: you can ensure a specific SMTP (or IMAP) client connection is encrypted with TLS. But email is store-and-forward. What you can't do is ensure that a given message is encrypted at every hop, let alone end-to-end, where only the sender and receiver can read it. Obviously, that's the point of layering OpenPGP on top of email. But, like I said: that's opt-in, with plaintext as a default. We would never accept that design in a secure messenger system.

tonyarkles 9y ago

I disagree, while also agreeing that IMAPS/SMTP-with-TLS is a huge improvement. The big difference between HTTPS and SMTP is that there's an implicit extra hop. I go to send you an email. I connect to my outgoing mail server over SMTP-with-TLS, and anyone monitoring my connection cannot see the content of the message. Awesome! Likewise, you retrieve the message using IMAPS, and anyone monitoring your connect cannot see the content. Great! But in between, there's absolutely no guarantee that my email provider sent it to your email provider over SMTP-with-TLS. It could very well have traveled completely cleartext, at which point it was harvested and archived by the NSA, with neither of our email providers having handed it over to them.

microcolonel 9y ago
> But in between, there's absolutely no guarantee that my email provider sent it to your email provider over SMTP-with-TLS. Don't accept non-STARTTLS traffic. Google doesn't, you shouldn't have to either. STARTTLS is widely available, and simply needs to be configured. Encouraging everyone to configure STARTTLS correctly is the easiest win we'll have. And I hope you don't take what I said to mean that IMAPS and SMTP over TLS are a proper message encryption system. I simply meant that HTTPS doesn't do anything right that IMAPS or SMTP over TLS don't also. Clearly there needs to be a standard way of advertising, distributing, transitioning, and retiring keys for email addresses. It needs to be robust, in continuity with existing infrastructure (probably domainkeys signed), straightforward (maybe signed proof of sender keys in a header), and possible to delegate in a way which meets the requirements of mailing lists. It also needs to be robust against malicious MTAs who could otherwise silently spoof senders and misrepresent their keys (double signing?). A system with these properties would also solve the problematic interactions between DMARC and mailing lists which prevent almost everyone from deploying an appropriate DMARC policy today. If somebody is working on this I'd like to know about it.
- tonyarkles 9y ago
  Google won't accept inbound mail (from an MTA, not an MUA) that doesn't do STARTTLS? If that's true, I'm both impressed (at their resolve to make the Internet a better place), and concerned that messages from old ISPs that haven't upgraded in a decade won't ever reach my GMail account.
  - jlgaddis 9y ago
    Google does accept it. To do otherwise would violate the RFCs. They won't accept an e-mail from a user ("submission") without STARTTLS, however. An MUA must negotiate the encrypted channel before even being allowed to authenticate. AFAIK, this is pretty much a universal requirement on the {IMAP4,POP3}-over-TLS ports (993,995/TCP) -- it definitely is on the mail servers I run.
    - tonyarkles 9y ago
      Right, but that was my entire point. Just because both users/MUAs are using STARTTLS has no bearing on whether the message is sent in the clear across the internet from MTA to MTA. That's where STARTTLS is worse than HTTPS. With an HTTPS request, there's a pretty good chance that the messages are getting from source-to-destination without ever traversing the Internet in cleartext (modulo MitM with forged certificates)
      - jlgaddis 9y ago
        Sorry, you misinterpreted my reply. I agree with you completely. I replied mostly to point out that microcolonel's statement that > Don't accept non-STARTTLS traffic. Google doesn't, ... is incorrect -- as you doubted: > If that's true, I'm both impressed ...
        tonyarkles 9y ago
        Oh! Apologies, didn't notice that you weren't the parent. Cheers :)