Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Nov 2017 11:07:49 +0000

On 10/31/17, 15:52, "DNSOP on behalf of Paul Wouters" <[email-masked] on behalf of [email-masked]> wrote:
>this zone can never be stolen from me by a parent.
    
Can you elaborate on this, what do you mean "stolen" by a parent?

The reason I am asking - choosing one strategy (any key, configured key rules, DS rules) is based on what one most wants to solve.  For "robustness" in the sense of most aggressively getting an answer, opting to accept any (and I'll use the word:) approved key is going to lead to more answers being validated.  "More answers" may or may not be a good thing, but the fact is that numerically, having more trusted points from which to build chains will lead to more validated answer sets.

By "approved" I mean any key that has passed muster to be a trusted key in the resolver and/or there is a chain of trust from the key set back to another trusted key.  Please don't take this as a general definition, I'm using it only within the context of this mail message and only within the confines of the protocol's technical work, not any judgement regarding legitimacy in operations.

Back to the question above, to help enumerate the scenarios in which one would opt to not trust a key that has been learned via a chain of trust in the face of a trusted key, it would help to understand what is meant by a parent "stealing" a zone.

What I am thinking is:

(Un- cut point/DS set is removed, re- cut point/DS set is changed.)

01 A child may be un-delegated by operational error at the parent.
02 A child may be un-delegated in accordance with the registration agreement.
03 A child may be un-delegated outside of the registration agreement.

04 A child may be re-delegated by operational error at the parent.
05 A child may be re-delegated in accordance with the registration agreement.
06 A child may be re-delegated outside of the registration agreement.

07 A child may be un-DSd by operational error at the parent.
08 A child may be un-DSd in accordance with the registration agreement.
09 A child may be un-DSd outside of the registration agreement.

10 A child may be re-DSd by operational error at the parent.
11 A child may be re-DSd in accordance with the registration agreement.
12 A child may be re-DSd outside of the registration agreement.

Before getting into the "why's", the impacts of cases:

01-03: Answers for the zone's data will be NXDOMAIN (once TTLs expire)
04-06: Answers will come from a different administrative authority
05-09: Answers will be accepted as Insecure unless the trust anchor is configured
10-12: Answers signed by other keys may be received

Cutting along the why's:

01,04,07,10 (Operator error) - The underlying DNS service error must be fixed, in the meantime, flexibility is desired to prevent service disruption.

02,05,08,11 (Justified change) - The issue lies above the level of DNSSEC.  By "justified change", this includes term expiration, lack of payment, failing to abide by acceptable use policy, etc.  Beyond the scope of the technology, this might even come as a result of a court order, to name a reason for this category.  In this case, the parent exerts the protocol prerogative of where it delegates names to enforce whatever policy governs.

03,06,09,12 (Unjustified change) - This would include any reason that could be seen as "corruption" of the registry operator role.  I would include all cases of "stolen" to be here, lacking a better definition of "stolen."

A dimension I haven't included is whether a validator has a trust anchor for the name in question or not.  (If not, then the issue of the conflict doesn't matter.)

The next step here is to look at the relative frequency of each case.  Mind, I'm not including child operator error in any of this (which would expand the cases).

The reason for drilling into this is the assertion that trusting configured trusted keys over the DS record is "the only workable solution".  I'm not convinced, I think that the cases in which that is the preferred option is in the minority of the failure modes.

What's in the back of my mind is that ultimately, there's still the DNS problem - the parent unilaterally controls the existence and direction of the delegation.  DNSSEC can't overcome that.  DNSSEC can only choose to be more restrictive (and thus brittle in some sense) or be as lenient as possible (for robustness in the sense of getting an answer to the query).

---

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Nov 2017 11:11:57 +0000

On 10/31/17, 20:50, "DNSOP on behalf of Mark Andrews" <[email-masked] on behalf of [email-masked]> wrote:
   
>Secondly doing deepest match on trust anchors is the only secure way to prevent a parent overriding the child zone's security policy.

