Hi Everyone,
During a discussion about the ARC protocol yesterday the question of
appropriate key sizes came up. The ARC proposal simply adopts the
guidelines for signing keys as laid out in RFC 6376.
Those guidelines are in section 3.3.3 of RFC 6376 (
https://tools.ietf.org/html/rfc6376#section-3.3.3). They specify that
receivers MUST validate signatures of 512 to 2048 bits, but are not
required to validate signatures with longer keys - may be worth revisiting
given advances in computing power, the increasing importance of DKIM as an
element of email authentication, and the reuse of these guidelines in other
proposals (i.e. ARC).
I'd like to suggest that it may be a good idea to increase the upper value
to 4096 or even 8192, to ensure that the standard is compatible with best
practices going forward.
Some motivations for revisiting the key size requirements are:
- 2048-bit keys are starting to become more common, with at least one
large sender (GSuite by Google) defaulting to 2048 bit keys.
- The TXT records for most 2048-bit keys exceed 512 bytes, so mandatory
support for 2048-bit keys already requires receivers and senders to support
EDNS or TCP fallback for DNS. An increase to 4096 (or even 8192) bits will
not change the required level of DNS support
- While key rotation can somewhat mitigate the security risks of using a
smaller key, in practice most real-world DKIM key implementations have not
made such rotation part of their systems, and hence in-practice the
mitigation is minimal
- The extension of these guidelines via ARC to forwarders, mailing
lists, etc. that are even more likely to keep their keys unchanged for long
periods of time.
Is there any interest in the group to discuss this question and how we may
be able to improve the current guidelines?
Thanks.
Best,
Peter
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html