On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt" <dnsop-boun...@ietf.org on behalf of e...@isc.org> wrote:
> On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote: > > Nice write-up Edward! You have nicely summarized why Mark and me agree > > that validator should use longest suffix match when selecting TA to > > validate data. > > +1. Hmmm, that wasn't my intent. ;) I had been trying to justify the other conclusion. But, if my work is leading you towards this "other" conclusion, I've been taking time to understand why. I'm beginning to have a new understanding on this. The overlooked (by me) point is that we are focusing on a situation where the local operator has chosen to explicitly configure a trust anchor. Beside code distributions shipping with the IANA managed KSK (or its DS form) for the global public Internet's root zone, if any operator wants another trust anchor point, they have to take explicit action to configure it. The question is - what is the expectation of the operator in doing this? There was a time when TLDs were signed but the root zone was not. Then operators had to configure trust anchors for the TLDs to enable validation. When the root zone was signed in 2010, the TLDs had to remind all those with trust anchors to remove them (before the TLD could change it's KSK). I can no longer find reports of the efforts to undo TLD trust anchors (Sweden and maybe CzechRep?) that I thought were once floating around. "Fears" surrounding this would lead one to favor the more open "any" policies, on the other hand, mass migration from TLDs to root for the top of the trust chain was probably a one-time event as a result of the on-set of DNSSEC in the root zone. I'm not sure that the need for robustness outweighs the expectation of someone explicitly adding a trust anchor anymore. OTOH, in the sense "I am not sure" there's the example of split-DNS and poor query path management (i.e., leaks). I'm not sure if robustness helps here, or is a bad-behavior enabler. > > Things might get even more complicated when negative trust anchors are > > configured, bleh. > > Fortuantely a negative trust anchor is a longest suffix match too. This is an emerging "thing" - more active awareness and management of the trust anchor element of a validator.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
