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. 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. Having checked with Paul Hoffman last night, I have a slightly different version of the suggestion I made. 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. The second is to add a more modern signing algorithm. Paul suggests EdDSA with the ED25519 profile. 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. For coding purposes, the minimum key size is just a parameter, and I would be astonished if changing the key size added as much as two lines of code to the implementations. Changing algorithms turns out not to be much harder -- the DKIM or ARC application calls signing and verification routines from a crypto library, and a different algorithm just means calling a different routine. A practical issue is that the most popular crypto library, OpenSSL, hasn't added EdDSA yet. They're currently on 1.0.2, and say it's supposed to be in 1.1.1 which will be released when it's released. So I'd suggest adding EdDSA to the spec, but not expect people to implement it yet. Then we can back-port the change into DKIM with what I hope would be a two-page update. This suggests a tweak to the ARC spec that we should make anyway. The way you do an algorithm migration, like the one we did from rsa-sha1 to rsa-sha256 is to put two signatures on the message for a while, one with the old algorithm and one with the new one. So a validator ignores signatures with algorithms it doesn't understand, and if there are two valid signatures with the same i=N using different algorithms, just pick one. R's, John _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
