4 ms·

You don't need to encrypt or sign anything. Organisations who email you like your bank and Paypal need to. You just need your email client to show a tick when i

You don't need to encrypt or sign anything. Organisations who email you like your bank and Paypal need to. You just need your email client to show a tick when it has verified a signature, which many already do with S/MIME.

c22 8y ago
Isn't this what DMARC is supposed to give us? Big companies like my bank and paypal run their own domains so they can use SPF/DKIM to authenticate their communications (and TLS to protect them in transit). Individually signed emails are only really useful for individuals.
- rakoo 8y ago
  No, because SPF/DKIM/DMARC only says that the mail server at bank.com did send this email. What I want to know as a recipient is if it was the correct bank.com, and not baank.com. Because baank.com can also have SPF/DKIM/DMARC.
  - c22 8y ago
    How is this any different than a PGP signature? If you don't bother to check the sender then it doesn't matter how encrypted or signed the message is.
    - rakoo 8y ago
      If you don't bother to check the sender then you're not using pgp the way it's supposed to. pgp wants you to assign trust to identities, explicitly or not, after which pgp will automatically tell you whether you're talking to the right person or not. That's something SPF/DKIM/DMARC doesn't have for a very simple and legitimate reason: it's not a technical issue, it's a people's issue.
      - c22 8y ago
        > ...it's not a technical issue, it's a people's issue. Exactly. Any solution you can come up with for baking PGP authentication into email can be applied also to DMARC, so if your primary use case is authenticating reputable businesses why not back the tech that's already seeing adoption by said businesses? Obviously it'd be great if all digital messages were effectively authenticated using strong cryptography. I imagine at some point we'll get there, probably through a combination of maturing technology and better educated users.
        rakoo 8y ago
        Saying "I trust you" is baked in in pgp. There's no such thing for DMARC because that's not its goal: DMARC and co are on the sender side for it to say "look it's really me", but that's not what we want. What we want would be a way to instruct our MTA to say "I trust these guys, the others go to the trash/spam"
        c22 8y ago
        I feel like we're talking past each other here. There's no reason an MTA couldn't allow you to designate the senders you trust and send the rest to spam. You could do the same by integrating PGP. The key exchange problem is the same, but DMARC handles this by tying the key to the domain. So if the email comes from bank.com and bank.com is also where you do your online banking you can be reasonably confident your bank sent the message. If we used PGP to do this then your bank would have to publish their public key somewhere and you would have to manually check that it's valid (served over https? printed on a card handed to you by the bank manager?) and configure it into your email client. This is exactly the user experience nightmare that causes "no one signing their emails". Obviously this sort of verification is required if you want truly authenticated communications with individuals, many of whom may share a domain, but if you simply want to verify that the organization you're talking to is who they say they are then the domain name is a suitable proxy.
        rakoo 8y ago
        I do agree that trusting the domain instead of the exact user is more than enough in the case of the article. What I'm saying is that PGP has the whole trusting thing built-in. Key distribution can be done through DNS (there is an OPENPGPKEY record: https://tools.ietf.org/html/rfc7929 https://tools.ietf.org/html/rfc7929) or through HTTP (https://tools.ietf.org/id/draft-koch-openpgp-webkey-service-03.txt https://tools.ietf.org/id/draft-koch-openpgp-webkey-service-...). On the other hand there is nothing existing today for telling your MTA to trust this or that domain only. There is no standard so every provider would start by doing their own thing. That missing part is the difficult part, and that is only doable in pgp today. However it is true that in both cases there should be some UI indication to ask you "do you trust this domain ?"
isostatic 8y ago
"verified a signature" How do you know that's your bank's signature and not from "h-s-b-c.com" How does granny know?
- pas 8y ago
  Your email client should show you if you have encountered that identity (identities of course can and should rotate keys, etc, and identities should be also signed by the keys that correspond to the certs signed by the CAs for the website/service). At first you don't know much about it, but it's a signal. If you continue to bank with HSBC and you get emails from them, you'll be able to spot a fake and the email client can say that it's a likely fake. No need to say anything else when you can't say otherwise.

