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

From: Warren Kumari <[email-masked]>
Date: Mon, 29 Jun 2015 16:48:53 -0400

Hi all,

So, there is a project underway to roll the DNSSEC root key. There has
been much written about this, including SAC063
(https://www.icann.org/en/system/files/files/sac-063-en.pdf[0]), a
DNSSEC Root KSK Rollover Plan Design Team, various consultations with
the community, many presentations at DNS-OARCs, etc.

One of the biggest impediments to actually performing the rollover is
that some set of folk will not have performed RFC5011 style rollover,
whether because their software doesn't support 5011, because they have
statically configured a TA, because the bigger response makes them
sad, whatever. The fact that we cannot tell who has only has the old
key, and who has both makes the keyroll very scary - we cannot predict
who, and how wide scale the outage will be when the old key is
removed.

I've written a draft that proposes a different way of performing root
key rollover that exposes who all has which key - this allows one to
know that 99.8% of resolvers have the new key, who has the old one,
and who will break.
It does this by encoding the current set of TAs that the resolver has
into a query, and using that to fetch the new keys. By watching
queries at the root one can see the population of people with each TA,
and watch that change over time. This was written for root key roll,
but is applicable to any TA in the tree.

I'd appreciate any feedback, the draft announcment is here:
Name:           draft-wkumari-dnsop-trust-management
Revision:       00
Title:          Simplified Updates of DNS Security (DNSSEC) Trust Anchors
Document date:  2015-06-29
Group:          Individual Submission
Pages:          8
URL:
https://www.ietf.org/internet-drafts/draft-wkumari-dnsop-trust-management-00.txt
Status:
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-trust-management/
Htmlized:
https://tools.ietf.org/html/draft-wkumari-dnsop-trust-management-00

Abstract:
   This document describes a simple means for automated updating of
   DNSSEC trust anchors.  This mechanism allows the trust anchor
   maintainer to monitor the progress of the migration to the new trust
   anchor, and so predict the effect before decommissioning the existing
   trust anchor.

   It is primarily aimed at the root DNSSEC trust anchor, but should be
   applicable to trust anchors elsewhere in the DNS as well.

   [ Ed note - informal summary: One of the big issues with rolling the
   root key is that it is unclear who all is using RFC5011, who all has
   successfully fetched and installed the new key, and, most
   importantly, who all will die when the old key is revoked.  A
   secondary problem is that the response sizes suddenly increase,
   potentially blowing the MTU limit.  This document describes a method
   that is basically CDS, but for the root key (or any other trust
   anchor).  Unlike the CDS record though, this record lives at a
   special name - by querying for this name, the recursive exposes its
   list of TAs to the auth server (signalling upstream) . This allows
   the TA maintainer to predict how many, and who all will break.  It
   also allows the pre-publication of a key before using it, and so
   avoids the need to double response sizes...]

   [ Ed note: Text inside square brackets ([]) is additional background
   information, answers to frequently asked questions, general musings,
   etc.  They will be removed before publication.]

   [ This document is being collaborated on in Github at:
   https://github.com/wkumari/draft-wkumari-dnsop-trust-management.  The
   most recent version of the document, open issues, etc should all be
   available here.  The authors (gratefully) accept pull requests ]

W
[0]: Full disclosure: Author.

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 29 Jun 2015 23:59:19 +0200

Moin!

> but is applicable to any TA in the tree.
So while this might work with future root key rollovers, I think it's to 
late for this one, as it requires all software (root servers and 
validating resolvers) to be updated, and one concern that we have with 
the root key rollover is old software.

On another note, how does that interact with the root loopback draft, 
where the resolver doesn't ask the root at all, but the local copy of 
the root zone?

So long
-Ralf

---

From: manning <[email-masked]>
Date: Mon, 29 Jun 2015 16:04:17 -0700

This looks very much like the draft that Olaf, Johan, and I wrote at the same time MSJ was proposing what we have now.
You might want to talk to either Olaf or Johan for more details.   And yes, this will fail if any of the loopback drafts are deployed.

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 29June2015Monday, at 14:59, Ralf Weber <[email-masked]> wrote:

> So while this might work with future root key rollovers, I think it's to late for this one, as it requires all software (root servers and validating resolvers) to be updated, and one concern that we have with the root key rollover is old software.
> 
> On another note, how does that interact with the root loopback draft, where the resolver doesn't ask the root at all, but the local copy of the root zone?
> 
> So long
> -Ralf
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: David Conrad <[email-masked]>
Date: Mon, 29 Jun 2015 16:28:34 -0700

Bill,

> You might want to talk to either Olaf or Johan for more details.

Don't suppose anyone has a copy of that draft?

> And yes, this will fail if any of the loopback drafts are deployed.

Sorry, I must be missing something obvious. Why?

Regards,
-drc

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 29 Jun 2015 19:28:52 -0400

There is much simpler way.
Just add record to the rootzone that is only signed by the new key.
If resolver returns AD bit it has the new key.

All that is needed is to sign a Rrset for a long time and add it at to the
rootzone and make sure no ZSK signs it.

Olafur

---

From: Warren Kumari <[email-masked]>
Date: Mon, 29 Jun 2015 19:32:04 -0400

On Mon, Jun 29, 2015 at 5:59 PM, Ralf Weber <[email-masked]> wrote:
> late for this one, as it requires all software (root servers and validating
> resolvers) to be updated, and one concern that we have with the root key
> rollover is old software.

Well, yes and no. I'd also through that there was no point in trying
to get this done soon -- but then, after chatting with some folk, I
have reconsidered that position...

*When* exactly the root key will actually roll is still unclear --
I've heard estimates from "the middle of next year" to "sometime in
2018 or 2019". I'm starting an informal poll - my choice is July 2017.
If folk send me their guesses I'll collect them and we'll figure out
some sort of prize for whoever gets closest.

Anyway, let's say it *is* mid-2017, just for arguments sake.  Let's
also say that ISC and Unbound decide to implement this (much of the
logic is already in there), and have it done by mid 2016 (that's
~1year). There is a *really* long tail of people who don't upgrade
their name-servers, but there are also a whole bunch who do,
especially if there is a security announcement / issue that gets
patched. Let's say 10% of people upgrade (note that these are not the
ones that are likely to have a key-roll issue, kinda by definition).
Whatever the case, at least there will be *some* visibility at the
root of the people who are not likely to go "Boom".

