
<html><head></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="ApplePlainTextBody"><div class="ApplePlainTextBody"><br><br>On Mar 15, 2019, at 4:30 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:<br><blockquote type="cite">It seems that these issues exist if there are *any* keys generated before use, independently of the number of keys.<br></blockquote><br>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.<br><br>It might be simplest to let resolver software bake whatever "current key"it likes, 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.<br><br>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.<br></div></body></html>