Subject: [DNSOP] More comments on draft-wessels-edns-key-tag-00

From: Edward Lewis <[email-masked]>
Date: Tue, 24 Nov 2015 17:00:02 +0000

One of the concerns in the document is "when to send the option."

I'll state the assumption that this is most useful for RFC 5011
["Automated Updates of DNS Security (DNSSEC) Trust Anchors"] situations.
Perhaps it is not exclusively use to that, but I'll presume that for this
suggestion.

In RFC 5011, section 2.3 "Active Refresh" there is this plus more detail:

"A resolver that has been configured for an automatic update of keys
   from a particular trust point MUST query that trust point (e.g., do a
   lookup for the DNSKEY RRSet and related RRSIG records)..." (yadda,
yadda, yadda)

In the sense that there's a concern about a resolver exposing the keys it
has, if the option is only to be attached to the queries done to satisfy
that requirement above I think the problem is simplified.  In this case,
the resolver will know that it "needs to know" and it knows where the
trust anchors are "homed."  I.e., if the resolver cannot directly query
the source, then all bets are off, RFC 5011-wise.

Now, if my assumption is incorrect, I'd still recommend that the option be
added to RFC 5011, section 2.3 mandated queries.  Beyond that, I'm not
sure what is the appropriate general case for "revealing" ones' configured
trust anchors.  There'd be no need for "union-ing" the response (section
5.2.1).  The temptation to scope creep this is curtailed if this is an
"extension" of RFC 5011 as opposed to a general EDNS option.  Any network
management reason for this would be available through the means the
operator does other network maintenance (use of tools to inspect, etc).

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 24 Nov 2015 21:24:54 +0000

Hi Ed,

> On Nov 24, 2015, at 9:00 AM, Edward Lewis <[email-masked]> wrote:
> 

I'd put it slightly differently.  I'd say it is most useful for "configured
trust anchors" whether they're updated with RFC 5011, or not.  By "configured
trust anchor" I mean the trust anchor material that exists outside the
name server process, survives restarts and reboots, etc.

As currently written the draft also applies to cached trust anchors (i.e.,
DS records) and I've had people tell me they think that could be useful.
But if the consensus is that edns-key-tag should only be reported for
configured trust anchors, I could live with that.

> the source, then all bets are off, RFC 5011-wise.

But then you only get data for validators doing 5011 and doing it correctly.
This is part of the problem we have with the root -- if there are validators
with manually configured keys, we'd like to know about them.

OTOH, really nothing in the draft is mandatory (except for the MUST NOTs).  So
an implementation of edns-key-tag could absolutely choose to only send the
values for RFC-5011 queries.

> operator does other network maintenance (use of tools to inspect, etc).

DW

---

From: Edward Lewis <[email-masked]>
Date: Wed, 25 Nov 2015 14:33:58 +0000

>configured trust anchors, I could live with that.

Okay, I've been myopically focused on 5011 for some time now.  That's my
story and I'm sticking to it.

>values for RFC-5011 queries.

You're right that the need is wider than 5011 cases.

In an effort to simplify and streamline this (for reasons I'll include
later), what about telling a querier to only send this option when it is
sending a query to an IP address that is authoritative for the DNSKEY set?
 I mean that as a toss-up question.

Can the querier know when that is happening?  I believe so but I don't
know if implementations can tell that (in time).  What I'm trying to rule
out are "stubs" that are sending queries to "upstream" validators or
forwarders.

The reason for this is to limit the times a stub exposes the trust anchors
it has (in case one is known to be exploitable) and to avoid having to
come up with rules for union-ing the possible lists of key tags. Or, to
ask another toss up - is there benefit in telling the upstream what trust
anchors are held?  (If there's a conflict between the two (which could
also be sever clock skew), use 'CD' in queries.)  I'm not sure there's a
benefit telling anyone other than the authority for the trust anchors
about the set held.

Now what I am trying to imagine is how the receiver of the option reacts.
I don't know that I'd recommend any active reaction - like trying to
inform the querier that their set of tags is out of date.  I have the
sense that there might be a benefit within a small use case but trying to
do that would proliferate corner cases as well as work against the loose
coupling that allows DNS to work at scale.

I imagine I'd look at packet traces to see what is being sent in, counting
IP addresses with/by tags of interest.  I.e., out of band (to port 53)
massaging of the data and reacting to it.  While I realize that during a
key roll there will always be late comers, having a gauge of how many are
ready for new signatures is helpful to the roll process.

The response - what would be in it?  Should it be empty?  Should it
include a set of tags (but what set of tags?). I ask the last because the
authoritative server would be configured or deduce the set of tags it sees
which might not agree with what a RFC 5011 validator may have picked up.
(I.e., keys in the AddPend state are trust anchors in the server, not
mature enough to be trusted in the client.)  Should it be the set of
intended trust anchors or the set of what is thought a 5011 validator
(there that focus goes again) would think the tags should be?

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 25 Nov 2015 18:05:17 +0000

