Subject: [DNSOP] The EDNS Key Tag Option

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 30 Jul 2015 00:09:41 +0000

Seeing Warren's recent draft on updates of DNSSEC trust anchors encouraged
me to finish and submit what I think may be a better method for tracking
trust anchor updates.  I've described an edns-key-tag option, which puts
trust anchor key tags in the EDNS OPT record.  It is modeled after RFC
6975, which is a way that clients can signal to servers the DNSSEC algorithms
that they support.

https://datatracker.ietf.org/doc/draft-wessels-edns-key-tag/

Feedback would be welcomed.

Duane W.

---

From: manning <[email-masked]>
Date: Wed, 29 Jul 2015 17:46:11 -0700

Slowly but surely,  the DNS evolves into a signaling system…. :)

manning
[email-masked]
PO Box 6151
Playa del Rey, CA 90293
310.322.8102

On 29July2015Wednesday, at 17:09, Wessels, Duane <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 29 Jul 2015 21:19:09 -0400

> On Jul 29, 2015, at 8:09 PM, Wessels, Duane <[email-masked]> wrote:
> 

Duane, 

Question: 
Validator has following TA’s configured 
. 12345  and 23456 
evil.example    9666 6669  

The if the query is for 
verisign.com <http://verisign.com/>  what TA”S are returned 
if the query is for 
www.evil.example <http://www.evil.example/>.   What TA’s are returned ? 

Olafur

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 30 Jul 2015 02:34:06 +0000

Hi Olafur,

For an RD=0 query to a name server authoritative for the "." zone the client would send 12345, 23456.

For an RD=0 query to a name server authoritative for the evil.example zone, the client would send 9666, 6669.

For RD=1 queries, I propose that the client send key tags for the trust anchor whose name has the longest match to the query name.  So for an RD=1 query for verisign.com it would send 12345, 23456.  For www.evil.example<http://www.evil.example> it would send 9666, 6669.  Certainly I suppose the "." trust anchor could still validate the www.evil.example<http://www.evil.example> response but the client will have other queries that would result in the "." trust anchor being sent upstream.

DW

________________________________
From: Olafur Gudmundsson [[email-masked]]
Sent: Wednesday, July 29, 2015 9:19 PM
To: Wessels, Duane
Cc: IETF DNSOP WG
Subject: Re: [DNSOP] The EDNS Key Tag Option

On Jul 29, 2015, at 8:09 PM, Wessels, Duane <[email-masked]<mailto:[email-masked]>> wrote:

Duane W.

Duane,

Question:

The if the query is for
verisign.com<http://verisign.com>  what TA”S are returned
if the query is for
www.evil.example<http://www.evil.example>.   What TA’s are returned ?

Olafur

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Jul 2015 14:45:39 +1000

> Feedback would be welcomed.

This really doesn't help anyone decide whether it is safe to withdraw
the old key which is the critical point of a trust key rollover.
All it shows is one of the clients has installed the new TA.

If a stub client has the new key but the recursive server doesn't
you will have (old + new).  Similarly when the situation is reversed.

What we are aiming for is knowing when the new trust anchor is
universally installed.  This requires that the common subset of
keyid's be sent rather then the union.  This subset may be empty
if someone fails to follow a TA rollover.

This also requires guidance on for how long client TA sets should
be kept so that the common subset can be completed.

It the last x hours the common subset of all TA seen is this list.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 30 Jul 2015 05:57:26 -0400 (EDT)

> https://datatracker.ietf.org/doc/draft-wessels-edns-key-tag/

I thought about this too after Warren's suggested hack queries. Of
course since EDNS is hop-to-hop this would not survive from the client
to the root.

If we want to gain visibility, we could look at something where we
request that the validating client sends an additional root ksk query
to one the known root servers despite any forwarder settings. While it
might get filtered out, it would at least give the root some visibility
into percentages of clients that have rolled to the new key. If we do
this, than I think using edns instead of the hacked query would be a
cleaner implementation.

Additionally, Mark brought up a good point that if you are behind a
forwarder that did not roll to a new KSK yet, that you would be negatively
affected too - even if you can get the information using CD=1 you still
most likely won't get anything from the upstream cache.

Paul

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 30 Jul 2015 08:25:05 -0400

