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.
pgpFr4Or7E7QD.pgp
Description: PGP signature
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