By this, do you mean choice of cryptographic algorithm and/or length?  To achieve "independence" in this way, the child can simply refuse to have a DS record at the parent and then lean on managing trust anchors at all relying resolvers.

---

From: Patrik Wallstrom <[email-masked]>
Date: Wed, 1 Nov 2017 13:17:31 +0100

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 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 Tue, Oct 31, 2017 at 2:39 AM, Moritz Muller <[email-masked]>
>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 trust anchor for a TLD (that
>> has also published its DS in the root zone).
>> Now, for example due to a key rollover at the TLD, the manually configured
>> trust anchor of the TLD does not match the DS in the root anymore.
>>
>> How should a resolver treat the signatures of this TLD?
>> The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures
>> of the TLD as bogus, but we didn't find any specifics in RFC 4034 and 4035
>> that describe how resolvers should behave in this case.
>> Knot resolver treats them as NOERROR (according to the developers).
>> If we interpret section 4.3 of RFC 4035 then we would have assumed that
>> the signature must be treated as secure.
>>
>> Did we miss something, or is there indeed clarification needed?
>>
>> — Moritz
>>
>>
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>

>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

---

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Nov 2017 13:48:02 +0000

>    options. Perhaps the options should be made more clear in a text somewhere.

The reason why I'm digging into this is that "things change."

Back about 15-20 years ago, when the design work was done, the original workshopping, documentation and re-documentation that led to the current RFCs on DNSSEC (numbering 4033-4035), the concerns were a bit different than perhaps they are now that we have operational experience.

Local policy is and remains the overriding philosophy of validation.  It is purely up to the receiver to determine what they trust.  But there's also the operational reality that most users will unbox a tool and rely on default settings until they realize they are unhappy with it and realize how to tweak it.

Besides local policy, the principle that plays a role here is maintaining as much robustness as possible.  Robustness means - getting answers to user's questions if at all possible.  DNSSEC, as an example of "slapped on security" (over an existing system, will inherently cause some once valid states to be invalid, for reasons based on "security."  To counter act that (not eliminate it), being conservative on what to block (SERVFAIL) was thought to be a design goal.

The desire to maximize robustness is something that might be subject to "things change."  During the time of design, there wasn't a mature registration economy (registries, DNS hosting, registrars, etc.), little thought was given to malicious mis-dealings in delegations.  I'm thinking in this direction based on a statement that "perfering a local trusted key over the DS record" is "the only way to go" because a "parent could steal a zone."

Perhaps what is needed is to examine the situation when it is found that there is a conflict between a trust anchor rooted-chain and a chain that passes up through a DS record on to an upper trust anchor.  (Keeping in the back of the mind that a resolver is allowed, via local policy, to build any kind of chain it wants, not just a chain that matches the delegation tree.)

1 - What if a higher-level trust anchor and chain validates an RR set but no trust anchor and chain is possible?  I.e., TA(example)->DS(delegation.example)->KEY (delegation.example)->www.delegation.example/IN/NULL validates
but
TA (delegation.example)->nothing->www.delegation.example/IN/NULL

By "nothing" I mean there's no key matching that cited in any RRSIG(NULL) over www.delegation.example/IN/NULL.

In a benign world, this should work as it is possible that the trust anchor base is outdated.  Perhaps there was a re-delegation, perhaps a misconfiguration.

In a malignant world, this would result from a "corrupted" registry.  (Where corrupted means, not playing by the rules whether intentionally or not.)

2 - The opposite, the trust anchor validates, not the DS chain

This could happen with a child forgetting to tell the parent that they've changed secure entry points, (been there, got a t-shirt and had a cool packet dump to analyze) but also had some population of trust anchor managers playing along.  The latter group didn't have errors, the non-players did experience SERVFAILs.

3 - they both work or both fail

I don't see an issue.

What I'm coming to is ... if there's a choice between being afraid of a malicious registry or being afraid of operational errors, for reasons I don't think are made in this email, I'm still opting to be afraid of operational errors because, well, them I've seen.

Are there cases of "corrupted" registries make the threat of "stolen zones" a real thing?

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 01 Nov 2017 07:49:32 -0700