IANA can publish the _tag record for the new key, or they can just
rely on RFC 5011 (note that this doesn't preclude using RFC5011) -
whatever the case, there will be a signal. If they choose to publish
the _tag record, it will save those people who are A: upgraded and B:
unable to get large responses...

>
> On another note, how does that interact with the root loopback draft, where
> the resolver doesn't ask the root at all, but the local copy of the root
> zone?

I think it is OK -- the draft-ietf-dnsop-root-loopback draft says that
resolvers download the root zone and serve it on their loopbacks.
Compliant resolvers will then query themselves and this will Just
Work. You do lose most of the purpose of this, which is to get
visibility -- but, those name-servers are not *really* querying the
root, and so... well...
draft-ietf-dnsop-root-loopback is also really designed for niche cases....

W
[0]: This contest void where prohibited, not open to ICANN / IANA
employees and their immediate families, bribery not allowed, unless I
get a cut too...

---

From: Warren Kumari <[email-masked]>
Date: Mon, 29 Jun 2015 19:33:47 -0400

> rootzone and make sure no ZSK signs it.

... and know where the nameservers are, and be able to query the
nameservers to see if they are returning the AD bit. This requires
that they are open recursive, that IANA (or someone) is able to query
them, or something similar...

Unless I've completely misunderstood?

W

---

From: Paul Vixie <[email-masked]>
Date: Mon, 29 Jun 2015 16:37:00 -0700

Olafur Gudmundsson wrote:
> All that is needed is to sign a Rrset for a long time and add it at to
> the rootzone and make sure no ZSK signs it.
>

this.

-- 
Paul Vixie

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 29 Jun 2015 19:42:24 -0400

Atlas probes can help us we can even measure this from webpages,
cellphones, OS updates can add a test etc.

Olafur

---

From: manning <[email-masked]>
Date: Mon, 29 Jun 2015 17:03:00 -0700

Why, yes, I still do.  (and it can be found in the IEtF archives)  https://tools.ietf.org/html/draft-ietf-dnsext-trustupdate-threshold-01

As to why,  perhaps I am missing the obvious, but if SUDSTA proceeds, does it matter if the origin IP of the root zone being served
is sporadically distributed?   It seems that one could not presume to have the data to assert the penetration of the new keys nor the 
origin of the stale keys, if that information was diffused through the IP address space.

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: David Conrad <[email-masked]>
Date: Mon, 29 Jun 2015 19:07:45 -0700

> origin of the stale keys, if that information was diffused through the IP address space.

Ah. I thought when you said 'will fail', you meant the scheme itself wouldn't work. Yes, we won't be able to see anyone who does root-loopback, but that is no different than the existing situation, right?

Regards,
-drc

---

From: manning <[email-masked]>
Date: Mon, 29 Jun 2015 21:20:40 -0700

> Ah. I thought when you said 'will fail', you meant the scheme itself wouldn't work. Yes, we won't be able to see anyone who does root-loopback, but that is no different than the existing situation,…

Actually, it makes it worse.   _IF_ a scheme to simplify updates comes to fruition, in todays networks there are (presumptive) a dozen+1 roots with their associated IP’s  (call it 26 ip addresses)
that need to be monitored.  The downside is the EXISTING unknown private roots who we don’t see PLUS the (again presumptive) number of new sites which will adopt root loopback to gain a
“legitimate” root nameserver in their networks.   When this happens in largish networks (lets pick on China) then we will have added yet another layer of operational coordination/complexity
with the need to synchronize key rollovers between (very big) islands of trust.   

So it can be made to work, but the layers of gum, bailing wire, and duct tape are, IMHO, problematic.

/bill

---

From: Tony Finch <[email-masked]>
Date: Tue, 30 Jun 2015 13:53:03 +0100

> If resolver returns AD bit it has the new key.

I don't think this works.

If the new key is published in the root zone's DNSKEY RRset then it will
be signed by the old key, so a validator will have a trust path from a
stale trust anchor down to the special record (just like it does for
records signed by ZSKs).

If the new key is not published in the root zone, then you are assuming
that the validator uses DNSKEY records for its trust anchor configuration
(but some validators use DS records) and that the validator will allow any
RRset to be signed by the trust anchor (but RFC 4035 section 5 suggests
only using the trust anchor to validate the apex DNSKEY RRset).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon, Rockall, Malin: South 5 to 7, occasionally gale 8 at first in
Rockall, decreasing 3 or 4. Moderate or rough, occasionally very rough except
in Malin. Rain then fog patches. Moderate, occasionally very poor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 30 Jun 2015 09:09:42 -0400

> On Jun 30, 2015, at 8:53 AM, Tony Finch <[email-masked]> wrote:
> 

> only using the trust anchor to validate the apex DNSKEY RRset).

