Subject: [DNSOP] Warren's DNSSEC root update draft

From: Michael StJohns <[email-masked]>
Date: Mon, 20 Jul 2015 12:02:30 -0400

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

---

From: George Michaelson <[email-masked]>
Date: Mon, 20 Jul 2015 18:18:21 +0200

a long lived mechanism is in-band, not using labels in the DNS or query
payload.

bits in the EDNS space, indicating yes-no and where more than bits are
needed, explicit field:value definitions will get us further.

because they demand code change they can only inform us of the future.

warrens mechanism admits of being able to use a cronjob from a host,
through a resolver, to indicate you know, as the admin, what you say it can
do.

-g

On Mon, Jul 20, 2015 at 6:02 PM, Michael StJohns <[email-masked]>
wrote:

> I've taken a brief look at Warren's as yet unpublished draft (attached to
> the meeting agenda) and had a few comments.
>
> 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]
>
> 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).
>
> 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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: David Conrad <[email-masked]>
Date: Mon, 20 Jul 2015 20:02:22 +0200

Mike,

On Jul 20, 2015, at 6:02 PM, Michael StJohns <[email-masked]> 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.

> 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?

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

> All of these operation concerns need at least tentative buy in from the Root zone ops

Yes. Perhaps something like RSSAC-002?

> and probably an assignment of resources at ICANN for the data reduction.

You mean like https://github.com/dns-stats/hedgehog/wiki/About?

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

> 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?

Thanks,
-drc

---

From: Michael StJohns <[email-masked]>
Date: Tue, 21 Jul 2015 03:07:19 -0400

> 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…

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

> 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 w…

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

So would I.  But its still an issue until its resolved.
> Yes. Perhaps something like RSSAC-002?

Actually, not this but maybe the next version after you get buy in for 
additional work.
> You mean like https://github.com/dns-stats/hedgehog/wiki/About?

Tools are cool.  I assume you're going to fund the people?

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

> 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

---

From: David Conrad <[email-masked]>
Date: Tue, 21 Jul 2015 10:32:32 +0200

Mike,

On Jul 21, 2015, at 9:07 AM, Michael StJohns <[email-masked]> 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.

> 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?

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

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

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

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

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.

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

---

From: Michael StJohns <[email-masked]>
Date: Tue, 21 Jul 2015 04:55:17 -0400

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

> 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 c…

Fund the people to do the actual data reduction and report back to the 
community the result of your experiments....????

> 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 mentio…

You may not.  The resolver operators may.  YMMV.
> 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 a…

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

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

---

From: Petr Spacek <[email-masked]>
Date: Wed, 22 Jul 2015 10:01:41 +0200

On 21.7.2015 10:55, Michael StJohns wrote:
>> 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.

I oppose this. It is very much to benefit of the client to inform us that the
client is not ready for roll-over. We may decide not to break it if we know
that it is not ready.

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

This whole debate is about MUST vs. SHOULD (opt-in/out), is that right?

-- 
Petr Spacek  @  Red Hat