3 ms·

You could associate your public key with a DNS record that you control? e.g. https://tools.ietf.org/html/rfc7929 https://tools.ietf.org/html/rfc7929

jolmg 7y ago
The MitM problem is not with sending the public key. They can just email it. The MitM problem is with intercepting the instructions from person A, having the MitM person generate them, and provide the pair to person B while impersonating A.
- dane-pgp 7y ago
  If you know you want to email alice@example.dk and if you trust DNSSEC, then fetching the public key for alice@example.dk from the DNS should be at least as secure as visiting https://example.dk https://example.dk in your browser. (If you don't trust that Alice's email address is alice@example.dk then you shouldn't send an email for her to that address regardless of MitM attacks.)
  - jcranmer 7y ago
    You're omitting the part that example.dk could create a fake key for alice@example.dk, publish that, decrypt a copy for themselves, and reencrypt it for alice@example.dk's public key.
    - dane-pgp 7y ago
      Well, I said it's at least as secure as visiting https://example.dk https://example.dk in your browser, where your attack is equivalent to the hosting company or DNS provider generating a new TLS certificate for that domain without the knowledge of Alice, the nominal registrant. (The web PKI also has the problem that any CA can issue a certificate for any domain).
      - jcranmer 7y ago
        The catch is that the primary reason to choose encrypted email is to prevent your hosting email provider from reading your email, so the inability of encrypted email to provide that guarantee kind of renders it worthless.
        dane-pgp 7y ago
        Of all the attackers you could worry about, I wouldn't put your own email hosting provider at the top of the list. MTA-STS is nice, but it's hard for an email client to guarantee that the hop-to-hop links between itself and the recipient's inbox are going to be protected with TLS. Passive snoops between mail providers seem like a much more realistic threat. Also, by putting a public key in the public DNS, it means that Alice can catch her mail provider's DNS server giving false information about her public key, which would come with cryptographically signed proof of which entities were involved in that lie. Ideally there would be an equivalent to the Certificate Transparency system for keys that are used or protected by DNSSEC.
  - CiPHPerCoder 7y ago
    > ... and if you trust DNSSEC... I don't, thanks.
pavel_lishin 7y ago
This is orders of magnitude more difficult than just telling someone to install Signal. Even people who are somewhat tech savvy are going to have trouble with these instructions. I freely admit that I have no idea how to do what you're proposing I do.

jolmg 7y ago

The MitM problem is not with sending the public key. They can just email it. The MitM problem is with intercepting the instructions from person A, having the MitM person generate them, and provide the pair to person B while impersonating A.

dane-pgp 7y ago
If you know you want to email alice@example.dk and if you trust DNSSEC, then fetching the public key for alice@example.dk from the DNS should be at least as secure as visiting https://example.dk https://example.dk in your browser. (If you don't trust that Alice's email address is alice@example.dk then you shouldn't send an email for her to that address regardless of MitM attacks.)
- jcranmer 7y ago
  You're omitting the part that example.dk could create a fake key for alice@example.dk, publish that, decrypt a copy for themselves, and reencrypt it for alice@example.dk's public key.
  - dane-pgp 7y ago
    Well, I said it's at least as secure as visiting https://example.dk https://example.dk in your browser, where your attack is equivalent to the hosting company or DNS provider generating a new TLS certificate for that domain without the knowledge of Alice, the nominal registrant. (The web PKI also has the problem that any CA can issue a certificate for any domain).
    - jcranmer 7y ago
      The catch is that the primary reason to choose encrypted email is to prevent your hosting email provider from reading your email, so the inability of encrypted email to provide that guarantee kind of renders it worthless.
      - dane-pgp 7y ago
        Of all the attackers you could worry about, I wouldn't put your own email hosting provider at the top of the list. MTA-STS is nice, but it's hard for an email client to guarantee that the hop-to-hop links between itself and the recipient's inbox are going to be protected with TLS. Passive snoops between mail providers seem like a much more realistic threat. Also, by putting a public key in the public DNS, it means that Alice can catch her mail provider's DNS server giving false information about her public key, which would come with cryptographically signed proof of which entities were involved in that lie. Ideally there would be an equivalent to the Certificate Transparency system for keys that are used or protected by DNSSEC.
- CiPHPerCoder 7y ago
  > ... and if you trust DNSSEC... I don't, thanks.

pavel_lishin 7y ago

This is orders of magnitude more difficult than just telling someone to install Signal. Even people who are somewhat tech savvy are going to have trouble with these instructions. I freely admit that I have no idea how to do what you're proposing I do.