I think it works some of the time i.e. 
if one or more of the following are true 
a) If the trust anchor is maintained by operator and operator saw advertisement and acted upon 
b) if the new key is advertised by 5011 protocol long before it is rolled and then removed 
c) If the New key is advertised via CDNSKEY and is picked up via trust anchor maintenance 
but most importantly: 

d) the Trust anchor is maintained by storing the DNSKEY when possible[*]

So this is not perfect mechanism, will give us an idea how many Validators picked up the new trust anchor 
and then we can start the real propaganda campaign. 

My bullet b) is a change from the root key rollover plan that assumes that new key is added just before it is used. 
I would propose that 5011 advertising  is done multiple times before the rollover and the new key is removed during the ZSK rollover,
to allow testing. 

I do not yet propose what name or record is used for this experiment but having it an “address of an object” would be good as that
enables testing from browsers. (CNAME is just as good as an address) 
 
    Olafur

Ps: based on my quick check of unbound and Bind both store DNSKEY’s,  I do not know how Nomininum, Microsoft and/or DNSMasq store it. Large public resolvers like Google are likely to do this via configuration

---

From: John Dickinson <[email-masked]>
Date: Tue, 30 Jun 2015 14:34:26 +0100

> https://tools.ietf.org/html/draft-wkumari-dnsop-trust-management-00
Hi,