> The reason why I'm digging into this is that "things change."

As a recap: this thread started with Moritz quoting from RFC 4035 and 

> Did we miss something, or is there indeed clarification needed?

I believe that RFC 4035 indicates success in any chain means that the 
validator should mark it as Secure.

Mike StJohns pointed out that RFC 6840 gave different guidance. That 
guidance suggests a default scheme and says that it should be up to 
validator configuration.

RFC 6840, which as the the latest standards-track text on the topic, was 
published in 2013. If things have changed since 2013, an update to RFC 
6840 should be started.

--Paul Hoffman

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 1 Nov 2017 08:17:08 -0700

On Tue, Oct 31, 2017 at 11:30 AM, Paul Wouters <[email-masked]> wrote:

>
>
> > On Oct 31, 2017, at 22:25, Ólafur Guðmundsson <[email-masked]>
> wrote:
> >
> >
> Not really, as that would mean you cannot have internal only zones in
> split-dns view, unless you are
> building in weird assumptions like ConfiguredKeyTrumpsNSECbutNotDS
>
> It better, it is the only working solution :)
>
> The question is that what the "users" expect?
I  agree that first two have the best operational behaviors, and the third
one blocks "split-DNS with different KEY"
if Internal domains use the same key as External "equivalent" ones then
there is no issue
Thus the question is twofold
a) is there need for clarification in how protocol works possibly with
recommendation for resolver "tunable" settings.
b) is there need for operational guidance for "split DNS" DNSSEC

I think the answer on both is yes.

Olafur

---

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Nov 2017 16:48:07 +0000

On 11/1/17, 11:17, "DNSOP on behalf of Ólafur Guðmundsson" <[email-masked] on behalf of [email-masked]> wrote:

>a) is there need for clarification in how protocol works possibly with recommendation for resolver "tunable" settings. 
>

This is something that might be fit into -validator-requirements-.  (Which is perhaps another motivation of mine to dig into this.)

But the idea of more knobs to turn and switches to flip runs counter to my perceived need to simplify the operation of the DNS.  The battlefield is defined by software developers, who are pushed to add more functionality into simpler to run packages.

Many operators use "off-the-shelf" components and do not write their own code, which is what shifts this on to the shoulders of the software developers.

>b) is there need for operational guidance for "split DNS" DNSSEC

There was an attempt to document split DNS more than 10 years ago, which died a death of disinterest.  (Last version expired 10 years, 1 month, 25 days ago. ;)  Lucky guess.)

https://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view-04