> On Nov 25, 2015, at 6:33 AM, Edward Lewis <[email-masked]> wrote:
> 

For the recursive-to-authoritative case that is exactly what I had in mind.

> What I'm trying to rule
> it has (in case one is known to be exploitable)

Can you say more about how limited you think it should be?  Never?

In what I'm proposing the stub also would send the option only for DNSKEY queries
and only for trust anchor zones (i.e. root).  Is that limited enough?

Do you have particular concerns about who knows about the stub's trust anchors?  
Are you thinking of on-path attackers or the recursive operator or something else?

Is it okay for a recursive to expose old trust anchors, but not okay for a stub?

> and to avoid having to
> come up with rules for union-ing the possible lists of key tags.

I actually like the suggestion I heard from someone (sorry, can't remember
exactly who right now) that instead of intersection or union, the recursive
could just forward a second instance of the option.

> Or, to
> anchors are held?  

I'd say there is a benefit to the zone operator in knowing what trust anchors
are in use by stubs.

> (If there's a conflict between the two (which could
> also be sever clock skew), use 'CD' in queries.)

Sorry I didn't follow that.

> I'm not sure there's a

I am fully against any active reaction.  The edns-key-tag option should
not affect the response in any way, nor cause any "extra" responses.

> ready for new signatures is helpful to the roll process.

Yes.

> (there that focus goes again) would think the tags should be?

Forgive me for saying, but it sounds to me like you might've misunderstood
a little about what I proposed.  I'm saying the edns-key-tag option rides
along with a DNSKEY query.  So the response is a normal DNSKEY response.

The draft currently says:

  A responder MUST NOT include the edns-key-tag option in any DNS response.

So what I've proposed is one-way, passive data collection only.  Note I modeled this
after RFC 6975, which works the same way.

DW

---

From: Edward Lewis <[email-masked]>
Date: Wed, 25 Nov 2015 20:17:10 +0000

>Can you say more about how limited you think it should be?  Never?

(Probably) as much as possible.  I can't see the benefit of telling a
third party this.  (First party being the validator/querier, second party
being the authority of the trust anchor set, third party including the
upstream.)

>and only for trust anchor zones (i.e. root).  Is that limited enough?

And to the IP addresses for the zone's advertised name servers.

>Are you thinking of on-path attackers or the recursive operator or

Nothing in particular.  I'm not even clear if it's attackers I am worried
about, it's just general leakage.   I don't see damage in leaking, per se,
outside of the "if someone knows trust anchor #4 was reverse engineered,
then the verifier using it is vulnerable."  It's more that I don't see a
benefit in allowing leakage.

>Is it okay for a recursive to expose old trust anchors, but not okay for

Hmmm, I don't think the two (stub and recursive) are different for this
option.  (In the sense that EDNS is hop-by-hop and not end-to-end, and the
only query handler that can make any use of this information is the
authority.)

>could just forward a second instance of the option.

Not commenting directly on that, but, I'm leaning towards this never being
an issue - that is - there should be no middlebox of any kind that would
forward/relay the option.

>I'd say there is a benefit to the zone operator in knowing what trust

Zone operator would be the one plowing through the packets seen at the
authoritative addresses, I think.  (Me being fully aware that zone
operators aren't always DNS operators.)

>Sorry I didn't follow that.

I was thinking - if a validator is forwarding all traffic to a recursive
server that is also DNSSEC validating, and there is a conflict because the
"upstream" is SERVFAIL'ing some data because of, say, the trust anchor not
right, the "downstream" ought to revert to "+CD" to avoid the buggy
in-validation.

>  A responder MUST NOT include the edns-key-tag option in any DNS

Missed that.  (Yes, I did read the draft, twice,...still missed it. ;))

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 25 Nov 2015 21:53:25 +0000

> On Nov 25, 2015, at 12:17 PM, Edward Lewis <[email-masked]> wrote:
> 

Well, the benefit is really for the authoritative.  So the benefit of
telling the third party is that the third party will forward it to the
second party.

> And to the IP addresses for the zone's advertised name servers.

Are you saying that stub clients should communicate directly with 
authority servers?

> only query handler that can make any use of this information is the

Earlier you said that stubs shouldn't send the option because it 
could expose old vulnerable trust anchors.   But now I hear you
say that its no different for stub and recursive.  

If exposing old trust anchors is a problem for stubs why is it not also
a problem for recursives?

My own opinion is that the benefits outweigh the risks.

I sense similarities to the (terrible) advice that you should obfuscate your
"version.bind" string.  Ugh.

> right, the "downstream" ought to revert to "+CD" to avoid the buggy

That would seem to apply regardless of the proposed edns-key-tag option.
FWIW the draft mentions CD in just one place:

   If the client included the DO and Checking Disabled (CD) bits, but
   did not include the edns-key-tag option in the query, the validating
   recursive resolver MAY include the option with its own Key Tag values
   in full.

DW