> On Nov 25, 2015, at 12:17 PM, Edward Lewis <[email protected]> wrote: > > On 11/25/15, 13:05, "Wessels, Duane" <[email protected]> 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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
