Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key

[Edward Lewis <[e-mail]>]

On 6/30/15, 9:57, "Tony Finch" wrote:

>John Dickinson <[e-mail]> wrote:
>>
>> I have been planning to write a draft to address 1 by having validators
>>send
>> the DS of known TA's in an edns0 option code. This info, could then be
>>logged
>> by the authoritative nameservers.
>
>Good idea, though just the key tags should be enough. (I think key
>management software ensures that tags don't collide.) If you only include
>the EDNS option when querying for the DNSKEY RRset then that tells the
>server which zone to the trust anchor key tags belong to.

Is this the right path?  (I'm asking, not driving towards a solution.)

I've been one of the folks struggling with this for some time.

It's true that the key tag does not uniquely identify the key.
Operationally, most key management tools will discard potential conflicts
which is good but makes us forget the trivial point mentioned here.

There's a larger set of questions.

Should the source of a trust anchor have the right or ability to ask any
other (validating, recursive) name server whether it is holding the (any)
trust anchor?  Should the source of the trust anchor build a process
relying on the ability to know who has or does not have the trust anchor?

ICANN is looking at changing the trust anchor for the root zone.  It would
be good if, before removing/retiring/revoking the trust anchor in place,
it was known that everyone out there had the new trust anchor in place.
That would be perfect.

What's the cost?  First there is identifying all holders of the trust
anchor.  If it were a NAT-free, IPv4 world, then it would be doable with a
simple scan of all IP(v4) addresses.  But we have NAT, we have firewalls,
we have IPv6.  We have techniques folks do to either extend address
spaces, provide security, improve availability.

If we could manage to contact every DNSSEC validator out there, (so,
second question,) is it a good idea to let an outsider poke/snoop into
configuration data?  (At what point does this become Snowden-esque?)
Leaving that as an open question.

What's the alternative if it is deemed infeasible or impossible to
determine when "everyone" has the new trust anchor?  The alternative
perhaps is to make a best effort to estimate when as many as should know
do, to inform as many as one can (not having a definitive roster of the
appropriate audience), to prepare "what to do when something fails"
documentation, and then go ahead with the change.

Is it the responsibility of the source of the trust anchor to avoid all
risk?  Or is it the responsibility of the players on the Internet to
handle all risk?  In my mind, DNSSEC is about protecting the recipient,
not the publisher of data.  Does that sway where responsibility lies?

This is not a rationalization for irresponsible behavior by a trust anchor
manager - maintaining trust is larger than security, it includes
availability/usability/better than the alternatives.  This is a debate in
my mind about how to manage a change when it's nearly impossible to
measure and manage all the angles.

PS -  I would love *love* having the ability to detect and measure whether
running the RFC 5011 process had any impact at all or how much impact it
has.  Don't get me wrong, more data is helpful.  I'd live to have what I
can in terms of collectable data for this.

PPS - All this having been written, I like the idea of knowing who's
queried for what in terms of the trust anchors.  Perhaps I'd use the DS
hash as the owner name (details elided) to avoid the key tag not being
unique problem.  I wouldn't use TDS to learn keys but just to check on
whether the trust anchors are up to date - an NXDOMAIN indicating the
validator's administrator has some work to do.  (Treat this more a
checksum than error correcting code.)