> > 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.
+1, with the suggested modification that ARC says that keys SHOULD be 2K or larger. Verifiers should be required to support keys from 1024 bits up to some larger value like 4096 bits, to give some future proofing for anyone who really, really wants to use RSA. As John notes, there's not much difference between handling 2K, 4K, or 8K keys from an implementation standpoint. > 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. I strongly support the idea of adding a more modern signing algorithm as part of ARC (and ideally eventually backport support to DKIM). RSA and DSA are no longer state of the art. The specific suggestion he conveys from Paul (EdDSA with the ED25519 profile) sounds in line with current best practices, and is widely used and supported ( https://ianix.com/pub/ed25519-deployment.html). And the smaller key size obviously helps mitigate the broader DNS TXT record length concern. 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. +1 Best, Peter On Mon, Jan 23, 2017 at 7:49 AM, John Levine <jo...@taugh.com> wrote: > In article <CAL0qLwbYXLn1Z8QHEg=Znn3Os5BC4WnTtHXAgkAECuKsLqfVWQ@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 > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder pe...@valimail.com +1.415.793.5783
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