Perhaps start there.  (Last time I saw the author was in a children's swimming school lobby just last year.  Odd.)

---

From: Philip Homburg <[email-masked]>
Date: Thu, 02 Nov 2017 11:14:49 +0100

>Are there cases of "corrupted" registries make the threat of "stolen zones" a 

I think the most well known example is the US government taking the .org domain
of Rojadirecta.

https://torrentfreak.com/u-s-returns-seized-domains-to-streaming-links-site-after-18-months-120830/

There were two issues in this case: for any organisation outside the US, using
a domain with a registry in the US is risky, because the US government assumes
jurisdiction, even if the company itself doesn't do any business in the US.

The second issue is that the domain was seized by the executive branch. And
not just blocked, but actually redirected to servers of the US government.

---

From: Matt Larson <[email-masked]>
Date: Thu, 2 Nov 2017 10:41:35 -0400

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

---

From: Bob Harold <[email-masked]>
Date: Thu, 2 Nov 2017 11:04:52 -0400

On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson <[email-masked]> 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".
>
> 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

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 02 Nov 2017 08:11:04 -0700

> searching every possible path before failing.  Is that a reasonable 

These are reasonable questions, ones that were actively discussed in the 
PKIX world 20+ years ago. The consensus conclusion was that any 
performance penalty was worth the consistency of answers, since the 
relying part (the stub resolver in our case) had no control over the 
order of evaluation.

> root the only path?

All trust anchors are "local", so the question becomes "if an operator 
does not configure DLV or any trust anchors". The former is now moot, 
and the latter goes against a bunch of MUST statements in the standard.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Thu, 2 Nov 2017 11:26:54 -0400

On Thu, Nov 2, 2017 at 11:04 AM, Bob Harold <[email-masked]> wrote:
>> 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.
>>
>> use the defaults in whatever implementation they're running, so defaults are
>> important.
>>
>> preference is a matter of local policy, but recommends an operationally safe
>> default of "Accept Any Success".
>>
>> 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.
>>

I have no actual data, so I'll pontificate instead :-)

I suspect that there is a really small set of resolvers with more than
just the root TA -- and if the resolver operator *has* configured a
local TA they have done this for a reason important to them, and so
presumably are willing to pay the performance cost.

Having a (per-TA) knob sounds like a nice compromise, but I'd really
like implementors to chime in on how much complexity this adds. If *I*
added a local TA for .example (or foo.example.com) I'd automatically
assume that this is a closest encloser / Negative Trust Anchor /
longest match type operation and would be very surprised if that
wasn't the behavior -- this *may* be a combination of being primarily
a routing person, and also the fact that if I create a local zone for
foo.example.com (in a non-DNSSEC world) I'd expect it to take
priority...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Nov 2017 15:27:44 +0000

On 11/2/17, 11:04, "Bob Harold" <[email-masked]> 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?

There are a bunch of tradeoffs to consider.  (I'll start with "it is a concern" but not sure if it's "something to be afraid of.")

For one, in terms of latency (time to answering the question), if the attempts are in parallel then there's arguably less impact, as network latency might be greater than compute latency.  ("Might" is the operative word.)

One of the old debates between myself and Olafur was whether the cost of a network retrieval was greater than or less than the cost of a cryptographic operation.  That debate is so old I've forgotten which of us sided with which side.  I do know that we never resolved it, knew it wasn't generally resolvable, and would probably change over time anyway.

For two, in terms of load on the network (more traffic), it's hard to know.  Depends on what is cached, how often the work is done, whether it is each validation or not.  (You'd only have the question arise when you have a trust anchor besides the root to consider - the frequency might be dependent on whether split-DNS is an issue or not, and so on.)

For three, performing actions in parallel complicate code writing.  If you were educated in the days before thread packages existed, you are tempted to try serially.  (pthreads, IEEE Std 1003.1c-1995, came along too late in the game for me.)  Younger kids are apparently able to multi-task better these days, I hear, so I hope that makes for better code (a'la Go).

There's always the "one branch gives me this result, the other branch seems to be hitting a timeout" case meaning sometimes you have to estimate when it's time to give up and get on with it.  It's that case that makes coders implement "first result wins" more often than is probably wise.

This is what makes "robustness" a tricky thing (and why I like to dive into this again now and then).  If "robust" means returning as much data to a query as possible (like finding the one working secure chain), you might risk breaking a different definition of "robust" for the relying application, which has a time-deadline to meet.

In short - it's a tradeoff of time (latency) and maximizing validation of answers (robustness) which depends a lot on how the code is implemented and the workload provided.  Like looking for a needle in a haystack - the longer you look the higher the chance you will find it, with how you look being a factor in speed, as well as the size of the haystack, number of needles present, etc.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Nov 2017 15:41:51 +0000

> foo.example.com (in a non-DNSSEC world) I'd expect it to take

This is an interesting viewpoint.  I understand that in the routing world, longest match prefix is the way the outgoing interface is chosen.  This doesn't translate into the design of DNSSEC though.  (Like a pun in English isn't quite the same in any other language and vice versa.)

The issue in routing is that you have to choose one solution and go with it.  Unless you are multi/broadcasting, the packet is going to go on to one outgoing buffer/queue.

The issue in DNSSEC is to retain as much robustness as possible because the decision will have a long-lasting impact (sitting in cache, opening an ssh connection, etc.)  This mirrors what Paul said in an earlier message regarding PKIX.

On 11/2/17, 11:11, "DNSOP on behalf of Paul Hoffman" <[email-masked] on behalf of [email-masked]> wrote:

>The consensus conclusion was that any performance penalty was worth the consistency of answers, since the relying part (the stub resolver in our case) had no control over the order of evaluation.

