Re: [DNSOP] Resolver behaviour with multiple trust anchors

[william manning <[e-mail]>]

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 <[e-mail]> wrote:

>
> On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>