> On Mar 15, 2019, at 4:30 PM, Michael Richardson <mcr+ietf@sandelman.ca> > wrote: > It seems that these issues exist if there are *any* keys generated before > use, independently of the number of keys. Fred Baker <fred@isc.org> wrote: > To my mind, the argument has the issue backwards. The issue is that the > resolver needs to be able to resolve keys currently signed by the IANA, which > means that it needs to know "a" current public key to validate the DNSKEY > response. Rather than publish 2^12 keys that might or might not be used in > the future, it seems to me that it has to be able to identify *a* public key > that has been used in the past and use that to get the current public > key. I agree with you. (I think that there is a substantive difference between 2^12 keys, and 12 keys, and I think 2^12 was hyperbole... moving on) > It might be simplest to let resolver software bake whatever "current key"it > likes, I agree that having a path from the current key at time X to the current key at time Y is a good thing. I don't think it needs to be contained in . > perhaps among a set of candidates, into the software, and use > that > public key to sign the NS request to the root. If the decrypted request is > recognized by the root, it replies to the DNSKEY request with the current > key. While the math says you can encrypt/decrypt with either "public" or "private" keys, and the practice says otherwise. In particular, a) none of root name servers have the private keys online b) the root name servers are run by 13 different entities, and each has 50+ anycast nodes operating as root name servers. c) thanks to DNSSEC there is significant thinking to having recursive resolvers take a copy of the root zone by <someprotocol>, and not bothering the root name servers as often. > The attack on that would be to flood the root with requests using whatever > key might be randomly generated (or no real key), consuming the root's > resource to validate signatures. I'm not sure I have a response to that, but > it probably comes down to a cheap way to identify candidates for validation > and ignore the rest. The attackers know the real public key (it's public), so they don't have to fake it. They could put random garbage in, which I think is your point. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-