This draft appears to be trying to solve several problems.
1. Signalling by a validator to an authoritative server which keys it 
knows about.
2. Signalling by an authoritative server the mechanism it is using to 
roll it's keys
3. Defining an alternative to 5011 with a different mechanism to roll keys.

This seems a big ask for one draft.

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.

For problem 2 I was going to suggest advice to implementers of 
validators to (by default) treat all TA's as potentially 5011. A non 
5011 TA is just one that is never seen to do 5011 stuff.

Given the above, My feeling is that there is no need to propose an 
alternative to 5011 unless it adds a significant increase in 
security/ease of use.

In addition, if I have understood your intent correctly, I have a few 
questions regarding the security of your proposed mechanism.

Assuming the traditional large (strong) KSK used as trust anchor and 
smaller ZSK scenario.
It appears that the TDS RRSet will be signed only by the smaller ZSK. 
Doesn't this effectively create a circular dependency that effectively 
reduces the security of the zone down to the strength of the ZSK?

You mention nothing like the add hold down timer in 5011. There seems to 
be good justification its need in 5011.

regards
John

---

From: Tony Finch <[email-masked]>
Date: Tue, 30 Jun 2015 14:52:08 +0100

Olafur Gudmundsson <[email-masked]> wrote:
>
> I do not yet propose what name or record is used for this experiment but
> having it an “address of an object” would be good as that enables
> testing from browsers. (CNAME is just as good as an address)

But my point is you can't find out a validator's RFC 5011 state using the
AD bit. There is no way to get AD for one key and not for another key.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Utsire: Variable 4 becoming southeasterly 4 or 5. Slight, becoming
slight or moderate. Mainly fair. Good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Tue, 30 Jun 2015 14:57:41 +0100

John Dickinson <[email-masked]> 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.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger: South or southeast 4 or 5, increasing
6 at times. Slight or moderate. Mainly fair. Moderate or good.

---

From: manning <[email-masked]>
Date: Tue, 30 Jun 2015 07:22:04 -0700

unless, of course, DNSSEC allowed for signing individual records instead of zones.

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Edward Lewis <[email-masked]>
Date: Tue, 30 Jun 2015 14:53:35 +0000

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

>>send

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.)

---

From: Warren Kumari <[email-masked]>
Date: Tue, 30 Jun 2015 15:59:40 -0400

On Tue, Jun 30, 2015 at 9:34 AM, John Dickinson <[email-masked]> wrote:
> 1. Signalling by a validator to an authoritative server which keys it knows
> about.
> 2. Signalling by an authoritative server the mechanism it is using to roll
> it's keys

I think it is more just:
1: Signalling by a validator to an authoritative server which keys it
knows about.
3: Defining an alternative to 5011 with a different mechanism to roll keys.

An auth server *can* include a TDS record to signal that it supports
TDS (your #2), but it doesn't have to stop doing 5011. If it doesn't
publish the record, it still gets the signalling information.

This mechanism works with 5011 if that is what the auth server want to use.
An auth can:
A: use 5011 AND NOT publish a TDS record -- everyone will use the 5011
logic. The auth servers will still get the queries for the TDS record
from new clients, and so will be able to see the population change
(from new clients).

B: use 5011 AND publish a TDS record -- new clients will do the TDS
processing, older clients will still follow 5011 logic. The auth
server will still be able to follow the population change (from new
clients) (I need to add a priority section explaining what to do if
you support both TDS and 5011)

C: only use TDS - new clients will do TDS processing, old ones will
simply die when the roll happens. The TA maintainer will at least know
who all will die - those folk who talk to the root, but don't ever
send a TDS query. This is, um, not recommended :-)

> the DS of known TA's in an edns0 option code. This info, could then be
> logged by the authoritative nameservers.

Inserting it in edns0 implies (I think) that all of the queries will
contain this, which seems like a fairly big query size / efficiency
hit. I guess you could just do it every N queries, or M time, or
something. Very similar idea though...

