Default DKIM keylength of 4096 is too long

[JaapD]

Default DKIM keylength of 4096 is too long

The default DKIM is 4096, but according to https://tools.ietf.org/html/rfc6376 , Signers MUST use RSA keys of at least 1024 bits for long-lived keys. Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and they MAY be able to validate signatures with larger keys.

The consequence of 4096 bit keys is that some mailservers deny the mail.

[georglauterbach]

Although this is very true, you are able to set the length of your DKIM keys manually, of course.

You have chosen to use the BUG issue template.This is more of a question and not a bug - I will mark it appropriately.

---

The consequence of 4096 bit keys is that some mailservers deny the mail.

I do not deny that this does not happen, but DKIM failures are not automatically rejected AFAIK, only when the mail server does not understand the key length itself, right?

---

We as maintainers have chosen to use 4096 as the default, and we are likely going to stick with it. The reason being that we try to do a best-effort at using the forefront of security measures. This, of course, leads to situations where (especially old) mail servers will reject mail. But we believe this to be better than security vulnerabilities. In the end, as already mentioned, we will always make sure all of our users can fall back to more common settings (i.e. 2048 DKIM key size, intermediate TLS level, etc.).

Unless @wernerfred or @casperklein or @polarathene think decreasing the default is a good idea, I would stick with the current default.

[casperklein]

From my personal TLS experience (Webserver):

1024 is good and not broken yet.
2048 is better/recommended, but generates slightly more CPU load.
4096 is obviously the "best", but generates significant more CPU load. Compared to the increased CPU load, one must decided if it's worth it. Keeping in mind, that 1024 is still unbroken, 4096 is probably overkill in most situations.

I don't see this as a big problem, as everybody can choose the key-length they want, while generating the keys.

The only thing we could discuss is the aspect, what we want to provide:

1. Max security --> sticking with 4096 as default
2. Max compatibility, but still security in mind --> change to 2048 as default.

[wernerfred]

Imho you can't make a right decision. If we choose 2048 for default we will receive Issues asking why we support 4096 but don't set it as default and vice versa.

I don't see this as a big problem, as everybody can choose the key-length they want, while generating the keys.

Basically my opinion, too. Same as for the cipher levels; if someone uses old clients or have different requirements its free to choose another cipher list.

[georglauterbach]

Closing. Reason: Consent reached :D

[polarathene]

We as maintainers have chosen to use 4096 as the default, and we are likely going to stick with it. The reason being that we try to do a best-effort at using the forefront of security measures.

Personally 4096-bit is overkill and a common choice by those more paranoid without understanding the security given from 2048-bit. They often cite the 2015 logjam attack on 512-bit keys where it was advised not to use 1024-bit and 2048-bit became the new mainstream choice which is more than adequate.

IIRC 2048-bit is roughly equivalent to 112-bit symmetric security level. That is very secure already. 128-bit can be achieved with 3072-bit key instead, users just take the natural inclination to double the "strength" (but doubling the number of bits is far more than double the security strength) which is excessive IMO.

2048-bit would be a more sane default and still provide ample security in addition to the better compatibility.

---

Side note: Similar needs to be done with the DH keys which are also 4096-bit by default and there's a related PR and heavy discussion I had with the author at the time on that topic. I later got a more solid understanding of the security strength though and I'm pretty confident in 2048-bit being an appropriate and secure default personally.

I'll eventually create a PR for such with proper justification and details to back it, but I wouldn't expect such any time soon as I'm fairly busy elsewhere too.

[JaapD]

I mentioned an old RFC, the new one, https://tools.ietf.org/html/rfc8301, states: "Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits"
So 4096 may be long, but it's ok to use it.

[polarathene]

Sorry for delayed response, had a busy week! 😅

I mentioned an old RFC, the new one, https://tools.ietf.org/html/rfc8301

This was introduced in 2018, same as TLS 1.3. Implementations may lag behind such however, and servers upgrading their software further still. TLS 1.2 support was still problematic in some servers and clients until about 2016, but TLS 1.2 RFC was published back in 2008.

If mail servers you wish to exchange with won't risk any compatibility issues, then exceeding 4096-bit would be fine. I don't know how likely that is to be an issue, I don't think it's equivalent to a TLS protocol update, so the lag probably isn't as bad (or may not even be a problem in practice) 😅

In that same year a related RFC, RFC8461 was also issued. It introduces ECC key support instead of RSA which is nice 👍 If admins want security beyond 2048-bit RSA, perhaps they should favor using an ECC key instead? (seems to be 128-bit symmetric security strength, which I believe is less than RSA 4096-bit, but more than adequate, and much more efficient to deploy)