Consistency is the objective there, not robustness, but I'd hand-wave the two are closely related.  Consistency, in terms of coherence, has historically been part of the DNS rhetoric, which (I'll claim) is a/one foundation for DNSSEC's robustness.

So, I get that from a routing backdrop, the longest match expectation is reasonable but not what was written into the DNSSEC documents because DNS and DNSSEC have different objectives than routing (or forwarding, whichever is more appropriate).

---

From: Tony Finch <[email-masked]>
Date: Thu, 2 Nov 2017 15:49:20 +0000

> 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 the closest enclosing validated DNSKEY.)

> 3. To a DLV provider (gone as of Sept 30?)

I have a half-formed evil plan to use DLV to distribute trust anchors for
reverse DNS zones that lack DS records (RFC 1918 and others). One managed
key is easier than c. 20 keys!

As Mark said, DLV only applies when the normal path says insecure.

> root the only path?  So "Closest Encloser" and "Accept Any Success" are the

Closest encloser implies to me that you don't fall back to looking at the
DS records if you can't validate a DNSKEY that has a local trust anchor.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fisher, German Bight: Northwest 5 or 6, occasionally 7 in Fisher, backing
southwest 4 or 5 later. Moderate, occasionally rough for a time. Showers.
Good.

---

From: Tony Finch <[email-masked]>
Date: Thu, 2 Nov 2017 15:53:41 +0000

Paul Hoffman <[email-masked]> wrote:
> These are reasonable questions, ones that were actively discussed in the PKIX
> world 20+ years ago. The consensus conclusion was that any performance penalty
> was worth the consistency of answers, since the relying part (the stub
> resolver in our case) had no control over the order of evaluation.

It's worth noting that the PKIX chain of trust is a directed graph whereas
the DNS is a tree, and trees are a lot easier to follow. (No loops etc.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fitzroy: Cyclonic 4 or 5, increasing 6 at times. Slight or moderate. Rain or
thundery showers. Good, occasionally poor.

---

From: Joe Abley <[email-masked]>
Date: Thu, 2 Nov 2017 12:38:18 -0400

> 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 to an application and requiring an end-user to do something; the small delay introduced by validating a signature chain against a different trust anchor is likely smaller than that in the event that validation subsequently succeeds and irrelevant in the case that it fails.

I think that the performance angle, whilst always worth considering e.g. for impact on scaling properties, is a red herring in this particular case. I think the focus on what policy makes sense and where it should be applied is the right one.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 Nov 2017 08:24:28 +1100

This is only about which trust anchors applies for a given name with
you have several configured with different names.  Multiple trust
anchors with the same name is still any match will do.

There are enough senarios where you want *only* the closest
trust-anchor to apply that that is what was coded.  This does however
result in occassional breakages when that trust anchor is not keep
up to date and it is only being used to provide a trust anchor for
a site in the event of a link failure.  That said if you have the
trust anchor there for link failures you *need* to keep them up to
date or they do not do their job when the link fails.  Having
validation fail is a good way to show that they are out of date and
that your processes have failed.

I don't see a reason to change from only using the deepest match.
It is the best overall strategy.  If you are getting validation
failures because the trust anchors are out of date, fix the process
that keeps the trust anchors up to date.  Once that is done worring
about DS overriding a configured trust anchor is moot.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Petr Špaček <[email-masked]>
Date: Mon, 6 Nov 2017 11:25:15 +0100

>> Secondly doing deepest match on trust anchors is the only secure way to prevent a parent overriding the child zone's security policy.

Even though Knot Resolver implements "use any" (DS or trust anchor,
whichever matches), I think we should move to "deepest match on trust
anchors", i.e. I agree with Mark.

"Use any" strategy is insecure and will surprise people, as ilustrated
by reaction from Edward quoted below:

> By this, do you mean choice of cryptographic algorithm and/or length?
> To achieve "independence" in this way, the child can simply refuse to
> have a DS record at the parent and then lean on managing trust anchors
> at all relying resolvers.

With current implementation of "use any" nothing prevents the parent
from publishing a DS and thus hijacking the domain without clients
noticing even if there was a local TA installed for given subdomain on
clients.

For this reason I propose to document that "deepest match" is mandated
behavior.

-- 
Petr Špaček  @  CZ.NIC

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 06 Nov 2017 07:15:55 -0800

Doesn't "I don't trust my parent's security policy" open up a million 
cans of worms anyway? It feels like making this change to the default 
behavior will make validation more brittle (because people *will* forget 
to update their lower-level trust anchors) in order to help a very small 
number of people who could have made the configuration change 
themselves.

--Paul Hoffman

---

From: Petr Špaček <[email-masked]>
Date: Mon, 6 Nov 2017 16:56:46 +0100

> cans of worms anyway? It feels like making this change to the default

1. The problem is that there were (and certainly will be) successfull
hacks into registries, that seems just inevitable.

2. Vast majority of people will not bother with setting up own trust
anchors. I.e. vast majority of people will not be affected by any
brittlenes you envision.

3. The small fraction of people who configure their own TA do it for a
reason. The reason I can see is "TA pinning". This provides users
ability to to configure their critical systems in a way which turns
successfull hack into my parent registry into Bogus status.

Yes, it requires them to keep TA up-to-date, but that is the price you
pay for pinning.

> number of people who could have made the configuration change themselves.

Personally I do not see justification for 'trust DS or TA' behavior so
I'm not willing to make security critical code paths more complex just
for sake of having an unused configuration knob.

In other words, "could have made the configuration change themselves" is
not applicable here because the knob is not going to be available.

I did my best to explain my reasoning, let me know if you can see some
holes in the reasoning.

-- 
Petr Špaček  @  CZ.NIC

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 06 Nov 2017 08:08:17 -0800

> Yes, it requires them to keep TA up-to-date, but that is the price you

In retrospect, I agree that these two are good justification for "if a 
subordinate trust anchor has been configured, the default is to trust it 
more than the superordinate one" as long as the document also says "but 
this should be configurable".

So, are you volunteering to start the effort for rfc6840-bis? :-)

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Nov 2017 18:17:20 +0000

