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