On Feb 20, 2019, at 1:39 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Tony Finch <dot@dotat.at> wrote:
Fred Baker <fred@isc.org> wrote:
The key consideration is that key rollovers are a "usual" event, and as such the key(s) should be something learned from the root and the root servers, not something configured or compiled into the resolver software.
+1
I agree that rollovers need to be routine (I think annual makes sense) but they have to be planned with software releases in mind. This might require keys to be generated and promulgated out of band a long time before they are published in the zone or used for signing. Then a vendor package can include root keys covering the next couple of years, say.
I think that there is very little incremental cost to including a multitude of keys in a software release. i.e. rather than 1 or 3 for the next 3-4 years, I'd like to around a dozen. With a variety of algorithms, keysizes, and with the private keys escrowed in a variety of ways. Some will be expired without ever been used... they are just in case, or in support of as-yet-unknown contingencies. (including fire-drills for such switches) I'd like for this to include a hash-based signature system, but I'm not sure we have the standards specifications for this nailed down sufficiently.
There are two hash-based signature schemes that have been reviewed by the IRTF CFRG, one is already and RFC and the other is in the RFC Editor queue. Both of them have huge signature values, which would be an interesting challenge in the DNSSEC environment. I think we should be using hash-based signatures to sign software and firmware. They will give us authentication and integrity protection even if a large-scale quantum computer gets invented soon. That will allow us to deploy the next generation when we know what that looks like (see https://csrc.nist.gov/projects/post-quantum- <https://csrc.nist.gov/projects/post-quantum-cryptography>cryptography <https://csrc.nist.gov/projects/post-quantum-cryptography>). Russ