Skip to content
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

Closed
1 task done
TaaviE opened this issue May 17, 2024 · 3 comments
Closed
1 task done
Labels
enhancement New feature or request

Comments

@TaaviE
Copy link

TaaviE commented May 17, 2024

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 the Content-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

  • I agree to follow this project's Code of Conduct
@TaaviE TaaviE added the enhancement New feature or request label May 17, 2024
@mdecimus
Copy link
Member

Hi,

The DKIM exploit has been addressed on May 18th and the fix is going to be included in version 0.8.1.

Thanks.

@TaaviE
Copy link
Author

TaaviE commented May 21, 2024

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

@mdecimus
Copy link
Member

@TaaviE I just added the legend (do not use) next to RSA SHA-1 on the webadmin to discourage its use on messages signed by Stalwart.
Regarding ignoring SHA-1 and <= 1024 bit signatures, sure, feel free to open a new enhancement for that. But I do think this option should be false by default as it will generate complains from users getting many of their emails sent to the Junk Mail folder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants