Mike, On Jul 20, 2015, at 6:02 PM, Michael StJohns <m...@nthpermutation.com> wrote: > Basically, the major benefit from this is not to the clients who have to > implement the "query occasionally so the root knows what I know", but to the > root operators (or not even them maybe).
Presumably, the clients who have not yet migrated would see some benefit if the old KSK is kept around until they get around to updating it. My understanding of Warren's draft is that it provides a way for the root trust anchor authority to have a clue about how many people have moved to the new key. > I believe that this will need to be manually turned on by the resolver owner > to deal with the possible data leaking threat rather than just being on once > you update. And I almost say "no" to "do you want to help improve our > software" types of prompts] This seems to be an odd way of viewing the approach Warren is proposing. The client is sending a query asking what the trust anchor is and if it has changed. A side effect of that query is an indication to the server operator of who is using what trust anchor. I'd view it more like the queries most operating systems send to see if they have any updates waiting. As to a "data leak", I'm curious as to the threat model you're imagining. AFAICT, the leaked information would be the keyid of the resolver. For this to be of value, it would suggest the attacker would (a) either be at a root server (instance) or be in the path of the query and (b) have compromised the key reflected by the keyid. Am I missing something? > Then there's the root operator problem and the data reduction problem. AFAIK, the root server operators all, to some extent or another, collect/reduce data about what queries are hitting their system (whether they make that information known outside their organization is a different question). For those root server operators that are collecting data, I would hope the root server operators would be willing to answer a question along the lines of "what percentage of queries are still using the old trust anchor?" from the root trust anchor authority. > All of these operation concerns need at least tentative buy in from the Root > zone ops Yes. Perhaps something like RSSAC-002? > and probably an assignment of resources at ICANN for the data reduction. You mean like https://github.com/dns-stats/hedgehog/wiki/About? > (And someone noted privacy issues at the microphone). I am unclear how Warren's draft alters the privacy profile of the root servers in any way. > Then there's what do you do with the data when you get it? Considering > there's no hope at all that everyone will implement this, we will ALWAYS get > an answer that says "someone hasn't done everything they need to do to roll > the root" of some vague size. Very true. It then turns into a policy question of how much breakage is enough to not risk rolling the root. However, I personally believe having at least some data in order to inform policy questions is better than none, and if nothing else, Warren's draft would set a lower bound on potential breakage. A serious question: how does one monitor the progress of resolvers migrating to the new KSK via 5011 rollover? Thanks, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
