3 ms·

This is all ridiculous. Maybe I’m not that bright, but it seems like you don’t need that much. 1. A TXT record containing a public key and a unique identifier

This is all ridiculous. Maybe I’m not that bright, but it seems like you don’t need that much. 1. A TXT record containing a public key and a unique identifier 2. Message Body and Headers hashed with SHA512, and then the hash is encrypted with the private key to the TXT record. This hash, and the address for the public key, is then added to the headers as the only permitted “untrusted” headers 3. Email receiver, if present, ignores all headers if the two are present. Looks up DNS public key, decrypts hash, removes the two headers, checks hash matches. If so, contents trusted if: 4. The domain the email was sent from, and claims to be sent from, is the same domain hosting the TXT record. What did I miss?

jerf 2y ago
You don't need all that much to ensure integrity in a brand-new system without decades of legacy. I mean, still non-trivial, getting that "not much" right is a professional cryptographer's job, but you don't need all that much. Getting it right in a system the size of the world with decades of legacy in an environment where right up until DKIM came out pretty much every player in the system expected and used the ability to make arbitrary modifications to emails passing through it is really hard. It makes even the simplest thing takes decades. Unfortunately, there isn't going to be a replacement to email either, because at this point anyone with the resources to pull it off will also insist on making it a closed box that you have to pay way, way too much to use.
- gjsman-1000 2y ago
  I’m a bit nuts, so bear with me: Maybe we should seriously have discussions about, let’s just call it, Email2. We have a new DNS record type, MX2, with a proper signing algorithm that’s mandatory. Meanwhile, we put it in spec that every MX2 mailbox, must be a valid MX mailbox, if the receiver chooses to accept MX. This might sound insane - except, I argue, with proper planning, it would be like the HTTPS transition. If you could even just get Gmail, Outlook, Zoho, and Yahoo on board - every piece of software would be forced to start supporting Email2. Especially, especially, if they announced that come 2030, all non-Email2 letters always go to Junk. They’ll still arrive - possibly forever - but the incentive to fix it will be there.
  - cameronh90 2y ago
    If we were going to do this, can we come up with a well defined subset/derived specification of HTML5 for email, along with a conformity test ala Acid2/Acid3? Outlook for Windows still uses the venerable Microsoft Word HTML rendering engine.
    - dsr_ 2y ago
      Sure. My primary request is that it not be allowed to show links as anything other than full URLs. My secondary priority is in not loading anything from an external site.
      - gjsman-1000 2y ago
        Unfortunately, we know that most people who aren't in tech, are terrible at reading and understanding URLs to begin with, so I'm not sure that there's any point to be gained here.
      - rebane2001 2y ago
        It'd be impossible to prevent non-full URLs without also imposing extremely heavy restrictions on images, styling, and html. There are way too many ways to hide, spoof, or obfuscate an url. And even then, you'd need to somehow render the link in a way where the average user can understand it (which part of the URL is the domain and what implications it has).
  - mvid 2y ago
    The benefit of email is its ubiquity and existing deployment. Throwing it away for a new protocol loses all existing value.
    - gjsman-1000 2y ago
      The same could be said of HTTP, but we threw it away in favor of HTTPS. Thank goodness we did - and I don’t think anyone wants to go back to the time we tried securing HTTP without HTTPS. Again, my proposal is not that we completely kill classic email - but rather, we make a new standard, the big players get on board, and there’s a clear deadline that says “your emails will always be junk past this date if they don’t comply.” They’ll still arrive though. Nobody wants their emails to go to Junk automatically - that’s incentive enough. This is like what we did with HTTP. There came a day where HTTP login screens now have warnings in many browsers. But they still work.
jeffbee 2y ago
You missed basically all of the practical details of sending and receiving mail. The people who wrote these RFCs and mail systems have been doing this for decades and have the experience to avoid the "why don't we simply [[wave arms]]" traps. The reason that DKIM signs only enumerated headers is because mailers add more headers as the message is in transit, and there is no way to sign those.
- kbolino 2y ago
  Well, the expanded payload could be signed again, just not with the same key.
toast0 2y ago
You missed that servers processing email routinely add or adjust headers. And some servers add trailing content. DKIM was designed to work with email as it exists, so the signer can pick which headers to include in the signature. And l= was included to allow for mailing list servers and other things to add trailers without breaking signatures or needing to sign again.
- magicalhippo 2y ago
  But does the recipient need to trust those headers? Couldn't it just remove those non-signed headers before decoding. If not, what does it really buy you? Slight fuzzy feeling? In the article they describe an attacker changing Content-Type as it's typically not signed. That seems like exactly the kind of header you'd want to ignore if not signed.
  - Avamander 2y ago
    > In the article they describe an attacker changing Content-Type as it's typically not signed. That seems like exactly the kind of header you'd want to ignore if not signed. That would result in a lot of unreadable emails unfortunately. It would also take over-signing the Content-Type to mitigate this issue, having everything signed that way would certainly break even more.
    - deleted 2y ago
      [deleted]