On 11/6/17, 10:57, "DNSOP on behalf of Petr Špaček" <[email-masked] on behalf of [email-masked]> wrote:

>I did my best to explain my reasoning, let me know if you can see some holes in the reasoning.

Coming from my assumption that "use any chain" is the best way to go, I tried to figure out why you are coming to a different conclusion.

There are two "holes" I see.  One is that DNSSEC's design is centered on preventing a receiver from accepting forged data.  Two is that the design of DNSSEC has to take into account the limitations of the base (DNS) protocol.

>From the point of view of a validator (operator), it is your choice to decide what to trust, or not.  You may decide that a certain signed zone is critical to your operations, so you get the DNSKEY with the SEP bit set and pin it as trusted.  How do you know whether the zone manages its keys in accordance with Automated Updates of DNSSEC Trust Anchors?  How do you know when to update the trust anchor, especially if the zone is not running in accord with Automated Updates?

The DNS protocol doesn't let you know.  You could find this via out-of-band channels, like via something at a URL (listing the secure entry points), via direct communication with the zone operators.

The protocol (DNS) lacks per-zone signaling.  For that reason, the assumptions of how DNSSEC is set up assumes a unified one-protocol set up.  E.g., even in the early days, .COM was an unusual case and we were tempted to define DNSSEC to act differently for it or other large delegated zones.  It took a while to get "opt-out" into the protocol in a way anyone could make use of it, which was a central issue.  (The history of that is murkier than I may be presenting.)

We even tried to have different key "strengths."  That failed to materialize as we realized the weakest link is still the weakest link.

Trying to differentiate zones by "criticality" begins walking a thread of deciding "what is critical" and how does one decide that?  (There are TLD operators who told me "it's okay, we think of this TLD as experimental."  To me a TLD would be critical, but that view is apparently not universally shared.)  How would a validator determine, objectively, whether a zone is critical to the validator's audience?  Once it did determine, how would it know what the security policy was of the zone (does it honor the add hold-down time, etc., does it even separate the KSK from the ZSK, would it switch to a CSK, and so on).

