On 7/20/2015 2:02 PM, David Conrad wrote:
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.
You presume wrong. You grabbed the question from the wrong end.
There are 4 states a client can be in: a) not running the protocol and
not up to date, b) not running protocol and up to date, c) running the
protocol and not up to date, and d) running the protocol and up to date.
The server can only detect three different states - a) not running the
protocol, b) running and no up to date, c) running and up to date.
The decision with respect to "clients ... would see some benefit..."
has to be based on what the servers know. And I would assume an (a -
not running the protocol) is going to counted as "we don't know so we
have to assume that they aren't up to date". Transitioning from (a) to
(b) still gives you "not up to date" and acts as a no vote to updating
the KSK (just like not implementing the protocol). Transitioning from
(a) to (c) gives the root an indication that it *can* transition, but
that's not really a "benefit to the client".
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?
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. The fact that this is limited to the set of trust
anchors doesn't make it less sensitive.
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.
So would I. But its still an issue until its resolved.
All of these operation concerns need at least tentative buy in from the Root
zone ops
Yes. Perhaps something like RSSAC-002?
Actually, not this but maybe the next version after you get buy in for
additional work.
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?
(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.
It doesn't. It alters the privacy profile of the clients.
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?
Serious question - how does one monitor the progress of resolvers
actually implementing DNSSEC validation? Note that merely querying for
DNSSEC data does not actually reveal how the resolver is using the data,
nor does it reveal the current set of trust anchors.
To answer your question (and mine)- "statistically" and with great
difficulty. 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); you're going to have large providers like Comcast that
don't do 5011, but have a centrally managed system that affects millions
of end users and who are prepared to update when the new keys come out;
and you're going to have middle of the pack organizations who are
running their own resolvers, who may or may not have reasonable IT
departments - and you can reason about them by how many generations of
servers behind they are (e.g. via server fingerprinting).
Mostly, I'm unclear why we're worrying about it. We told the community
what we were going to do, they are adults. They were told this was
going to happen within 5 years and that it would be 5011. That I believe
was told to them before the root was signed? (I'm not clear of the
timing). We can't hand hold everyone and the longer it takes to roll
the root, the harder it will be.
At this point, implementing new functionality is pretty much a
non-starter. It's 6 months to RFC, 18 months or more to resolver and
server implementation, 36-54 months to deployment and configuration and
60 months to gaining enough data. And then another 2 years before you
actually decide what to do with respect to the root. Call it 2022. I
may be wrong about timing, but its unclear that I'm wrong in the
direction of too much time.
Later, Mike
Thanks,
-drc
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
