in reverse order of trustworthiness: the root a third party - e.g. DLV locally verified - e.g. my employer, ISP, someone I have a binding legal relationship with
/Wm On Thu, Nov 2, 2017 at 8:04 AM, Bob Harold <rharo...@umich.edu> wrote: > > On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson <m...@kahlerlarson.org> > wrote: > >> The root KSK rollover project has given me a real appreciation for the >> brittleness of trust anchor configuration, even with RFC 5011. (Automated >> update support should get better over time, especially after the first KSK >> roll exposes problems, but right now it's pretty shaky, which is my >> informed opinion based on observation from the operational trenches.) In >> the real world, where trust anchors are going to go stale, an "Accept Any >> Success" (in the language of Appendix C) trust anchor policy is the safest >> operationally. >> >> I agree with Ed's observation that operators are, by and large, going to >> use the defaults in whatever implementation they're running, so defaults >> are important. >> >> Trust is always going to be a matter of local policy, so with DNSSEC >> there's never going to be a consistent output given a consistent input. The >> best we can do is give good guidance to implementors, ideally based on >> operational experience, to inform their choices for the default settings >> that operators will end up using. >> >> I think RFC 6840 gets it right: it acknowledges that trust anchor >> preference is a matter of local policy, but recommends an operationally >> safe default of "Accept Any Success". >> >> Why would one want a "Closest Encloser" trust anchor preference policy? >> I've heard two reasons in this thread: >> >> 1. The untrusted parent scenario: I submit there's no practical >> implication of distinguishing between the parent's control of the >> delegation and its control of the DS: the child zone is completely at the >> will of the parent zone, so if your parent has it in for you, you lose. >> This scenario is not sufficient motivation, in my opinion, to suggest >> "Closest Encloser" as a default policy. >> >> 2. In a split DNS context, reject answers that leak into the wrong view: >> I think using DNSSEC as a backstop to enforce split DNS policy is a dubious >> operational practice and likewise not sufficient motivation to suggest >> "Closest Encloser" as a default policy. >> >> In my perfect world, implementations would offer a knob to set "Closest >> Encloser" for consenting adults but default to "Accept Any Success". >> >> Matt >> > > I generally agree with you, but wonder if there is a performance penalty > to searching every possible path before failing. Is that a reasonable > concern? > > How many paths are there? I can think of: > 1. To the root > 2. To a local trust anchor > 3. To a DLV provider (gone as of Sept 30?) > > If local trust anchors are checked before the root, and they are under > operator control, then maybe "Closest Encloser" is a reasonable default. I > don't know where to fit DLV into that plan. > > Also, if an operator does not configure DLV or local trust anchors, then > is root the only path? So "Closest Encloser" and "Accept Any Success" are > the same? > Or am I not understanding something (no experience with this yet)? > > -- > Bob Harold > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