> On Jul 29, 2015, at 10:34 PM, Wessels, Duane <[email-masked]> wrote:
> 
> Hi Olafur,
> 
> For RD=1 queries, I propose that the client send key tags for the trust anchor whose name has the longest match to the query name.  So for an RD=1 query for verisign.com <http://verisign.com/> it would send 12345, 23456.  For www.evil.example <http://www.evil.example/> it would send 9666, 6669.  Certainly I suppose the "." trust anchor could still validate the www.evil.example <http://www.evil.example/> response but the client will have other queries that would result in the "." trust anchor being sent upstream.

Why not include the number of labels to the TA  in the option? 
rather than have “user” chase down with it was for www.evil.examle <http://www.evil.examle/>. evil.example. , example or “.”  ? 

The main usage for this option IMHO is to check if the “local” resolver set is using expected TA’s, and if it is not enable “user” to complain.

Olafur

>> On Jul 29, 2015, at 8:09 PM, Wessels, Duane <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> https://datatracker.ietf.org/doc/draft-wessels-edns-key-tag/ <https://datatracker.ietf.org/doc/draft-wessels-edns-key-tag/>
>>

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 30 Jul 2015 16:05:55 +0000

Hi Mark,

> On Jul 29, 2015, at 9:45 PM, Mark Andrews <[email-masked]> wrote:
> 

I'm not sure I follow what you're saying.  It doesn't show when one of the clients
has installed the new TA, it shows the TAs that "all" of them have.  

> you will have (old + new).  Similarly when the situation is reversed.

That is true for any particular query, yes.  But in all likelihood the
recursive server will send queries on its own, or forward queries from
stubs without a TA.  If the stub has the new key but the recursive doesn't,
we would be able to detect that.  By analyzing all the queries from an address
we would be able to see that some have the new TA and some don't.

The reverse situation would not be detectable as currently proposed.

> if someone fails to follow a TA rollover.

Yes, that might work.

> It the last x hours the common subset of all TA seen is this list.

I wasn't proposing that recursives should keep state on key tags that
they've seen but if people think its reasonable then I am open to it.

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 30 Jul 2015 16:10:30 +0000

> On Jul 30, 2015, at 2:57 AM, Paul Wouters <[email-masked]> wrote:
> 

Hi Paul,

I am proposing (Sectino 5.2) that a recursive/forwarder would copy
edns-key-tag values from incoming queries to outgoing queries, and append
its own if different.

DW

---

From: Ray Bellis <[email-masked]>
Date: Thu, 30 Jul 2015 17:45:09 +0100

> edns-key-tag values from incoming queries to outgoing queries, and append

There really needs to be a way to signal EDNS0 option forwarding (as
opposed to hop-by-hop) based on some sort of range, rather than
hard-coded logic on an option-by-option basis...

Ray

---

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Jul 2015 09:50:31 -0700

> hard-coded logic on an option-by-option basis...

why so? i argued for hop-by-hop in EDNS for reasons which still appear
"good" to me. just as with additional-data section processing (which is
per-Qtype), this kind of data forwarding should be part of each option's
specification.

-- 
Paul Vixie

---

From: Ray Bellis <[email-masked]>
Date: Thu, 30 Jul 2015 17:53:47 +0100

> per-Qtype), this kind of data forwarding should be part of each option's

Mostly because IMHO it would be a darned sight simpler (and more future
proof) not to have to look up from a per-value table whether any
particular option should be forwarded or dropped.

I'm thinking in particular of things with embedded firmware that don't
routinely get updates.

Ray

---

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Jul 2015 09:55:42 -0700

> I'm thinking in particular of things with embedded firmware that don't

for those reasons, end-to-end forwarding will not be reliable.

if we want to send something end-to-end we have to put it into the
answer section, and sign it.

-- 
Paul Vixie

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 30 Jul 2015 17:44:15 +0000

> On Jul 30, 2015, at 5:25 AM, Olafur Gudmundsson <[email-masked]> wrote:
> 

Hi Olafur,

That is not quite what I have in mind.  Rather it is to provide data to "trust anchor operators" that helps them
understand the progress of updates (RFC 5011 or otherwise) during a rollover.

DW

---

From: Michael StJohns <[email-masked]>
Date: Thu, 30 Jul 2015 14:18:09 -0400

> understand the progress of updates (RFC 5011 or otherwise) during a rollover.

  VENN Diagram - in Ascii
_______________________________________________________________________________
| |
| All DNS Resolvers |
| 
_________________________________________________________________________    
|
| | |   |
|  | DNS Resolvers that 
implement                                           |   |
|  | this option |   |
|  | ___________________________      ________________________ 
              |   |
