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

["Wessels, Duane" <[e-mail]>]

> On Nov 25, 2015, at 12:17 PM, Edward Lewis <[e-mail]> wrote:
> 
> On 11/25/15, 13:05, "Wessels, Duane" <[e-mail]> wrote:
> 
>> 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.)

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.


> 
>> 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?
> 
> And to the IP addresses for the zone's advertised name servers.

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



> 
>> 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?
> 
> 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
>> a stub?
> 
> 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.)

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.

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

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