4 ms·
Well, you could use opportunistic encryption: once the first (plain text) email is sent, it establishes an identity for the sender and from that point forward t
by yholio 5y ago
Well, you could use opportunistic encryption: once the first (plain text) email is sent, it establishes an identity for the sender and from that point forward the exchange is encrypted. It's, of course, not authenticated, and anyone can MITM the exchange, but it kills dead all passive (eavesdrop only) attacks. Also it makes a past compromise easy to detect, without reusing any session key.
A more direct solution would be to leverage the DNSSec infrastructure and publish, say, an "MXK record" (MX Keyserver) for each compliant server. If such a record is present, then the mail domain vouches that you can find at that specific address a VKS keyserver that can resolve individual public keys for all its mailboxes. The whole exchange is encrypted and hierarchically authenticated, from the DNSSec root down to the individual mailbox, so it requires the cooperation/compromise of the specific level to break.
This way, when you type "user@host" in your email client's To: bar, the client can immediately resolve the public key of the recipient, and encrypt and sign the message accordingly with a high confidence that the encryption will be transparent and ensure the security of the exchange.
- akerl_ 5y agoYou’ve not addressed the overall problem of session vs long lived keys, but more so you’re pitching we tie this to DNSSEC? I’d think the fact that DANE is basically the same idea and has been jettisoned by browser vendors would be a good data point.
- yholio 5y agoLong lived public keys work well for PGP, the trouble with that is the manual handling of keys and huge learning curve. With automated identities handled by the email client and countersigned by the provider, you can easily establish a key rotation schedule. Maybe not as effective as Signal but it stops all MITM attacks that don't compromise the providers, a high bar. Of course, the actual symmetric encryption key is unique for each message. DANE was ditched not because of technical problems or political pushback, but simply due to lack of adoption. Massive network effects and existing investment in the broken CA model, sites don't care about interacting with two sets of PKI if customers will only reach them on one, therefore they don't publish DANE records, therefore the support is removed from major browsers after a few years essentially to reduce dead code and 1024 bit RSA keys. If you know otherwise please enlighten. So it's the same problem everywhere, lack of interoperability chains us to outdated protocols, a problem of course shared by my proposal too.
- akerl_ 5y agoGPG doesn’t work well generally, and long lived keys are one of the many major flaws.
- WalterBright 5y ago> the trouble with that is the manual handling of keys and huge learning curve There's no learning curve with the scheme I proposed.