Mike, On Jul 21, 2015, at 9:07 AM, Michael StJohns <m...@nthpermutation.com> wrote: > The decision with respect to "clients ... would see some benefit..." has to > be based on what the servers know.
Yes, and the information provided by the mechanism described by Warren's draft would provide at least some information to the servers as to state of the clients. > Causing a client to emit something that isn't necessary to get the service is > generally considered a requirement for opt-in type of consideration. Do you disable "Software Update"-like probes on your operating system(s) and applications? >>> and probably an assignment of resources at ICANN for the data reduction. >> You mean like https://github.com/dns-stats/hedgehog/wiki/About? > Tools are cool. I assume you're going to fund the people? Me? No. However, if you're asking if ICANN would fund the people, you might want to look at who funded Hedgehog in the first place. Since ICANN runs a root server, I think it safe to assume we'll support continued development of features we need. >> I am unclear how Warren's draft alters the privacy profile of the root >> servers in any way. > It doesn't. It alters the privacy profile of the clients. Sorry for being unclear. Today, everyone trusts the root servers and a vast amount of (meta) data is available to anyone at or in the path of the root servers (this is the "privacy profile of the root servers" I was mentioning). Warren's draft enables the root server operators (and anyone in the path to the root servers) to be able to see the keyids the resolvers are using, presumably for validation. Given the information already available to the root servers, et al., and the fact that the querying systems that are leaking the information are (generally) not end user systems, I personally do not see any significant increase in privacy exposure risk. YMMV. >> A serious question: how does one monitor the progress of resolvers migrating >> to the new KSK via 5011 rollover? > To answer your question (and mine)- "statistically" and with great difficulty. And what data do you use to measure '"statistically" and with great difficulty' the progress of resolvers migrating to the new KSK via 5011 rollover? > You're going to have classes of devices that you can look at to see what they > would *normally* do and you'll use that to reason about the actual ones in > the wild (e.g. the home premise stuff or DNS in a box stuff); Statistically speaking, the number of machines ICANN, as the IANA Function operator and the entity responsible for managing the KSK, can look at "to see what they would *normally* do" is and will always be insignificant. > Mostly, I'm unclear why we're worrying about it. Because the root of the DNS is seen as critical infrastructure and I believe the Root Management Partners would prefer to have more information rather than less regarding how much of the Internet we're going to break. > We told the community what we were going to do, they are adults. We told a bunch of DNS protocol geeks, network operators, and a few others what we're going to do. Being adults and having a bit of responsibility, I don't believe the Root Management Partners have the luxury of being cavalier about breaking critical infrastructure. > They were told this was going to happen within 5 years and that it would be > 5011. Actually, I believe we said "after 5 years" and we did not specify the technology by which the key would be rolled. > At this point, implementing new functionality is pretty much a non-starter. I do not believe DNS software will be frozen after the first key roll. Regards, -drc (ICANN CTO, but speaking only for myself)
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