I could simply pull all of the "and then install the new TA" stuff out
of the draft, and this could just be signaling of what TAs are
deployed.
I suspect that simply including a signalling mechanism that announces
what you know, without tying it to getting something in return, will
not get as widely deployed -- where is my incentive to send this? "To
be a good citizen" doesn't work as well as it used to / should :-( The
implicit suggestion that TDS may end up being the preferred mechanism,
and removal of the need to double-sign provides an incentive to do
this -- "I'll show you mine if you show me yours..."

>
> For problem 2 I was going to suggest advice to implementers of validators to
> (by default) treat all TA's as potentially 5011. A non 5011 TA is just one
> that is never seen to do 5011 stuff.

RFC 5011 requires significantly increasing the response sizes / double
signing. It is unclear if this really is a problem or not, but some
folk believe it is...

> alternative to 5011 unless it adds a significant increase in security/ease
> of use.
>

I think it *does* provide a significant ease of use / operational win
over RFC5011-- it provides an incentive to report your TA set (you
need to, to get the next TAs), and also doesn't require increasing the
response size. It is unclear if this is a good enough tradeoff. It
might not be. Decoupling the signalling from the roll, and not
providing a 5011 alternative is, um, an alternative :-)

> Assuming the traditional large (strong) KSK used as trust anchor and smaller
> ZSK scenario.

Hmmm. Good point. This may be a major issue... You could require that
the TDS records be signed by the KSK (like the ZSK), but this feels
like it may be hackish...

> You mention nothing like the add hold down timer in 5011. There seems to be
> good justification its need in 5011.

Yup, you are right. I had initially stuffed some text in the draft
saying that you simply follow all of the RFC5011 key timing logic /
parameters, but this didn't really seem to fit very well for some
cases. Rather than rewrite all of the 5011 timing stuff I decided to
publish this and get initial feedback. The draft still needs
significant work  before it would be finished, the full timing, much
better examples, the IANA section, the security section, priority of
5011 vs TDS, etc are included in that...

Anyway, thank you for reading and providing feedback, hopefully we can
make this better and / or remove the roll part and / or decide it is
not worth pursuing....

W

---

From: Warren Kumari <[email-masked]>
Date: Tue, 30 Jun 2015 17:18:08 -0400

On Tue, Jun 30, 2015 at 10:53 AM, Edward Lewis <[email-masked]> wrote:
> trust anchor?

I think that there is a philosophical and operational difference
between asking other validators what TA they have, and expecting them
to volunteer the information to you.

Having the user of a TA come along and report that it is using the TA
*feels* less intrusive than going off and asking it.

There are also operational issues with asking each TA user, including:
- you have to be able to find them - they may be behind firewalls / NATs
- they may have ACLs that prevent them from being queried by random
people (they really should have this!)
- you could scan for them, but this could be (and often is) viewed as
anti-social. You could simply look through logs and query each address
that asks you -- but a number of resolvers send their outgoing query
on a different interface than they accept queries on
- you could make some addresses "special" and expect resolver
operators to allow queries from this special address, but this is is
kinda icky, still doesn't address FW and NATs, nor finding them
-- this also opens the system to a DoS from A: all or B: the (spoofed)
special address
- you could have probes or sensors all over the place perform the
query and ship that to a central location
-- this requires a lot of additional infrastructure
-- getting probes that reach everywhere is really hard - Atlas is
good, but quite biased to some geographies and networks with clue.
Geoff Huston's Ad network system gets really good coverage, but
requires a bunch of machinery, and still doesn;t get full coverage.

Having the resolver send it's list to the server(s) serving the zone
with the TA is much simpler:
- it feels more opt-in
- the resolver knows where the auth servers are, and can reach them
- it doesn't rely on a bunch of other infrastructure
- gets coverage from resolvers in e.g corporations, remote geographies, etc.

> Should the source of the trust anchor build a process

"Did everyone get the new trust anchor?" Well to tell you the truth in
all this excitement I kinda lost track myself. But being this is the
root trust anchor, the most powerful TA in the world and would break
your Internet completely, you've gotta ask yourself one question: "Do
I feel lucky?" Well, do ya, punk?"
  -- with apologies to Dirty Harry.

Ideally you shouldn't have to rely on knowing who has, or who does not
have the trust anchor -- but, without this information you have no way
to predict what the impact of the keyroll will be and who all will be
affected - you are basically flying blind.

