3 ms·

How do I trust the public key I get via a tag in an email from somebody whose public key I don’t already have? How does the person rotate keys if we only talk

by akerl_ 5y ago

How do I trust the public key I get via a tag in an email from somebody whose public key I don’t already have? How does the person rotate keys if we only talk occasionally? Or, if we’re looking for a bigger, overall flaw: e-mail is fundamentally fire-and-forget via SMTP, so there isn’t a way to use the users pubkey to creat a per-message session key, and reusing a persistent key for encrypting data is a massive pitfall.

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 ago
  You’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 ago
    Long 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 ago
      GPG 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.
WalterBright 5y ago
> How do I trust the public key I get via a tag in an email from somebody whose public key I don’t already have? You trust it as much as you trust getting getting unencrypted email from your friends. The point, though, is that from then on, nobody else can eavesdrop on your communications with the person who sent you their public key. You can still verify it by calling up the person and asking if he sent it. Or you can have him send the key via snail mail. > How does the person rotate keys if we only talk occasionally? The same way you got the original key. > so there isn’t a way to use the users pubkey to creat a per-message session key, and reusing a persistent key for encrypting data is a massive pitfall. Is it that massive? SSH uses keys that aren't changed every time it's used it, and it's still viable. Besides, it's as secure as any public key cryptosystem is, and that's a heck of a lot better than plaintext.
- akerl_ 5y ago
  SSH uses asymmetric crypto to authenticate, and then negotiates session keys. That’s how most modern PKI systems actually work. TLS is a great example: all actual traffic is encrypted symmetrically, and all modern ciphers use forward-secret session key negotiations. And, to say the underlying part out loud: an encryption system can be a heck of a lot worse than plaintext, because plenty of ways of handling encryption are trivially broken, but give the user an illusion that what they’re saying is secure. For rotation: my specific question was around long delays. Say, for example, you email me today. I get your public key from this new tag we’ve added. A month later, you rotate your key, but the next time we exchange emails is when I email you a year from now. I’m using your old key, the one I have.
  - WalterBright 5y ago
    Yes, but anyone with my SSH keys can connect with SSH. > but give the user an illusion that what they’re saying is secure. I don't trust any encryption system with my life or the nuclear launch code. But for casual privacy, the scheme I proposed is fine. > I’m using your old key, the one I have Then my system should bounce it back saying the key is invalid. Of course, if I change my key the email app should send a "new public key" email to my address book.

by akerl_ 5y ago

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 ago
You’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 ago
  Long 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 ago
    GPG 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.

WalterBright 5y ago

> How do I trust the public key I get via a tag in an email from somebody whose public key I don’t already have? You trust it as much as you trust getting getting unencrypted email from your friends. The point, though, is that from then on, nobody else can eavesdrop on your communications with the person who sent you their public key. You can still verify it by calling up the person and asking if he sent it. Or you can have him send the key via snail mail. > How does the person rotate keys if we only talk occasionally? The same way you got the original key. > so there isn’t a way to use the users pubkey to creat a per-message session key, and reusing a persistent key for encrypting data is a massive pitfall. Is it that massive? SSH uses keys that aren't changed every time it's used it, and it's still viable. Besides, it's as secure as any public key cryptosystem is, and that's a heck of a lot better than plaintext.

akerl_ 5y ago
SSH uses asymmetric crypto to authenticate, and then negotiates session keys. That’s how most modern PKI systems actually work. TLS is a great example: all actual traffic is encrypted symmetrically, and all modern ciphers use forward-secret session key negotiations. And, to say the underlying part out loud: an encryption system can be a heck of a lot worse than plaintext, because plenty of ways of handling encryption are trivially broken, but give the user an illusion that what they’re saying is secure. For rotation: my specific question was around long delays. Say, for example, you email me today. I get your public key from this new tag we’ve added. A month later, you rotate your key, but the next time we exchange emails is when I email you a year from now. I’m using your old key, the one I have.
- WalterBright 5y ago
  Yes, but anyone with my SSH keys can connect with SSH. > but give the user an illusion that what they’re saying is secure. I don't trust any encryption system with my life or the nuclear launch code. But for casual privacy, the scheme I proposed is fine. > I’m using your old key, the one I have Then my system should bounce it back saying the key is invalid. Of course, if I change my key the email app should send a "new public key" email to my address book.