I could see a knob for a validator operator to select zones for pinning the trust anchors, for selecting them for STD 69 (Automated Update) treatment.  I can't see though having a restrictive policy (if trust anchor, no DS - so to speak) be the default as that would be the unusual case (having a trust anchor).

DNSSEC never assumed that the whole tree would be signed.  That is why trust anchors were invented.  DNSSEC, at first, even tried to allow an arbitrary policy of "who can sign what."  (That is why there's "Domain Name System Security Extensions" from March 1999 and then "Domain Name System Security (DNSSEC) Signing Authority' from November 2000.  That's RFC 2535 and 3008 for those that speak RFC numbers.  DNSSEC didn't adopt the on-tree signing authority until we exhausted attempts at something more liberal.)  The problem with arbitrary policies is that, first, you must be able to write them down.

This is why the guidance in "Protocol Modifications for the DNS Security Extensions" leads to "any" chain. "Clarifications and Implementation Notes for DNS Security (DNSSEC)" opens the possibility that knobs can be included, which is the prerogative of the implementer to build and the operator to use (local policy).  I see these two documents as compatible.

The bottom line is that one can choose to abide by a rule of "if a trust anchor is there, ignore other chains" but recall that the choice is made by the validator operator, not the zone administrator, as the validator operator is also responsible for keeping the trust anchors current and accurate, it is their own failure if that is not the case, and they exclusively have the ability to fix a conflict.

The bottom line is that the zone administrator doesn't get a say - it's all up to the validator operators.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 9 Nov 2017 00:01:19 -0500 (EST)

> This is why the guidance in "Protocol Modifications for the DNS Security Extensions" leads to "any" chain. "Clarifications and Implementation Notes for DNS Security (DNSSEC)" opens the possibility…

"prerogative of the implementer" canont apply to how one defines trust
in a protocol. You can't have two implementations make different
trust decisions, especially as most endusers don't control their
resolver.

> The bottom line is that the zone administrator doesn't get a say - it's all up to the validator operators.

It's up to neither. You cannot retroactively argue that hardcoding trust
anchors is an option can that be ignored by an implementation.

knot had a bug some people thought would be a nice fallback recovery
feature to a failed rollover procedure. knot should just be fixed. This
really does not require an RFC update.

Paul

---

From: Edward Lewis <[email-masked]>
Date: Thu, 9 Nov 2017 13:29:34 +0000

>trust decisions, especially as most endusers don't control their

The first split I make when considering this is the difference between general purpose implementations - such as BIND, Unbound, Microsoft's, and others that are distributed to a general population - and turn-key implementations which are purpose built for a specific need.  The latter do exist, are generally not considered when it comes to standards as, for them, conformance to open standards just doesn't matter.

For general purpose implementations, it is up to the distributor of the software to decide what and how to implement.  Whether to faithfully implement a Request for Comments is a choice.  I have been witness to an implementation that tried to fix itself to be more compliant only to find the relying parties balking, requesting a return to the non-conformant behavior.

When it comes to DNS resolution, there is the basic protocol to implement - the messages, the formats, timing, etc.  If not done correctly, a resolution engine may suffer rcode=FORMERR and get nowhere.  But there is a lot of choice for an implementer and still remain interoperable with other software builds.

One feature is what I've often called the "aggressive nature" of searching for an answer.  Neglecting DNSSEC for the moment, in 2012 I tried to write a basic resolver to find information about a popular ranking engine's top zones.  I discovered that many of the zones were "broken" in the sense that the servers operating them did not answer queries for SOA, NS, etc., errors that should have made the zones unreachable.  Yet these zones were ranked as popular.  I realized that general purpose resolvers went beyond the basic strategy for getting an answer, I mentally tagged this as "aggressive resolution".  In the same sense that an experienced librarian may find a reference book that an inexperienced one may not.