anamexis 2y ago
You've more-or-less described DKIM. You can see some issues with it here: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Weaknesses https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Wea...
SAI_Peregrinus 2y ago
Step 2 is wrong, you want a signature, not encryption. For RSA that's more like a decryption with the private key, though still different because the padding isn't the same.
peanut-walrus 2y ago
How often should the key be rotated? How is the rotation done? How are body and headers normalized? Which header determines who sent the email? How do you know the email was sent to you? Where do you store the on-path routing information?

jerf 2y ago

You don't need all that much to ensure integrity in a brand-new system without decades of legacy. I mean, still non-trivial, getting that "not much" right is a professional cryptographer's job, but you don't need all that much. Getting it right in a system the size of the world with decades of legacy in an environment where right up until DKIM came out pretty much every player in the system expected and used the ability to make arbitrary modifications to emails passing through it is really hard. It makes even the simplest thing takes decades. Unfortunately, there isn't going to be a replacement to email either, because at this point anyone with the resources to pull it off will also insist on making it a closed box that you have to pay way, way too much to use.

gjsman-1000 2y ago
I’m a bit nuts, so bear with me: Maybe we should seriously have discussions about, let’s just call it, Email2. We have a new DNS record type, MX2, with a proper signing algorithm that’s mandatory. Meanwhile, we put it in spec that every MX2 mailbox, must be a valid MX mailbox, if the receiver chooses to accept MX. This might sound insane - except, I argue, with proper planning, it would be like the HTTPS transition. If you could even just get Gmail, Outlook, Zoho, and Yahoo on board - every piece of software would be forced to start supporting Email2. Especially, especially, if they announced that come 2030, all non-Email2 letters always go to Junk. They’ll still arrive - possibly forever - but the incentive to fix it will be there.
- cameronh90 2y ago
  If we were going to do this, can we come up with a well defined subset/derived specification of HTML5 for email, along with a conformity test ala Acid2/Acid3? Outlook for Windows still uses the venerable Microsoft Word HTML rendering engine.
  - dsr_ 2y ago
    Sure. My primary request is that it not be allowed to show links as anything other than full URLs. My secondary priority is in not loading anything from an external site.
    - gjsman-1000 2y ago
      Unfortunately, we know that most people who aren't in tech, are terrible at reading and understanding URLs to begin with, so I'm not sure that there's any point to be gained here.
    - rebane2001 2y ago
      It'd be impossible to prevent non-full URLs without also imposing extremely heavy restrictions on images, styling, and html. There are way too many ways to hide, spoof, or obfuscate an url. And even then, you'd need to somehow render the link in a way where the average user can understand it (which part of the URL is the domain and what implications it has).
- mvid 2y ago
  The benefit of email is its ubiquity and existing deployment. Throwing it away for a new protocol loses all existing value.
  - gjsman-1000 2y ago
    The same could be said of HTTP, but we threw it away in favor of HTTPS. Thank goodness we did - and I don’t think anyone wants to go back to the time we tried securing HTTP without HTTPS. Again, my proposal is not that we completely kill classic email - but rather, we make a new standard, the big players get on board, and there’s a clear deadline that says “your emails will always be junk past this date if they don’t comply.” They’ll still arrive though. Nobody wants their emails to go to Junk automatically - that’s incentive enough. This is like what we did with HTTP. There came a day where HTTP login screens now have warnings in many browsers. But they still work.

jeffbee 2y ago

You missed basically all of the practical details of sending and receiving mail. The people who wrote these RFCs and mail systems have been doing this for decades and have the experience to avoid the "why don't we simply [[wave arms]]" traps. The reason that DKIM signs only enumerated headers is because mailers add more headers as the message is in transit, and there is no way to sign those.

kbolino 2y ago
Well, the expanded payload could be signed again, just not with the same key.

toast0 2y ago

You missed that servers processing email routinely add or adjust headers. And some servers add trailing content. DKIM was designed to work with email as it exists, so the signer can pick which headers to include in the signature. And l= was included to allow for mailing list servers and other things to add trailers without breaking signatures or needing to sign again.

magicalhippo 2y ago
But does the recipient need to trust those headers? Couldn't it just remove those non-signed headers before decoding. If not, what does it really buy you? Slight fuzzy feeling? In the article they describe an attacker changing Content-Type as it's typically not signed. That seems like exactly the kind of header you'd want to ignore if not signed.
- Avamander 2y ago
  > In the article they describe an attacker changing Content-Type as it's typically not signed. That seems like exactly the kind of header you'd want to ignore if not signed. That would result in a lot of unreadable emails unfortunately. It would also take over-signing the Content-Type to mitigate this issue, having everything signed that way would certainly break even more.
  - deleted 2y ago
    [deleted]

anamexis 2y ago

You've more-or-less described DKIM. You can see some issues with it here: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Weaknesses https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Wea...

SAI_Peregrinus 2y ago

Step 2 is wrong, you want a signature, not encryption. For RSA that's more like a decryption with the private key, though still different because the padding isn't the same.

peanut-walrus 2y ago

How often should the key be rotated? How is the rotation done? How are body and headers normalized? Which header determines who sent the email? How do you know the email was sent to you? Where do you store the on-path routing information?