stalwartlabs / mail-server

Secure & Modern All-in-One Mail Server (IMAP, JMAP, POP3, SMTP)
https://stalw.art
5.3k stars 222 forks source link

[enhancement]: Discourage or disallow creating DKIM signatures with the length tag #442

Closed TaaviE closed 6 months ago

TaaviE commented 6 months ago

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

mdecimus commented 6 months ago

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 commented 6 months ago

@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 commented 6 months ago

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