2 ms·

There are some good points in there, and, while I don't want to provide a definitive rebuttal, I think it is worth mentioning how close PGP is to something that

There are some good points in there, and, while I don't want to provide a definitive rebuttal, I think it is worth mentioning how close PGP is to something that can be recommended. Let me respond to the issues one by one: > If messages can be sent in plaintext, they will be sent in plaintext. This is actually perhaps the strongest argument. If I'm steelmanning it correctly, it says that any system which tries to be backwards compatible with an insecure protocol is likely to result in some messages being unencrypted when they're not supposed to, either by accident, or due to an attack. It's true that by introducing an entirely new, backwards incompatible protocol, this entire class of problems can be almost eliminated. There is still, of course, the problem that someone copy-pastes text from a secure context to an insecure context, but I agree that there is a meaningful reduction of risk being offered here. However, it is worth comparing this situation to the web ecosystem. The fact is, browsers still support both HTTP and HTTPS, and a lot of work has been done on protocols, and implementations, and UX to stop downgrade attacks from happening. To avoid this problem, we could have defined HTTP to be the legacy web, and come up with an entirely new protocol (perhaps one where a benevolent dictator provides the only accepted client and server implementations), but I'm glad we didn't go down that route. > Metadata is as important as content, and email leaks it. While the most popular email encryption tool doesn't encrypt subject lines, Delta Chat, for example[0], does. That's therefore not an argument against encrypted email as it against using clients that aren't as good as Delta Chat. However, your point about backwards compatibility is still relevant here. I suppose the analogous scenario is that with HTTPS we know whether the connection to the server is encrypted by looking at the URL (or the padlock, or other clues that users don't really follow). However, until quite recently there was still the issue that a request over HTTPS could pull in sub-resources that weren't encrypted, which feels somewhat equivalent to someone accessing their Delta Chat inbox in a separate client that doesn't use PGP. As for other metadata, it would be possible for email providers to implement a type of anonymous remailer, where the sending server hides the sender address, and the recipient server decrypts an outer layer of encryption to find the intended recipient, but I admit that no providers currently offer such a service. If it were implemented, though, I think it could offer better security than centralised services, because the metadata could be split across different jurisdictions, removing the single point of failure. > Every archived message will eventually leak. This seems to be an argument that if you store sensitive documents on your computer, then the security of those documents is only as good as your at-rest encryption (and your ability to stop someone separating you from your computer when it is unlocked). You accept that recipients can configure their email clients to delete old messages stored on their computer, but then you seem to require that senders can delete their old messages on other people's computers, which doesn't seem like something any protocol can enforce. (You also make a point here about how JavaScript sent from a server can't be made secure, because a server can send a different script next time you visit. That's true, unless the initial page of the web app is stored as a bookmarklet[1], or secured by a hashlink[2], which browsers currently don't support). > Every long term secret will eventually leak. Yes, it would be nice to have Perfect Forward Secrecy supported by PGP encrypted email. There has at least been some effort to advance that at the IETF in the past[3], and it's also being considered as part of the future development of Autocrypt.[4] [0] https://delta.chat/pt/help#how-does-delta-chat-protect-my-metadata https://delta.chat/pt/help#how-does-delta-chat-protect-my-me... [1] https://news.ycombinator.com/item?id=17776456 https://news.ycombinator.com/item?id=17776456 [2] https://datatracker.ietf.org/doc/draft-sporny-hashlink/ https://datatracker.ietf.org/doc/draft-sporny-hashlink/ [3] https://datatracker.ietf.org/doc/html/draft-brown-pgp-pfs-03 https://datatracker.ietf.org/doc/html/draft-brown-pgp-pfs-03 [4] https://autocrypt.org/next-steps.html#deletable-forward-secure-encrypted-mail https://autocrypt.org/next-steps.html#deletable-forward-secu...

tptacek 5y ago
For more than a decade, the web security field was plagued by vulnerable UX that would, in a bunch of different ways, shift users off HTTPS sites and on to HTTP sites. It was a real problem, only recently and gradually mitigated by HSTS. Two distinctions to draw between the HSTS situation and the encrypted email situation: 1. There is no proposed "HSTS" for email, let alone any coherent plan by which it could be rolled out; HSTS worked because a very small number of browsers needed only collaborate with a relatively small number of server operators to make it work; the dynamics of email are totally different. 2. In the web threat model, the consequences of shifting a user from HTTPS to HTTP are not automatically fatal, and affect only that user. In the Inevitable Encrypted Reply, whole threads involving multiple counterparties are disclosed. And in the PGP threat model, you have to assume the adversary is recording everything, all the time. Once the I.E.R. happens, you and all your friends are dead.
- dane-pgp 5y ago
  Thank you for fleshing out the comparison between HSTS and encrypted email. I just have a couple of points to add. 1. For the avoidance of doubt, there is a proposed "HSTS for email", but it doesn't provide end-to-end encryption (so it's not particularly relevant here). The technology I'm talking about is MTA-STS,[0] as described in RFC 8461, which you probably already know about, but it might be new to other people. I'm not sure how different the dynamics are between the web and email, though. Surely there are more operators of web servers than email servers? Also, over 90% of the email client market is attributable to Google, Microsoft, Apple, and Yahoo! collectively.[1] That doesn't seem very different to the situation with browsers. 2. I think it's worth highlighting that if a user is shifted from HTTPS to HTTP, that may mean that their password (or session cookie) is being sent unencrypted to/through an attacker. Once the attacker has this, they can access all the details of a user's account, which, in the case of webmail or a forum, includes all previous messages and grants them the ability to send new messages as that user. That seems like a worse failure mode than just losing the privacy of a single message, and I think people are just as likely to die if you leak information about them over insecure email as over insecure HTTP. In both cases the threat model would assume that the adversary is recording everything, all the time. [0] https://scotthelme.co.uk/improving-email-security-with-mta-sts/ https://scotthelme.co.uk/improving-email-security-with-mta-s... [1] https://www.litmus.com/blog/email-client-market-share-infographic/ https://www.litmus.com/blog/email-client-market-share-infogr...

