On 7/21/2015 4:32 AM, David Conrad wrote:
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.
And that's the point. It's not a benefit to the client. It's a benefit
to the server.
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?
On about half of them I disable things. I never, ever allow them to
automatically install software. But the key point is that I personally
decide whether or not to allow the software to send the probes in the
first place - e.g. OPT IN as I indicated above. I pretty much say
"NO" to "do you want to help us improve the product by sending blinded
data" questions and I'm pretty sure that's not an unusual approach for
other IETF attendees.
You cannot assume that every single new installation of modified client
code to do Warren's stuff will agree that sending the root this data is
of use to them, and they may not agree to enable the protocol. I pretty
much believe you need to give them the option to say no.
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.
Fund the people to do the actual data reduction and report back to the
community the result of your experiments....????
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.
You may not. The resolver operators may. 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.
Not if you go buy a few of these... or ask various people to run a set
of tools or to describe what the various boxes do.
Hence "statistically".
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.
I'm sad you believe this. If this were the case, then we would tell
exactly them as they would be the only ones who actually implemented DNSSEC.
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.
ublic key delivery
The public component of a Trust Anchor will be distributed in a
secure fashion to preclude substitution attacks.
Acceptable methods for delivery and validation of Trust Anchors
include, but are not limited to:
o In-band as zone data in DNSKEY RRset, with proof traceable to the
previous Trust Anchor as described in RFC 5011 [RFC5011].
o Publication of the Trust Anchor on ICANN's web site, protected and
authenticated via TLS/SSL, while also providing detached OpenPGP
[RFC4880], S/MIME [RFC5751] and other signatures traceable to
ICANN and optionally other parties.
o Proof distributed out-of-band directly to the witnesses
participating at the key ceremony, whereas distribution to their
respective communities is at the witness' own discretions.
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)
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
