On 27Jan15, A. Schulze allegedly wrote:
Hello everybody,
Murray encourage me to ask here:
https://tools.ietf.org/html/rfc6376#section-3.3.3 say
"Signers MUST use RSA keys of at least 1024 bits for long-lived keys."
and
"Verifiers MUST be able to validate signatures with
keys ranging from 512 bits to 2048 bits, and they MAY be able to
validate signatures with larger keys."
Signer using a key larger then 2048 (like I do for years now) aren't
inside the specification
because there is no MUST on the validation side.
From operational perspective I experience no drawback using 4k RSA
keys for DKIM.
I see these options:
- the signer could use smaller keys and rotate them more often
- the specification support other key types which gather same level
of security with smaller keys
( elliptic curve crypto )
- the specification REQUIRE validators to handle larger keys.
I would kindly ask for other options or advise.
On the matter of smallish keys, it was originally stressed that
validation should only occur at the time of delivery rather than many
years later, so the notion of smaller keys being vulnerable to future
technology is less of a risk. So from the perspective, shorter keys
are not as terrible. But others will disagree.
On the matter of EC and larger keys, both of those are valid
suggestions in 2015, however not so much in 2004 when many of these
original decisions were made. At that time:
o there was limited support for EDNS0 - even today it's not 100%
o (as I recall) openssl exhibited erratic behavior with 2048 < keys <
4096. This made me pretty nervous about the true level of support
for large keys in general.
o EC was nascent in 2004 - I don't recall whether there was much if
any s/w that supported it.
I don't recall how much re-evaluation of those limits was done in
later incarnations of the specs. EC at least is probably worth as it
reduces DNS payload sizes.
Of course introducing larger keys and/or a new algorithm is within the
protocol but will be quite a challenge due to the installed base.
I also note that we original had the notion of the verifier having to
choose the signature with the "most secure signing algorithm", so in
theory you could create signatures with RSA and EC, but that notion
was lost/dropped in later iterations of the specs. Perhaps it should
be revivified?
Mark.
pgpUl9sqCRtox.pgp
Description: PGP signature
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html