[dataflow]

I really don't understand what the original DKIM was not sufficient. Can someone ELI5? If you can verify that a message (including headers, which DKIK can sign) was signed by the outgoing server, then why isn't that the end of the story? Who cares how or why it got forwarded, or whatever else?

[winstonwinston]

They want to allow forwarders (such as mailing lists) to modify signed messages all while keeping the original signed author email address. It is meant to replace ARC which is now deprecated.

You can now verify who changed what and when but it is still based on will and trust to accept what has been altered and therefore a security theatre.

It ‘solved’ a problem for a mailing list that insist on altering signed messages, even though they do not have to modify forwarded messages in my opinion and many lists do not.

[brightball]

There are a few gaps with DKIM.

1. You have to set it up on every sending server. It's easier today but it wasn't always

2. You have to periodically rotate each of the keys that you setup because they can be cracked/stolen. Soon as somebody steals your key, they can impersonate anyone sending email from your domain.

3. Receiving email servers have no way of knowing if a message they received without a DKIM signature is supposed to include a DKIM signature, so simply not including one creates a scenario where receiving mail servers have to guess if the message was really from you.

[crote]

2b. You have to publish the retired private keys, or else a recipient will retain undeniable proof of message authenticity.

Depending on your perspective, this can be either a feature or a bug.

[bombcar]

The fallout from this has barely begun to be felt. It’s more important than the hypothetical quantum crypto stuff imo.

[yasaheblasa]

1&2 sound worse after this update as described.. I'm not really sure why we are still bothering with this when DNSSEC progress means DANE like setups could solve the original E2E S/MIME issues of payment and domain indicating expectation of what its email senders are required to have for S/MIME.

There are some aspects of (possibly positive) deniability by an individual that probably still remain with DKIM but they kind of remain anyway with domain anchored S/MIME.

[tptacek]

What DNSSEC progress?

[yasaheblasa]

I don't consider 100% the goal since I'm happy if the average squatter/spammer/landing-page maker finds no value in steps to reaching more discerning clients given correlating filters. It seems likely to me that the percentage is near the tipping point where any serious organization is probably doing DNSSEC or having discussions about why they have IT problems and should be as serious now as they are for the email standards. For example, the validating DNSSEC looks higher than domains with functioning DKIM usage:

https://stats.labs.apnic.net/dnssec?s=Validating&d=01%2F06%2... https://stats.labs.apnic.net/dnssec?s=Validating&d=01%2F06%2... https://stats.labs.apnic.net/dnssec?s=Validating&d=01%2F06%2... https://stats.labs.apnic.net/dnssec?s=Validating&d=01%2F06%2...

[tptacek]

I don't think it's the case that serious orgs are generally doing DNSSEC. Rather the opposite.

https://dnssecmenot.fly.dev/

[yasaheblasa]

Sure, biggest Brand/Monopoly (and largely US) Tech is of course an interesting situation with a few different directions for interpretation. Yet, I think that many of them simply have to add DNSSEC, IPv6, etc as soon as the numbers finally look too much like 50%+, I.e. MS is about half the sites and already has selectively added it, usually where the consumer brand consequence is theirs via a SaaS product.

[dataflow]

1. I can't say I buy this excuse, but okay.

2. Is this an actual problem that has arisen with a worrying frequency in the past, or just a hypothetical? And how is it different from someone stealing your SSH key or TLS certificate?

3. Isn't it obvious from previous emails you've received from the same server?

[brightball]

1. There are a lot of domains out there and all of the people who own them aren't necessarily technical enough to setup DKIM on their mail server. Ideally those people are using some type of service. SPF is much simpler in this regard.

2. This is a rather famous story about it happening.

https://www.wired.com/2012/10/dkim-vulnerability-widespread/

I have no idea how widespread the issue is today but I had to do some analysis on it when I worked for dmarcian ahead of the Anti-Phishing Working Group conference and we found that a significant percentage of email from known malicious IPs associated with reported phishing was passing DKIM. Key rotation removes the problem. Many services like ProtonMail and Sendgrid will set you up with 2 CNAME's for your DKIM keys so that they can rotate them for you automatically.

3. Domains send emails from multiple servers. Sometimes dedicated email servers, Google/Outlook, Sendgrid, email marketing tools, etc. A receiving system has no way to validate whether any of the tools sending email claiming to be from your domain are actually from your domain. The first time you look at a DMARC report for a domain that's been around for a while, you will typically see that 90% or more of the messages claiming to be from your domain weren't from you at all.

[dataflow]

Re: #3, shouldn't this be per-domain anyway, rather than per server? If a domain has one server signing and another one not signing then something feels wrong. It seems pretty fine to just look at what the domain did in the past as the basis, no?

[brightball]

Since multiple services can send on behalf of the domain, DKIM has to be configured for each of them. A service provider, like Google, will likely use the same private key across any of their servers that is sending your mail but Sendgrid won't have access to that private key so they have to setup their own. Same goes for any other services that send mail using your domain.

As a receiving mail server, they have no way of knowing how many different parties are legitimately sending email on behalf of your domain.

SPF is per domain. You setup a DNS record at the domain (or subdomain) level that lists all of the IPs (or a DNS reference to a list of those IPs) that are authorized to send email on your behalf...but, that breaks with mail forwarding and mailing lists.

SPF is much simpler, absolutely. DKIM requires a private key to sign outgoing messages from every mail server sending mail on your behalf.

[dataflow]

> A service provider, like Google, will likely use the same private key across any of their servers that is sending your mail but Sendgrid won't have access to that private key so they have to setup their own. Same goes for any other services that send mail using your domain.

I'm sorry, I'm so lost and confused. Why would a service like SendGrid be impersonating a random domain without being able to get a private key from the domain owner? Like you're saying SendGrid offers the ability to send emails from a domain like @gmail.com without its private key?

[bawolff]

> Who cares how or why it got forwarded, or whatever else?

Because it broke enough niche usecases that lots of people didn't feel comfortable fully turning on dmarc in strict mode. Fixing that will hopefully spike adoption