That's why you don't change upstream code without reason.
Not only did they have a reason, they discussed the reason and the proposed change with upstream.
https://lwn.net/Articles/282038/
comments here read differently.
16 years of CVE-2008-0166 – Debian OpenSSL Bug
61–68 of 68 posts
Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug
#62Earlier quoted context omitted.
While you can forge the DKIM signature there is a good chance there is also SPF configured. SPF tells which servers are allowed to send mail for the domain. So your email would likely still end up in the spam folder.
DMARC only requires one of SPF or DKIM to pass. DKIM passing and SPF failing won't deter DMARC; the message will land in the inbox.
oh wow, didn't know that. That's actually pretty bad. Why on earth was it designed in such a way that didn't require both tests to pass if both of them are configured.
Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug
#63Earlier quoted context omitted.
DMARC only requires one of SPF or DKIM to pass. DKIM passing and SPF failing won't deter DMARC; the message will land in the inbox.
oh wow, didn't know that. That's actually pretty bad. Why on earth was it designed in such a way that didn't require both tests to pass if both of them are configured.
Because both of them rely on DNS. DKIM is trivial to bypass if you can create a TXT record with your own key, and SPF is trivial to bypass if you can create a TXT record containing an SPF record with your own IP address / hostname / whatever. Presumably if you can compromise one of them, you can compromise both.
Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug
#64Earlier quoted context omitted.
DMARC only requires one of SPF or DKIM to pass. DKIM passing and SPF failing won't deter DMARC; the message will land in the inbox.
oh wow, didn't know that. That's actually pretty bad. Why on earth was it designed in such a way that didn't require both tests to pass if both of them are configured.
Because SPF has many design flaws that will break SPF for legitimate use-cases (such as relaying/forwarding). You wouldn't want to rely on SPF, you should always on DKIM instead.
SPF should be considered legacy at this point. But of course DMARC had to be designed with backwards compatibility in mind, thus it'll still consider the email to be DMARC alignment with just SPF alignment (without DKIM alignment). Also, understand that 'alignment' is different from a 'pass', so it's not as bad as many commenters here make it look.
There are proposals of adding a flag to the DMARC policy to have the receiver ignore SPF alignment, thus enforcing DKIM alignment. However, that is not final yet.
Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug
#65Earlier quoted context omitted.
oh wow, didn't know that. That's actually pretty bad. Why on earth was it designed in such a way that didn't require both tests to pass if both of them are configured.
Because both of them rely on DNS. DKIM is trivial to bypass if you can create a TXT record with your own key, and SPF is trivial to bypass if you can create a TXT record containing an SPF record with your own IP address / hostname / whatever. Presumably if you can compromise one of them, you can compromise both.
> DKIM is trivial to bypass if you can create a TXT record with your own key
This is exactly what DMARC prevents. With DMARC the alignment requirement is added, so signing an email with a different domain key will no longer work.
For a DMARC pass you need DKIM alignment. DKIM alignment means that the email is correctly signed with a DKIM key that is published under the sender (rfc5322.From) domain.
Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug
#66Earlier quoted context omitted.
Because both of them rely on DNS. DKIM is trivial to bypass if you can create a TXT record with your own key, and SPF is trivial to bypass if you can create a TXT record containing an SPF record with your own IP address / hostname / whatever. Presumably if you can compromise one of them, you can compromise both.
> DKIM is trivial to bypass if you can create a TXT record with your own key This is exactly what DMARC prevents. With DMARC the alignment requirement is added, so signing an email with a different domain key will no longer work. For a DMARC pass you need DKIM alignment. DKIM alignment means that the email is correctly signed with a DKIM key that is published under the sender (rfc5322.From) domain.
Yes, and if you can get modification access to the TXT records for the sender's domain, you can compromise both DKIM and SPF. That's my point. Edit: More specifically, that it doesn't make sense to force both of them to pass when they both share a single point of failure.
Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug
#67Earlier quoted context omitted.
> DKIM is trivial to bypass if you can create a TXT record with your own key This is exactly what DMARC prevents. With DMARC the alignment requirement is added, so signing an email with a different domain key will no longer work. For a DMARC pass you need DKIM alignment. DKIM alignment means that the email is correctly signed with a DKIM key that is published under the sender (rfc5322.From) domain.
Yes, and if you can get modification access to the TXT records for the sender's domain, you can compromise both DKIM and SPF. That's my point. Edit: More specifically, that it doesn't make sense to force both of them to pass when they both share a single point of failure.
If your DNS is compromised it's game over anyway, because then everything is compromised. DNS is a single point of failure. You'll also be able to reroute inbound email, MITM HTTP traffic, order rogue TLS certificates, etc. etc.
Saying DKIM is flawed because you can create rogue keys with DNS access is the same as saying the entire PKI is flawed because you can order certificates using DNS-01 verification.
Re: 16 years of CVE-2008-0166 – Debian OpenSSL Bug
#68Earlier quoted context omitted.
Yes, and if you can get modification access to the TXT records for the sender's domain, you can compromise both DKIM and SPF. That's my point. Edit: More specifically, that it doesn't make sense to force both of them to pass when they both share a single point of failure.
If your DNS is compromised it's game over anyway, because then everything is compromised. DNS is a single point of failure. You'll also be able to reroute inbound email, MITM HTTP traffic, order rogue TLS certificates, etc. etc. Saying DKIM is flawed because you can create rogue keys with DNS access is the same as saying the entire PKI is flawed because you can order certificates using DNS-01 verification.
I didn't say DKIM was flawed. I wasn't complaining about DKIM at all. You may want to re-read the comment I was replying to. I'm well aware of the consequences of a DNS compromise.
I simply said, twice, that DMARC forcing both SPF and DKIM to align and pass doesn't add anything of value; if you are capable of subverting one of them, you are almost certainly capable of subverting both of them at the same time.