|  | |                          |     |                       | 
             |   |
|  | | DNS Resolvers with up    |     | DNS Resolvers with    | 
             |   |
|  | | to date TAs              |     | out of date TAs       | 
             |   |
|  |_|                          |_____| |_____________|   |
|    |                          |     |                       | 
                 |
|    |__________________________|     |_______________________| 
                 |
| |
|_______________________________________________________________________________| 

Not drawn to scale.  The question continues to be how long until and 
whether or not you get enough take on this at both the resolver and root 
sides to get usefully sufficient data.

Say you get a 10% uptake rate of implementers and they show 100% 
compliance with the installation of a new trust anchor.  Is that 
sufficient evidence to say its OK to remove the old trust anchor? What 
happens if the implementers are non-representative of the set of "All 
DNS Resolvers" and that the actual (and unknowable) reality is that only 
30% of the world actually is up to date?

Say you get a 100% uptake rate of implementers and they show a 0% 
compliance rate?  Reality or a bug in your software?

Say you get a 20% uptake rate and an 80% compliance rate - and it stops 
there and shows no sign of increasing.  Do you ever revoke the old trust 
anchor?

Say you get a 0 uptake rate besides the usual suspects - what then?

Data is only useful if you've got a plan for when you get it and if you 
understand that perfect knowledge is impossible.

One of the best analogs for the root roll is probably the US transition 
to DTV.  The US delayed the DTV roll out at least once due to consumer 
pushback (and unavailable hardware) - but eventually went ahead and 
obsoleted 5-10% of the people who hadn't paid attention, didn't care or 
couldn't be bothered. (Probably other categories like couldn't afford 
it).   It's similar to the root roll problem in that there is no-inband 
reverse signalling path to say "Hey - I can understand digital TV, go 
ahead and shut down my analog", and that all such reverse signalling 
took other paths.  It's also very similar in that almost all of the 
burden on the transition was mostly borne by other than the end-user 
(e.g. cable tv boxes still emitted analog, digital satellite ditto and 
few end-users run resolvers - its IT departments, cable internet 
operators, organization specialized entities like DISA for the DOD, etc).

While I applaud attempts to (5 years or more too late) provide 
suspenders and a belt for this process, I'm not sure that the costs for 
doing so will ever be recouped.  You would get better data just asking 
the operators now than you will get in 5-8 years when you finally get 
this rolled out.

By the way, NONE of these should delay adding a second trust anchor as 
soon as is practicable.

Later, Mike

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 30 Jul 2015 18:37:24 +0000

> On Jul 30, 2015, at 11:18 AM, Michael StJohns <[email-masked]> wrote:
> 
> Data is only useful if you've got a plan for when you get it and if you understand that perfect knowledge is impossible. 

Sure, but I would claim that describing how to get the data and the plan for when you get it are different things and
probably only one of these is appropriate for an IETF mailing list.

DW

---

From: Michael StJohns <[email-masked]>
Date: Thu, 30 Jul 2015 17:04:12 -0400

> probably only one of these is appropriate for an IETF mailing list.

Is that an indirect way of asking me to shut up and go away?

This is a mailing list for figuring out protocols for use in the 
operation of DNS.  One of the basic principles of protocol design is 
first figuring out how it will be used or what purpose it is 
fulfilling.   So *I* would claim that arguing against pursuing an idea 
on the basis that it doesn't actually help with the operation of the DNS 
*because* you don't know what to do with the data when you get it is a 
reasonable set of discussions for this list.

The main argument that I mostly agree with is that "more data is good", 
with the caveat that there's always a cost for more data and not always 
paid by those who benefit from the data (cf advertising stats collection 
in your browser).  The main argument I disagree with is "this will help 
us to decide when to roll the root".   I don't see it - and the 
arguments are using generalities rather than numbers so they're a bit 
slippery to analyze in a rigorous manner.

So the cost benefit analysis comes down to:  Is doing this because "more 
data is good" sufficient reason to proceed?  If not, is there sufficient 
evidence that this will provide us with information that will help us to 
decide when to roll the root in a timely (e.g. next year, not next 
decade) manner?  At what point do we abandon the effort because its "too 
late" to roll the root?

Let's first get a clean statement of need from the root operators and 
ICANN - what they want to collect, why, what they want to do with it, 
and when do they need it including drop dead dates?; and *then* let's 
build a protocol (or DNS extension or a mass emailing if that's what it 
takes to actually get the data).

Later, Mike