Description

I originally raised this change as desired back in a March 2021 discussion (and again by me recently in April 2023 and Aug 2023), detailing why we should be set the default to 2048 (revert rather, as the change from 2048 to 4096 wasn't justified well but got through review).

Additional history for how the default became 4096 is detailed in:

• refactor: Share a common helper (vhost builder) for sourcing domains #2620 (June 2022)
• tests(refactor): open_dkim.bats #3060 (Feb 2023)

I finally got around to tackling it 🎉 and improved the related DKIM docs and help command output while at it.

The DKIM UX and docs could probably do with some more improvements, but I mostly wanted to address the bad default of 4096-bit default key size. Potentially a breaking change if users rely on implicit defaults with automated config/deployment scripts.

Extra reference from RFC documents

Our docs reference RFC 6376, and I'll update that to reflect changes from RFC 8301 as noted below, and cited in the original March 2021 discussion referenced to motivate this change in DMS.

RFC 8301 3.2 Key Sizes (Jan 2018, Updates: RFC 6376):

Selecting appropriate key sizes is a trade-off between cost, performance, and risk. Since short RSA keys more easily succumb to off-line attacks:

• Signers MUST use RSA keys of at least 1024 bits for all keys.
• Signers SHOULD use RSA keys of at least 2048 bits.
• Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits, and they MAY be able to validate signatures with larger keys
• Verifiers MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures.

Compared to RFC 6376 3.3.3 Key Sizes (Sep 2011), the 1024-bit requirement for signers changed from long-lived keys to ALL keys, and that the verifiers minimum range for validation was raised to 1024-bit from 512-bit.

It additionally notes key size choice should be influenced by:

• The practical constraint that large (e.g. 4096-bit) keys might not fit within a 512-byte DNS UDP response packet.
• The security constraint that keys smaller than 1024 bits are subject to off-line attacks.
• Larger keys impose higher CPU costs to verify and sign email.
• Keys can be replaced on a regular basis; thus, their lifetime can be relatively short.
• The security goals of this specification are modest compared to typical goals of other systems that employ digital signatures.

1024-bit should be fine, especially with key rotation and the lower impact to security when compromised vs private keys for other security purposes. 2048-bit should place more of our audience at ease, where those that prefer the perks of smaller key sizes are advised to adopt ECC keys (supported with rspamd, along with RSA fallback).

NOTE: Each commit has a message detailing changes, may provide extra context for review or easier to follow diffs.

Type of change

• Improvement (non-breaking change that does improve existing functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update (DONE)

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (README.md or the documentation under docs/)
• New and existing unit tests pass locally with my changes