-
-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[enhancement]: Discourage or disallow creating DKIM signatures with the length tag #442
Comments
Hi, The DKIM exploit has been addressed on May 18th and the fix is going to be included in version Thanks. |
@mdecimus Should I create separate issues for discouraging the use RSA-SHA1 DKIM and/or <=1024bit RSA keys? Both do exist out in the wild, if they made letters "spammier" or were ignored (when configured), it would too improve overall security. Because both SHA1 collisions and factoring 512bit keys are quite relatively feasible even right now, it would be good to take steps before both are trivial. |
@TaaviE I just added the legend |
Which feature or improvement would you like to request?
DKIM's length tag has been described as dangerous since the standard was published. When a DKIM signature with the
l
tag is created, it makes the letter malleable to the extent that its entire contents can be replaced by the attacker with no visible indicator.Allowing the use of
l
tag is a huge footgun. A modern email stack should ideally not allow it's use. The very least Stalwart should double/over-sign theContent-Type
header (along with other MIME headers) by-default.From the perspective of receiving, such letters DKIM signatures with the length tag should be ignored altogether. Alternatively the signature should be ignored when the specified length and canonicalized body size differ.
In order to further prevent DKIM replay attacks in general, signatures with timestamps too long in the past should be ignored. As an additional defense measure, signatures using SHA-1 or small keys should ideally be ignored, or should be penalized (it's quite likely those outdated systems are easier to compromise or abuse). If these things can't be done by default, users should have a documented option to enable these defenses.
We've written a larger writeup with some statistics and some of the possible attack and defense methods here: https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
Code of Conduct
The text was updated successfully, but these errors were encountered: