3 ms·

> but email doesn't even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear. There is a draft standard [1] for str

by u801e 9y ago

> but email doesn't even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear. There is a draft standard [1] for strict transport security. I'm not sure of its current status though. > Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simply content. They're sent in plaintext. Nothing sent during the data phase of the SMTP transaction has to strictly be unencrypted. There's nothing preventing the client from encrypting both the headers and body of the message. But that doesn't prevent the MTA itself from adding uncrypted headers to the message after the client sends the CRLF.CRLF sequence to end the data phase. > Most email users get their email from a website. Unless you make them install something on all their computers I'm not sure how many users still use a dedicated email client, but I'm sure that there are many who use clients like Outlook, Apple Mail, Thunderbird, amongst others. Anyone who wants to encrypt their email needs to know they need to use a client on their machine that handles the encryption/decryption steps for them (or that they need to do it themselves. [1] https://www.infoworld.com/article/3046850/security/google-microsoft-yahoo-and-others-publish-new-email-security-standard.html https://www.infoworld.com/article/3046850/security/google-mi...

tptacek 9y ago
That's strict transport security between hops. There's no proposal on the table for end-to-end encryption, or even (so far as I know) for a header that would signal that a message be dropped before it's sent over an unencrypted channel --- right now, servers simply agree between themselves to enforce transport security, with no input from messages.
- e12e 9y ago
  Realistically, how many hops are we talking? The dns mx record points to a server that handles mail for a user - anything beyond that point is that domains problem to secure - and it's relatively easy to do so. (The exception being aliased/forwarded addresses - but that's handled on the server side - and could also be set to force ssl/tls). The sender needs a smtp server, usually "their own", and usually (today) supports tls/ssl. Now the sender_smtp-receiver_smtp needs to enforce encryption. I really think we're at a point where forcing ssl on incoming mail would a) not lose any legitimate email, b) maybe block some spam. Then, remove support for connecting to mail over unencrypted pop/imap/smtp for mail clients (probably except for localcast, to not break "known secure transport" like an ssh/vpn tunnel). Since Gmail, outlook.com have effectively broken easy mail federation (oh, look a bad man had your ip a year ago, no mail for you, and no, we won't bounce it with an error, just silently drop it/file it as spam) - we have an oppsto be a bit aggressive in phasing out old rfcs that allow unencrypted smtp/imap/pop over untrusted networks. I'll happily concede that patching transport security doesn't make email end-to-end secure. Then again, I'm not sure the Web is any better: ssl is hop-by-hop, clients keep a plain text cache on disk, along with a log of meta-data (and servers tend to log a lot of plain text meta-data too), client certificates are being phased out for http2... Wrapping messages in s/mime or gpg actually looks pretty good by comparison. Maybe what we need is a suggestion that if you email user+secure@example.com rather than user@ - only email encrypted to User@example.com (with user+secure@ as alt identity...) will get through? Then muas could check to see if there's a gpg key for user+secure@, given mailto user@, in the directory - and transparently Encrypt by default?
  - tptacek 9y ago
    It doesn't make sense to talk about whether HTTPS is end-to-end encrypted. Sometimes it is, sometimes it isn't. If you're exchange secrets directly with a web application that doesn't leave the application's secured deployment environment, TLS is all you need. But if you're exchanging secrets with another person using a server as a mediator --- as is the case with web chat and web email systems --- then it's not. I don't know why we'd bother with fussy contraptions involving special email addresses that nobody knows about, let alone uses. We have secure messaging systems today, systems billions of people already use, they're designed from the ground up to handle these problems, and so they're much better at security than any email system we can even reasonably come up with might be. Why are we wasting time trying to make people feel safer emailing secrets? We should get them to stop doing that at all.
    - e12e 9y ago
      It's my understanding that most of these secure messaging system relay via servers speaking https - and their distinctive feature is that the clients are distributed as self-contained apps, that wrap the complexity, and label "signal-protocol over https rpc" as just "signal" (similar for WhatsApp etc). Why is it hopeless to do the same for email? Take a sane protocol subset, add a convention protocol for encryption, and ship it as "secure email"? It is a tautology that a "secure mail app" that allows "traditional email interop" cannot make strong privacy guarantees, just like when using WhatsApp you give up federation and networking-as-a-utility (you're completely beholden to a provider that you don't even have a proper contract with, let alone the opportunity to seamlessly move providers / self-host / federate while maintaining global addressing and data portability). I think that's part of the disconnect in the discussion - wrapping a sane protocol selection in an opaque app along with a saas/paas silo that limits addressing, routing and federation is OK for some arbitrary subset of not-by-themselves secure protocols, but any suggestion that reusing elements of email is dismissed as "can't be done" (or "can't be done, because webmail", while "can't be done because messenger.com" seems absent). We've already done meta-data wrapping for email, with one, perhaps flawed approach: https://en.m.wikipedia.org/wiki/Mixmaster_anonymous_remailer https://en.m.wikipedia.org/wiki/Mixmaster_anonymous_remailer

