> On Jan 23, 2017, at 7:49 AM, John Levine <jo...@taugh.com> wrote: > > In article > <CAL0qLwbYXLn1Z8QHEg=znn3os5bc4wntthxagkaecukslqf...@mail.gmail.com> you > write: >> I'd like to come up with something better than updating DKIM every time >> there's new advice on key sizes, etc. Doing one update that points to the >> best current advice, and then letting that other thing get updated >> whenever, would be better.
Yes. Thank you. Yes. >> Otherwise at some point we'll need to update >> DKIM and ARC, and then DKIM, ARC, and the next thing, etc. etc. >> >> But is there such a reference? > > I'm pretty sure there isn’t. https://www.keylength.com/en/ Use this site to determine what cipher suite and key length you need to meet [NIST/ANSSI/IAD-NSA/…BSI] minimum level of security. See also: https://wiki.mozilla.org/Security/Server_Side_TLS from the fine folks at https://cipherli.st. It’s a list of ciphers and key lengths that have no known (public) vulnerabilities. For at least the past few years, it has been kept impeccably up-to-date. > The first is that ARC says that keys SHOULD be 2K and MUST be at least > 1K. We understand the only likely deviation from the SHOULD to be due > to DNS crudware that can't provision larger keys. Given the short > lifetime of ARC signatures, this is cryptographically defensible. Given the half-life of IETF documents, I think this advice is still prey to the “that cipher suite / key length isn’t secure any more” problem as the existing documents. Instead, I think something like this is more appropriate: Keys SHOULD meet the minimum NIST and/or BSI recommendations (see https://www.keylength.com/). In 2017, the minimum bit length for factoring modulus keys is 2048, for elliptical curve is 256 and for hashes (SHA-*) is 256. The minimum numbers are stated and their shelf life is implied. To be secure after 2017, implementers will have to do a little bit of homework to look up key lengths, but that’s really no different than before. At least now we’re providing a reference. We should recommend secure defaults and let users of DNS crudware harangue their vendors or find new ones that can support publishing secure keys. We’re also foreshadowing long key lengths next year. > The second is to add a more modern signing algorithm. Paul suggests > EdDSA with the ED25519 profile. +1 > It was designed by well-known > civilian cryptographers with no help from the NSA, and there is a high > quality reference implementation that everyone likes. A 256 bit EdDSA > key is about as strong as a 3000 bit RSA key and the crypto operations > are faster, so that's the last signing algorithm we're likely to need. LOL. EC is currently quite robust but let’s not forget that we are but one novel new attack away from those faster crypto operations becoming a liability. Then we’ll all be jacking up our EC key lengths to compensate. Matt _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
