Subject: [DNSOP] Resolver behaviour with multiple trust anchors

From: Moritz Muller <[email-masked]>
Date: Tue, 31 Oct 2017 09:39:23 +0000

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

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 31 Oct 2017 07:42:32 -0700

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.
>
> 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.
>
> 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.
> If we interpret section 4.3 of RFC 4035 then we would have assumed 
> that the signature must be treated as secure.
>

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.

--Paul Hoffman

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 Oct 2017 19:24:14 +0100

>Secure, even if a different chain returns Bogus.

If extra trust anchors are configured for security reasons (as opposed to
availability) then I would expect some sort of longest match on the
trust anchor that is to be used.

For example, if I configure a trust anchor for example.com for security
reasons, then that is probably because I don't fully trust the .com zone
or even the root zone.

If then a record fails to validate using the trust anchor that is configured
for example.com, then it would be very bad if the resolver turns around and
suddenly trusts the information from the .com zone.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 31 Oct 2017 11:25:35 -0700

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:

> 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.
>
> 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.
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 31 Oct 2017 22:30:13 +0400

> 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

> But I suspect the middle one is implemented 

It better, it is the only working solution :)

---

From: Michael StJohns <[email-masked]>
Date: Tue, 31 Oct 2017 15:23:26 -0400

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

A couple of things -

  Make sure that the subordinate trust anchor is still a trust anchor.   
It's possible that  RFC5011, section 5 came into play:

>   Alternately, a trust point that is subordinate to another configured
>     trust point MAY be deleted by a resolver after 180 days, where such a
>   subordinate trust point validly chains to a superior trust point.
>     The decision to delete the subordinate trust anchor is a local
>     configuration decision.  Once the subordinate trust point is deleted,
>     validation of the subordinate zone is dependent on validating the
>     chain of trust to the superior trust point

The idea here was to deal with the transition from unsigned root to 
signed root, but still allow for situations where the subordinate zone 
wanted to ensure it was able to manage its own trust point. This should 
have been a bind/unbound/powerdns configuration item but who knows.

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 validate the chain of
> trust to the response zone. For example, imagine a validator
> configured with trust anchors for "example." and "zone.example."
> When the validator is asked to validate a response to
> "www.sub.zone.example.", either trust anchor could apply.

> When presented with this situation, DNSSEC validators have a choice
> of which trust anchor(s) to use. Which to use is a matter of
> implementation choice. Appendix C discusses several possible
> algorithms.

And once again we see the folly of the words "implementation choice" 
when trying to come up with a coherent DNS.

Later, Mike

---

From: Edward Lewis <[email-masked]>
Date: Tue, 31 Oct 2017 19:33:16 +0000

On 10/31/17, 14:30, "DNSOP on behalf of Paul Wouters" <[email-masked] on behalf of [email-masked]> wrote:

>> Any-TrustedKey-works  
   
>It better, it is the only working solution :)

Can you elaborate...why would it be the "only" "working" solution?

I understand that "Any-TrustedKey-Works" would be hard on implementers (I recall a day when one of the original DNSSEC developers didn't like doing something because it made the code ugly), but it's the one that maximizes robustness.

("What if:" The trust anchor manager was off-line during the time when an Automated Updates [STD 69] revocation was signaled?)

Finding the closest trusted encloser ("trusted" meaning there's a trust anchor data, as opposed to a simple "closest encloser" determined by existence) is simple, finding and handling the list of all trusted enclosure points would make the coding ugly.  That's the only rationale I'd see for not follow a philosophy of "Any-TrustedKey-Works."

---

From: Paul Wouters <[email-masked]>
Date: Tue, 31 Oct 2017 15:52:19 -0400 (EDT)

> Can you elaborate...why would it be the "only" "working" solution?

The idea of the hierarchical model has always been that if you don't
trust the parent, you can configure keys at the level you want. If
I don't trust the root, I can put in a trust anchor for .ca. If I
don't trust .ca, I can put in a trust anchor for nohats.ca.

Allowing "any" key to override that would make me vulnerable to all
my parents, even if I don't want to trust them. I don't want .ca to
be able to put in a DS for internal.nohats.ca in their TLD and steal
my traffic. Now, when I run that zone internally and sign it internally,
and put in the trust anchor, this zone can never be stolen from me by
a parent.

This has always given the parent keys an enigma problem. Get abused once
and we will bypass you. Trusting "any" key will no longer allow me to
untrust a particular zone cut.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Tue, 31 Oct 2017 13:00:38 -0700

> On Tue, 31 Oct 2017, Edward Lewis wrote:
...
>>>> ConfiguredKey-trumps-DS
...
> don't trust .ca, I can put in a trust anchor for nohats.ca.

+1. and this is how DLV worked, for that reason.

> untrust a particular zone cut.

+1. all policy is local.

-- 
P Vixie

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 31 Oct 2017 13:51:42 -0700

>> implementation choice. Appendix C discusses several possible

And the two paragraphs that follow those give more guidance:

    It is possible and advisable to expose the choice of policy as a
    configuration option.  As a default, it is suggested that validators
    implement the "Accept Any Success" policy described in Appendix C.2
    while exposing other policies as configuration options.

    The "Accept Any Success" policy is to try all applicable trust
    anchors until one gives a validation result of Secure, in which case
    the final validation result is Secure.  If and only if all 
applicable
    trust anchors give a result of Insecure, the final validation result
    is Insecure.  If one or more trust anchors lead to a Bogus result 
and
    there is no Secure result, then the final validation result is 
Bogus.

> 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 
list strongly prefer that, others strongly don't.

--Paul Hoffman

---

From: Michael StJohns <[email-masked]>
Date: Tue, 31 Oct 2017 17:03:54 -0400

> list strongly prefer that, others strongly don't.

My main and only desire when querying the DNS is that given the same 
inputs to the system you should always get the same output. Getting 
different answers on something that's as important as security because 
you queried different implementations  continues to seem to be to be a 
bad idea.

Having a standard default (which was not what this was) and having 
configuration options to change it for good reason is different than 
"which to use is a matter of implementation choice".

Later, Mike

---

From: Mark Andrews <[email-masked]>
Date: Wed, 01 Nov 2017 11:50:13 +1100

In message <[email-masked]>, Moritz Muller writes
:
> 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.

Firstly the TLD has mismanged the key rollover if this is the case
assuming that it was expecting TA to be installed for it.  It not
the operator of the validator is in error.

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

Thirdly if you are doing split DNS and you want to enforce that you
only get answers from a particular view you can use DNSSEC to reject
leaked answers.

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 01 Nov 2017 12:31:50 +1100

> +1. and this is how DLV worked, for that reason.

DLV is deepest match.  It also was was only consulted if the answer
validated as insecure with configured trust anchors.  No trust-anchor
above a name means it validated as insecure.

The same data could be used to configure trust anchors which are
used instead of DS records.  Named currently doesn't support this.