c22 8y ago

Isn't this what DMARC is supposed to give us? Big companies like my bank and paypal run their own domains so they can use SPF/DKIM to authenticate their communications (and TLS to protect them in transit). Individually signed emails are only really useful for individuals.

rakoo 8y ago
No, because SPF/DKIM/DMARC only says that the mail server at bank.com did send this email. What I want to know as a recipient is if it was the correct bank.com, and not baank.com. Because baank.com can also have SPF/DKIM/DMARC.
- c22 8y ago
  How is this any different than a PGP signature? If you don't bother to check the sender then it doesn't matter how encrypted or signed the message is.
  - rakoo 8y ago
    If you don't bother to check the sender then you're not using pgp the way it's supposed to. pgp wants you to assign trust to identities, explicitly or not, after which pgp will automatically tell you whether you're talking to the right person or not. That's something SPF/DKIM/DMARC doesn't have for a very simple and legitimate reason: it's not a technical issue, it's a people's issue.
    - c22 8y ago
      > ...it's not a technical issue, it's a people's issue. Exactly. Any solution you can come up with for baking PGP authentication into email can be applied also to DMARC, so if your primary use case is authenticating reputable businesses why not back the tech that's already seeing adoption by said businesses? Obviously it'd be great if all digital messages were effectively authenticated using strong cryptography. I imagine at some point we'll get there, probably through a combination of maturing technology and better educated users.
      - rakoo 8y ago
        Saying "I trust you" is baked in in pgp. There's no such thing for DMARC because that's not its goal: DMARC and co are on the sender side for it to say "look it's really me", but that's not what we want. What we want would be a way to instruct our MTA to say "I trust these guys, the others go to the trash/spam"
        c22 8y ago
        I feel like we're talking past each other here. There's no reason an MTA couldn't allow you to designate the senders you trust and send the rest to spam. You could do the same by integrating PGP. The key exchange problem is the same, but DMARC handles this by tying the key to the domain. So if the email comes from bank.com and bank.com is also where you do your online banking you can be reasonably confident your bank sent the message. If we used PGP to do this then your bank would have to publish their public key somewhere and you would have to manually check that it's valid (served over https? printed on a card handed to you by the bank manager?) and configure it into your email client. This is exactly the user experience nightmare that causes "no one signing their emails". Obviously this sort of verification is required if you want truly authenticated communications with individuals, many of whom may share a domain, but if you simply want to verify that the organization you're talking to is who they say they are then the domain name is a suitable proxy.
        rakoo 8y ago
        I do agree that trusting the domain instead of the exact user is more than enough in the case of the article. What I'm saying is that PGP has the whole trusting thing built-in. Key distribution can be done through DNS (there is an OPENPGPKEY record: https://tools.ietf.org/html/rfc7929 https://tools.ietf.org/html/rfc7929) or through HTTP (https://tools.ietf.org/id/draft-koch-openpgp-webkey-service-03.txt https://tools.ietf.org/id/draft-koch-openpgp-webkey-service-...). On the other hand there is nothing existing today for telling your MTA to trust this or that domain only. There is no standard so every provider would start by doing their own thing. That missing part is the difficult part, and that is only doable in pgp today. However it is true that in both cases there should be some UI indication to ask you "do you trust this domain ?"

isostatic 8y ago

"verified a signature" How do you know that's your bank's signature and not from "h-s-b-c.com" How does granny know?

pas 8y ago
Your email client should show you if you have encountered that identity (identities of course can and should rotate keys, etc, and identities should be also signed by the keys that correspond to the certs signed by the CAs for the website/service). At first you don't know much about it, but it's a signal. If you continue to bank with HSBC and you get emails from them, you'll be able to spot a fake and the email client can say that it's a likely fake. No need to say anything else when you can't say otherwise.