DNSSEC offers more choice in terms of aggressive resolution.  For example, if a resolver is suffering a forgery attack (a'la what Kaminsky described long ago now) the first response the resolver would get is the forgery.  If the resolver waited longer, the real answer would likely arrive.  Early, and as far as I know still true for current, resolvers close their listener after getting the forgery.  It is possible to continue listening (but for how long?) to get the real answer.  With DNSSEC proving the first answer wrong, the real answer could be validated - if the listener is not torn down.  I understand why this more aggressive implementation was not chosen.

There is much leeway in what an implementer chooses to encode.  The goal of the RFC series, early on at least, was to give guidance on how to allow interoperability.  The documents are not requirements nor design guides.  I spent a long time with "The Algorithm" in section 4.3.2 of "Domain Concepts and Facilities" (part of STD 13) to come to know what that means.  (Thanks to Rob Austein.)

Implementers, like any kind of writer, have to put their audience foremost in mind.  This is why there are many extra-standards features (and bloat) in software today.  (Round-robin deliver of answers worked its way into mainstream code that way.)  Implementers have to balance simplicity of tools with functionality via complex configurations.  I've been told that many times the operator will just go with the default settings - so that is important.

>It's up to neither. You cannot retroactively argue that hardcoding trust anchors is an option can that be ignored by an implementation.

I don't understand this point.  If you are referring to the practice of general purpose code shipping with a set of trust anchors, at least in BIND one can turn DNSSEC off - or remove/override the packaged defaults.  That is useful when deploying code on a network that is not the global public internet.
    
>knot had a bug some people thought would be a nice fallback recovery feature to a failed rollover procedure. knot should just be fixed. This really does not require an RFC update.

It's not clear whether the "bug" was a "feature you didn't like" or a coding error from this statement, so I don't know what the latter sentence is saying.

I realize I'm writing a lot, and I'm not sure I'm making a strong enough case about why "for the sake of resiliency" any chain that validates ought to be taken as a good thing.  This might take a different approach as trying to talk about "trust" is too ill-defined when discussing a protocol whose basic design did not consider "trust" regarding the data delivered.  "Trustworthiness" in "Clarifications to the DNS Specification" relied on what section the data appeared in a response and from what IP address it came.  Forgeries weren't considered even in that round of clarification.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 9 Nov 2017 09:17:09 -0500

On Thu, Nov 9, 2017 at 12:01 AM, Paul Wouters <[email-masked]> wrote:

> This is why the guidance in "Protocol Modifications for the DNS Security
>> Extensions" leads to "any" chain. "Clarifications and Implementation Notes
>> for DNS Security (DNSSEC)" opens the possibility that knobs can be
>> included, which is the prerogative of the implementer to build and the
>> operator to use (local policy).  I see these two documents as compatible.
>>
>
Paul,

I have been thinking about what you said and why it is perfectly valid, but
that I think it is wrong.
The issue here is three fold IMHO
Operator is using split-DNS i.e. internal and external
Operator is using the SAME name space for both views  i.e. foo.example.com
can exist in both name spaces with different values.
Operator is using DIFFERENT keys to sign the two namespaces.

We have no way at the moment to express  which namespace a "name" comes
from thus you want to give preference to the "internal" namespace for users
of that namespace

The purist in me says this is bad setup, the practical part of me says "you
get what you ask for" i.e. IETF failed to write guidelines for Spit-DNS
thus we should expect things like this.
Either way I think the use of Different Key is what we should strongly
discourage as that makes the other problems go away.

The bottom line is that one can choose to abide by a rule of "if a trust
>> anchor is there, ignore other chains" but recall that the choice is made by
>> the validator operator, not the zone administrator, as the validator
>> operator is also responsible for keeping the trust anchors current and
>> accurate, it is their own failure if that is not the case, and they
>> exclusively have the ability to fix a conflict.
>>

---

From: william manning <[email-masked]>
Date: Fri, 10 Nov 2017 21:09:46 -0800

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

---

From: william manning <[email-masked]>
Date: Fri, 10 Nov 2017 21:11:40 -0800

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 <[email-masked]> wrote:

>> 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
> 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?
>
> 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?