4 ms·

>You can't have strong security guarantees with backwards compatability, because backwards compatability requires plain text sending. That's right. >Unless yo

by jolux 6y ago

>You can't have strong security guarantees with backwards compatability, because backwards compatability requires plain text sending. That's right. >Unless you're OK with limited guarantees like the UI will tell you when the mail could be sent in plain text. Or if the UI tells you the message will be end to end encrypted, it won't fallback to plain text, etc. This would require changing all the clients.

toast0 6y ago
> This would require changing all the clients. Not really, the old clients would never send (or receive) end to end encrypted messages, so they don't need new UI to tell you that. That's the cost of unbounded backwards comptability. If you want to have 100% coverage of email users, changing all clients is part of the deal. But, uhhh, good luck with that. Server based standards are an easier lift --- you could build a standard to require hop to hop encryption on mail and expect that to plausibly gain enough adoption to use over a managable time frame. Of course it would be trivial for a hop in the delivery path to subvert that and remove the request, and all hops in delivery would still have message content access; but if people like it, a large majority of servers might support it in 5-10 years.
- jolux 6y ago
  >Of course it would be trivial for a hop in the delivery path to subvert that and remove the request, and all hops in delivery would still have message content access; but if people like it, a large majority of servers might support it in 5-10 years. You're describing TLS, and this is already happening.
  - toast0 6y ago
    Not just TLS, but a way to say, while composing a message, if it's can not be delivered via TLS with a valid certiticate, then don't deliver it. Which apparently already exists as REQUIRETLS https://www.rfc-editor.org/rfc/rfc8689.html https://www.rfc-editor.org/rfc/rfc8689.html Published November 2019. I didn't see any data on support, and hadn't heard of it before looking just now.

by jolux 6y ago

toast0 6y ago

> This would require changing all the clients. Not really, the old clients would never send (or receive) end to end encrypted messages, so they don't need new UI to tell you that. That's the cost of unbounded backwards comptability. If you want to have 100% coverage of email users, changing all clients is part of the deal. But, uhhh, good luck with that. Server based standards are an easier lift --- you could build a standard to require hop to hop encryption on mail and expect that to plausibly gain enough adoption to use over a managable time frame. Of course it would be trivial for a hop in the delivery path to subvert that and remove the request, and all hops in delivery would still have message content access; but if people like it, a large majority of servers might support it in 5-10 years.

jolux 6y ago
>Of course it would be trivial for a hop in the delivery path to subvert that and remove the request, and all hops in delivery would still have message content access; but if people like it, a large majority of servers might support it in 5-10 years. You're describing TLS, and this is already happening.
- toast0 6y ago
  Not just TLS, but a way to say, while composing a message, if it's can not be delivered via TLS with a valid certiticate, then don't deliver it. Which apparently already exists as REQUIRETLS https://www.rfc-editor.org/rfc/rfc8689.html https://www.rfc-editor.org/rfc/rfc8689.html Published November 2019. I didn't see any data on support, and hadn't heard of it before looking just now.