> it was known that everyone out there had the new trust anchor in place.

Yes, it would be perfect -- unfortunately I don't think you'll ever be
able to tell that /everyone/ has the new TA.
But, if someone handed me a black box, and said "Pulling this lever
will make life X% safer for Y% of people, but will significantly
negatively impact Z% of people" I'd want to know what exactly X, Y and
Z are. If I couldn't get better answers than X="some", Y="a bunch" and
Z="not very many... probably" I don't think I'd be able to, in good
conscience, pull the lever. I know that I sure wouldn't want to be in
that situation...

> configuration data?  (At what point does this become Snowden-esque?)

What if people came along and *told* you, instead of you asking? They
way you are not prying / snooping as much -- and people who don't want
to tell you are (implicitly) agreeing to take care of themselves. I
don;t think that someone saying "I'm using TAs #23 and #42 are really
leaking private information to you, the operator of the TA, any more
than them asking "what are the NS for .com?" -- actually, I think it
is much less info that is being leaked...

> documentation, and then go ahead with the change.

Yup. If you cannot determine who all has the new TA, I think all you can do is:
1: Get the word out to as many people as you can, so they can A: get
the new TA and B: build a contingency plan. This means a wide,
intensive communications plan, not just the DNS geeks who happen show
up at OARC and DNSOP - they are not your audience...

3: Do as good a job at estimating the impact as you possibly can. This
includes trying to figure out the distribution of nameserver software
out there, how many users use what set of resolvers, if the top N will
have the new TA, etc. Then make a decision just what the risk vs
reward numbers are -- if you are 90% sure that 99.999% of people will
be fine, is this acceptable? 40% sure that 82% of people will be fine?

4: Figure out what to do if things go pear shaped -- if you estimated
99.999% of people will be OK, but you discover it is only 92%, what do
you do?  If it is unacceptable, how you you roll back -- and then
what?

5: You should collect as much info as possible during the roll, so
next time this isn't as painful...

Or, put another way -- SAC063 (full disclosure: contributor):
Recommendation 1: Internet Corporation for Assigned Names and Numbers
(ICANN) staff, in coordination with the other Root Zone Management
Partners (United States Department of Commerce, National
Telecommunications and Information Administration (NTIA), and
Verisign), should immediately undertake a significant, worldwide
communications effort to publicize the root zone KSK rollover
motivation and process as widely as possible.

Recommendation 3: ICANN staff should lead, coordinate, or otherwise
encourage the creation of clear and objective metrics for acceptable
levels of “breakage” resulting from a key rollover.

Recommendation 4: ICANN staff should lead, coordinate, or otherwise
encourage the development of rollback procedures to be executed when a
rollover has affected operational stability beyond a reasonable
boundary.

Recommendation 5: ICANN staff should lead, coordinate, or otherwise
encourage the collection of as much information as possible about the
impact of a KSK rollover to provide input to planning for future
rollovers.

> risk?

No, it is the responsibility of the source of the trust anchor to be
responsible -- this does not mean avoid all risk, rather *minimize the
risk* and only proceed when the risk vs reward payoff makes sense.

> Or is it the responsibility of the players on the Internet to
> handle all risk?

Ideally yes -- but that is like saying that it is the responsibility
of the person holding the gun not to shoot themselves in the foot.
There are many cases (including children, and myself) who cannot be
trusted with this responsibility. Many people don't even know that
they have the responsibility - they took over from someone else, they
installed a piece of software that enabled this, etc.
People should all understand how their DNS works, and what all the
important bits are -- but, people should also know how their cars work
and what all the important bits in the engine do. Unfortunately
neither of these are true.

>  In my mind, DNSSEC is about protecting the recipient,
> has.

Me too!

> Don't get me wrong, more data is helpful.  I'd live to have what I

Yah, me too! Luckily (for me!) I'm not the one who has to make any
decisions here. I can sit on the sidelines making snide comments...

> checksum than error correcting code.)

That's an option. Pulling the keyroll logic out of the draft would
make it shorter and simpler. Not necessarily better, but that's what
these threads are for....

W