---

RSA 4096-bit is still excessive imo. Those that want it usually don't understand the security strength properly. You don't really gain anything tangible when you understand it better... but you do waste resources unnecessarily due to the overhead. Worrying still is those that advocate for RSA 8192-bit 😱

112-bit symmetric security strength (or rather entropy) from a RSA 2048-bit key is very strong. It requires a massive effort in time and resources to attack that it should be considered infeasible (unless we have some major technological breakthrough, but at that point there's no guarantee of RSA 4096-bit being any safer).

If I can find the time I'll PR docs that better explain why that is, along with the math to reassure anyone who's expressing concern that RSA 2048-bit wouldn't be enough as a default.

Mostly it really comes down to the cost of performing such an attack, there are more affordable options if the target is valuable enough to pursue.

---

The amount of energy required to brute-force an attack on 112-bit entropy

This is calculated naively (aka simplified, like just iterating through the full keyspace instead of many more complex operations in reality involved, along with costs external to the actual processing workload itself), except when referencing the rough cost per operation of factoring RSA-768 in 2009 (which was described as equivalent to the energy cost to boil two olympic swimming pools from 20C, about 464MWh, divided by 66-bit number and converted to Joules):

• Roughly what Russia, Japan or India produced annually in electricity in 2019 (Based on optimistic energy cost per operation, if based on the 2009 RSA-768 factoring, it'd be over 22 million times as much).
• Close to (and probably is in a less naive calculation) enough energy to boil all of the world's oceans (at the RSA-768 energy cost per operation).
• The global bitcoin hashing network as of 2021 at the 150M TH/sec processing power would take over 1 million years.
• If you had 100 trillion machines all capable of 1 billion guesses per second, it would take over 1,600 years (ideally your average success rate is at 50% of the keyspace, so within 800 years if all goes well, ignoring cost of powering that much compute or acquiring it, which is over 2^16 (65k) times more than the bitcoin network capability).

If certain trends held up with hardware advancement you could see doubling in processing capability within the same power budget every few years, allowing it to be possible to attack within your lifetime; but that cannot continue at such a pace as it will hit the limits of physics (and thermodynamics).

Besides, if you rotate your DKIM key regularly enough, the attack window is quite small. It's not like encrypted traffic which you could record and later decrypt to discover secrets is it? (assuming you got that far and had the resources to pull that attack off)

---

RSA 2048-bit is over 1 billion times more difficult than RSA 1024-bit (which is only 1k times more difficult than RSA 768-bit)

For what it's worth, the 2009 factoring of RSA 768-bit took about 2 years, they predicted that by 2020 RSA 1024-bit would likely be achievable due to advancements, noting that 768-bit was 5x easier than it'd have been when it's difficulty was predicted back in 1999 with the RSA 512-bit factoring.

Last I heard it's still quite difficult to achieve due to costs of the attack beyond time (768-bit used almost 1TB of RAM at it's peak, 1024-bit will require much more afaik).

RSA 1024-bit is only 10-bits more difficult (roughly 1,000x) than RSA 768-bit, that doesn't change, just the time/cost becomes more within reach with technological advancement. RSA 2048-bit (112-bit symmetric security strength) is roughly 30-bits or so more difficult than RSA 1024-bit, that's over 1 billion times more difficult! 😄

---

TL;DR

[georglauterbach]

@polarathene Thanks for the nice explanation:) I've read about ECC in DKIM too and would be happy to see it!:D We are currently only proving RSA keys if I'm not wrong.

What's the chance of "easily" providing ECC as well?

[polarathene]

Thanks for the nice explanation:)

Welcome! :)

What's the chance of "easily" providing ECC as well?

I haven't looked into it personally, I'm not sure when I would have the time to either at this point. If the related software supports signing with the ECC curve and likewise verifying on received it's probably just some config changes that could be added via ENV + sh script to the image.

The wikipedia article on DKIM or the linked RFC did mention you may want to sign with two keys, both RSA and ECC when signing, so if the receiver doesn't support the ECC key, it will apparently fallback to RSA (two separate DNS DKIM entries I think).

That doesn't help as much for the server doing signing but is probably better than 4096-bit RSA still (I haven't run any benchmarks, but recall 4096-bit and 8192-bit scaling quite poorly performance wise vs ECC). 2048-bit RSA + 256-bit ECC (112-bit + 128-bit symmetric strength) may be faster than 4096-bit RSA and any modern MTA receiving with ECC support would opt for the higher strength.

[georglauterbach]

Sounds very reasonable to me. I will have a look into it myself, but I'm short on time too. Maybe a feature to look forward to in the future.