Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-11-10 Thread william manning
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 wrote: > > On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-11-10 Thread william manning
in the last 20 years, there have been a few testbeds that have explored this space. irl.cs.ucla.edu/papers/imc71-osterweil.pdf https://eprint.iacr.org/2013/254.pdf that suggest Matt is spot on here. accepting any success is likely to present the fewest problems from a user perspective. /Wm

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-11-09 Thread Lanlan Pan
Brian Dickson 于2017年11月3日周五 上午3:58写道： > (Apologies for neither top- nor bottom- posting, i.e. not quoting any > other emails.) > > There are corner cases which exist, where desired behavior of some > resolvers is not possible to achieve. > > This mostly has to do

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-11-02 Thread Brian Dickson
(Apologies for neither top- nor bottom- posting, i.e. not quoting any other emails.) There are corner cases which exist, where desired behavior of some resolvers is not possible to achieve. This mostly has to do with constraints where "local policy" may have more than one scope. I.e. Inside a

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-11-02 Thread Joe Abley
On 2 Nov 2017, at 11:04, Bob Harold wrote: > 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? I think there's a much bigger performance penalty from returning an error

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-11-02 Thread Tony Finch
Paul Hoffman wrote: > On 2 Nov 2017, at 8:04, Bob Harold wrote: > > > 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? > > These are reasonable questions, ones that

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-11-02 Thread Tony Finch
Bob Harold wrote: > > How many paths are there? I can think of: > 1. To the root > 2. To a local trust anchor These are actually the same path since you'll find the relevant local trust anchors in the process of walking down from or up to the root. (Or, down from or up to

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-11-02 Thread Warren Kumari
On Thu, Nov 2, 2017 at 11:04 AM, Bob Harold wrote: > > On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson wrote: >> >> The root KSK rollover project has given me a real appreciation for the >> brittleness of trust anchor configuration, even with RFC 5011.

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-11-02 Thread Paul Hoffman
On 2 Nov 2017, at 8:04, Bob Harold wrote: 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? These are reasonable questions, ones that were actively discussed in the PKIX world 20+ years

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-11-02 Thread Bob Harold
On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson 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

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-11-02 Thread Matt Larson
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

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-11-01 Thread Patrik Wallstrom
If I remember the discussions correctly, there was a sense that the resolver decides the local policy. And that yes, those are the three options. Perhaps the options should be made more clear in a text somewhere. On Tue, 31 Oct 2017, Ólafur Guðmundsson wrote: There are three ways to treat this

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-10-31 Thread Mark Andrews
In message <121cdbc2-d68c-48ee-a56e-46c61fc21...@sidn.nl>, Moritz Muller writes : > > Hi, > > Together with my colleagues I have been stumbling upon a, for me, unclear > case when validating trust anchors. > > Assuming that a resolver has enabled DNSSEC validation and has the root > keys

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-10-31 Thread Michael StJohns
On 10/31/2017 4:51 PM, Paul Hoffman wrote: And once again we see the folly of the words "implementation choice" when trying to come up with a coherent DNS. The full quote makes the situation murkier: it is a combination of implementation choice plus configuration options. Some folks on this

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-10-31 Thread Paul Hoffman
On 31 Oct 2017, at 12:23, Michael StJohns wrote: But sadly - the language in RFC6840 section 5.10 is controlling... basically, any implementation can do whatever it wants. A DNSSEC validator may be configured such that, for a given response, more than one trust anchor could be used to

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-10-31 Thread Michael StJohns
On 10/31/2017 5:39 AM, Moritz Muller wrote: Hi, Together with my colleagues I have been stumbling upon a, for me, unclear case when validating trust anchors. Assuming that a resolver has enabled DNSSEC validation and has the root keys configured. Additionally, it has configured manually a

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-10-31 Thread Paul Wouters
> On Oct 31, 2017, at 22:25, Ólafur Guðmundsson wrote: > > > There are three ways to treat this case: > Any-TruestedKey-works > ConfiguredKey-trumps-DS > DS-trumps-configuredKey > > I think the Last one is the "most" correct from an operational expectation, Not

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-10-31 Thread Ólafur Guðmundsson
There are three ways to treat this case: Any-TruestedKey-works ConfiguredKey-trumps-DS DS-trumps-configuredKey I think the Last one is the "most" correct from an operational expectation, but the first one is least likely to run into errors, But I suspect the middle one is implemented Olafur On

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-10-31 Thread Philip Homburg
>It sounds like clarification is needed if even one (much less three) >systems treat such a signature as Bogus. My reading of RFC 4035 is that >any chain that successfully leads to a trust anchor should return >Secure, even if a different chain returns Bogus. If extra trust anchors are

Re: [DNSOP] Resolver behaviour with multiple trust anchors

2017-10-31 Thread Paul Hoffman
On 31 Oct 2017, at 2:39, Moritz Muller wrote: Together with my colleagues I have been stumbling upon a, for me, unclear case when validating trust anchors. Assuming that a resolver has enabled DNSSEC validation and has the root keys configured. Additionally, it has configured manually a