I've taken a brief look at Warren's as yet unpublished draft (attached
to the meeting agenda) and had a few comments.
My major objection to this type of approach is that it doesn't pass the
"cui bono" test. 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). The
cost to implement this on the client side is pretty close to the cost to
implement 5011 (and in fact it uses similar timings). And generally, I
would guess that the folk that are going to implement this are the ones
already doing 5011 and not all of them, so we're not really going to get
a complete data set at the root. (Logically, if you had to implement
this, would you concentrate on something that will actually allow
automatic rollovers or on something that's just reporting you can't do
it?) [Note: My belief is that it's not as simple as just upgrading to
the new software. 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]
Then there's the root operator problem and the data reduction problem.
The root ops all have to set up support for this new option - hopefully
that will be minor, but adding new things to the root servers is always
fraught. Once they do, they have to have sufficient logging space to
collect the data and be willing to do it over a period of time.
Finally, someone has to be willing to do the data reduction. All of
these operation concerns need at least tentative buy in from the Root
zone ops and probably an assignment of resources at ICANN for the data
reduction. (And someone noted privacy issues at the microphone).
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.
And then there's the sunset problem. This is only useful (if at all)
for a short period of time, and then it becomes extraneous. e.g. For a
while before the first rollover and then for a while after. At that
point we've either had a disaster or we haven't had one. Its unclear
that long term collection of the data adds value vs causing enough pain
on the client side to get them to "do the right thing" with respect to
automated updates.
The above are comments on the utility of the data collection part. I'm
going to think a little more on whether or not this could provide
similar security guarantees as does 5011 if it were used for trust
anchor rollover. I'm not sure that it can deal with even a single key
compromise and that was one of the basic design criteria driving 5011.
Later, Mike
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