tptacek 5y ago

For more than a decade, the web security field was plagued by vulnerable UX that would, in a bunch of different ways, shift users off HTTPS sites and on to HTTP sites. It was a real problem, only recently and gradually mitigated by HSTS. Two distinctions to draw between the HSTS situation and the encrypted email situation: 1. There is no proposed "HSTS" for email, let alone any coherent plan by which it could be rolled out; HSTS worked because a very small number of browsers needed only collaborate with a relatively small number of server operators to make it work; the dynamics of email are totally different. 2. In the web threat model, the consequences of shifting a user from HTTPS to HTTP are not automatically fatal, and affect only that user. In the Inevitable Encrypted Reply, whole threads involving multiple counterparties are disclosed. And in the PGP threat model, you have to assume the adversary is recording everything, all the time. Once the I.E.R. happens, you and all your friends are dead.

dane-pgp 5y ago
Thank you for fleshing out the comparison between HSTS and encrypted email. I just have a couple of points to add. 1. For the avoidance of doubt, there is a proposed "HSTS for email", but it doesn't provide end-to-end encryption (so it's not particularly relevant here). The technology I'm talking about is MTA-STS,[0] as described in RFC 8461, which you probably already know about, but it might be new to other people. I'm not sure how different the dynamics are between the web and email, though. Surely there are more operators of web servers than email servers? Also, over 90% of the email client market is attributable to Google, Microsoft, Apple, and Yahoo! collectively.[1] That doesn't seem very different to the situation with browsers. 2. I think it's worth highlighting that if a user is shifted from HTTPS to HTTP, that may mean that their password (or session cookie) is being sent unencrypted to/through an attacker. Once the attacker has this, they can access all the details of a user's account, which, in the case of webmail or a forum, includes all previous messages and grants them the ability to send new messages as that user. That seems like a worse failure mode than just losing the privacy of a single message, and I think people are just as likely to die if you leak information about them over insecure email as over insecure HTTP. In both cases the threat model would assume that the adversary is recording everything, all the time. [0] https://scotthelme.co.uk/improving-email-security-with-mta-sts/ https://scotthelme.co.uk/improving-email-security-with-mta-s... [1] https://www.litmus.com/blog/email-client-market-share-infographic/ https://www.litmus.com/blog/email-client-market-share-infogr...