Hacker News Reader

Comment by dataflow | Hacker News Reader

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?

View on HN

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.

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.

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.

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

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?

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.

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?

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.

> 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?

I'll try to explain.

Say I decide to open a pirate themed gym called Slimmer Ye Timbers and buy the domain slimmeryetimbers.com.

If I want to setup a website, I will go to a hosting company, set something up, go into the DNS and point a couple of records for the top level domain and the www subdomain to the hosting company.

If I want to receive email sent to argh@slimmeryetimbers.com I need to setup a mail server (Google, Outlook, web host may offer one, could setup an open source one, etc) and once it's setup I go to the DNS to point an MX record at the mail server.

So far, if people try to lookup my website or send an email TO me everything is pretty straightforward.

Now, if I want to send email that says it's FROM argh@slimmeryetimers.com is where things get weird. Because I don't have to do anything.

Any server, anywhere can just do it and every mail server that receives a message saying it's from that domain has to try to figure out if it really is or isn't. This is where antispam rules come in. Without DMARC, SPF & DKIM in place receiving mail servers will build up trust in different IP addresses, typically from vendors who go out of their way to prevent email abuse specifically to protect the reputation of those IP addresses. The receiving mail server my do a reverse DNS lookup to see if the hostname matched. They might see if the MX server used by domain is the same server sending the message along with a ton of other algorithmic hoops to make a good judgement. Even with DMARC, SPF and DKIM in place they may still use those rules.

DMARC, when strictly enforced with p=reject, let's you signal the receiving mail server that all mail claiming to be from your domain can be validated and if it can't be validated that message isn't from you and can be discarded. All that DMARC does is say that if you receive a message from this domain, it should pass either SPF OR DKIM for this domain as well.

So let's say, for example that I'm using both Google Workspace and Sendgrid for email for slimmeryetimbers.com. I'll setup Gmail for my main professional email for myself and my staff and I'll setup Sendgrid to send email from the website (responses to contact forms, etc).

For SPF it can be pretty simple, a single TXT record:

"v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Both Google and Sendgrid publish DNS records with the IP address of their servers and keep them up to date, so adding that include is all that we have to do.

DKIM is more complicated. Google will provide you with a DKIM record to put under a subdomain that includes the public DKIM key. Once they have verified it's setup, they will sign every email sent from your account with the private key that only they know. When a receiving server gets the message they will see that the message has been signed by DKIM and it will point to the subdomain where the public key was stored. By following the instructions from the signature in the email and using the public key, they can verify that the message was actually signed by the private key and hasn't been tampered with.

If we then setup Sendgrid they will give you their own DNS records for DKIM that work for their own private key. In both of these situations, we never get our hands on the private key because we are using a 3rd party service that doesn't disclose it. Sendgrid issues 2 CNAME records that point to DKIM public key records on their DNS so that they can control them. They'll send out messages signed with one private key and then later switch to a different private key while the original key and it's public record is changed, transparently without you having to deal with it.

If we were to setup our own mail servers, we would have access to it though. It's also entirely possible for somebody with access at an email company to go steal the private keys of their customers and sell them, or just use them. It's possible for those services or our mail servers to be hacked/compromised and the keys be stolen. Built in rotation process helps with this. It's the same reason that Let's Encrypt issues secure certificates that expire after 90 days (sometimes less). Just key rotation.

That was long but I hope it helps?

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.

What DNSSEC progress?

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...

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

https://dnssecmenot.fly.dev/

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.

As you can see, after 30+ years of effort, we are nowhere close to 50%, or even 25%, of deployment on real sites.

Secure shell had to wait quite a while for gradual adoption by anyone new and caskets of the older to pile up. SSL wasn't exactly shiny new in 2014 when LetsEncrypt was brought in to make it prevalent together with Google pressure. Similar pressure has the same groups picking DNSSEC experience up just in the last year.

If we put aside the advertising for a moment, the US had the same problems with every technology that is newer than landlines. Big investments in companies that will be prevented from failing will try to keep the US behind the trend but a few US companies will see that they better get ahead of where the rest of the world is going with or without US tech.

No, it didn't. SSH adoption was nearly universal with a year or two of its release. TLS was nearly universal on commercial sites long, long before LetsEncrypt. SSH and TLS are not comparable in adoption to DNSSEC.

> 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

Reply on news.ycombinator.com