by u801e 9y ago

tptacek 9y ago

That's strict transport security between hops. There's no proposal on the table for end-to-end encryption, or even (so far as I know) for a header that would signal that a message be dropped before it's sent over an unencrypted channel --- right now, servers simply agree between themselves to enforce transport security, with no input from messages.

e12e 9y ago
Realistically, how many hops are we talking? The dns mx record points to a server that handles mail for a user - anything beyond that point is that domains problem to secure - and it's relatively easy to do so. (The exception being aliased/forwarded addresses - but that's handled on the server side - and could also be set to force ssl/tls). The sender needs a smtp server, usually "their own", and usually (today) supports tls/ssl. Now the sender_smtp-receiver_smtp needs to enforce encryption. I really think we're at a point where forcing ssl on incoming mail would a) not lose any legitimate email, b) maybe block some spam. Then, remove support for connecting to mail over unencrypted pop/imap/smtp for mail clients (probably except for localcast, to not break "known secure transport" like an ssh/vpn tunnel). Since Gmail, outlook.com have effectively broken easy mail federation (oh, look a bad man had your ip a year ago, no mail for you, and no, we won't bounce it with an error, just silently drop it/file it as spam) - we have an oppsto be a bit aggressive in phasing out old rfcs that allow unencrypted smtp/imap/pop over untrusted networks. I'll happily concede that patching transport security doesn't make email end-to-end secure. Then again, I'm not sure the Web is any better: ssl is hop-by-hop, clients keep a plain text cache on disk, along with a log of meta-data (and servers tend to log a lot of plain text meta-data too), client certificates are being phased out for http2... Wrapping messages in s/mime or gpg actually looks pretty good by comparison. Maybe what we need is a suggestion that if you email user+secure@example.com rather than user@ - only email encrypted to User@example.com (with user+secure@ as alt identity...) will get through? Then muas could check to see if there's a gpg key for user+secure@, given mailto user@, in the directory - and transparently Encrypt by default?
- tptacek 9y ago
  It doesn't make sense to talk about whether HTTPS is end-to-end encrypted. Sometimes it is, sometimes it isn't. If you're exchange secrets directly with a web application that doesn't leave the application's secured deployment environment, TLS is all you need. But if you're exchanging secrets with another person using a server as a mediator --- as is the case with web chat and web email systems --- then it's not. I don't know why we'd bother with fussy contraptions involving special email addresses that nobody knows about, let alone uses. We have secure messaging systems today, systems billions of people already use, they're designed from the ground up to handle these problems, and so they're much better at security than any email system we can even reasonably come up with might be. Why are we wasting time trying to make people feel safer emailing secrets? We should get them to stop doing that at all.
  - e12e 9y ago
    It's my understanding that most of these secure messaging system relay via servers speaking https - and their distinctive feature is that the clients are distributed as self-contained apps, that wrap the complexity, and label "signal-protocol over https rpc" as just "signal" (similar for WhatsApp etc). Why is it hopeless to do the same for email? Take a sane protocol subset, add a convention protocol for encryption, and ship it as "secure email"? It is a tautology that a "secure mail app" that allows "traditional email interop" cannot make strong privacy guarantees, just like when using WhatsApp you give up federation and networking-as-a-utility (you're completely beholden to a provider that you don't even have a proper contract with, let alone the opportunity to seamlessly move providers / self-host / federate while maintaining global addressing and data portability). I think that's part of the disconnect in the discussion - wrapping a sane protocol selection in an opaque app along with a saas/paas silo that limits addressing, routing and federation is OK for some arbitrary subset of not-by-themselves secure protocols, but any suggestion that reusing elements of email is dismissed as "can't be done" (or "can't be done, because webmail", while "can't be done because messenger.com" seems absent). We've already done meta-data wrapping for email, with one, perhaps flawed approach: https://en.m.wikipedia.org/wiki/Mixmaster_anonymous_remailer https://en.m.wikipedia.org/wiki/Mixmaster_anonymous_remailer