Subject: [DNSOP] Configured Trust Anchor vs. DS record

From: Edward Lewis <[email-masked]>
Date: Thu, 9 Nov 2017 14:39:47 +0000

To set up the problem to solve.  Asking for points that are missed.

(Purposefully omitting the trailing dot, not talking about 'root' because that could get confusing.)

Trust anchor for "one/17" (i.e., key_id=17)

Trust anchor for "two.one/145"

Received data for "three.two.one" signed by "two.one/9342"

What would cause "two.one/9342" to be signed by "one/17" and not by "two.one/145"?  (I think this captures the question of interest.)

1. "two.one/145" is in the MISSING state from STD 69.
2. "two.one/145" was revoked but the validator didn't remove it.
3. "two.one/145" is stale, as the validator is not using STD 69.
4. "two.one" was re-delegated, the previous holder still uses "two.one/145"
5. (open for more scenarios of "why")

What should the validator do with the response?

For cases 1,2,3, the chain ought to be accepted.

For case 4, although the appropriate DNS response (according to the DNS protocol) was received, the application calling it might not want to take action based on the response (action such as open a connection and/or flow data).

Is there a way, within the DNS, to differentiate amongst the reasons why the response is signed up to "one" and not "two.one"?

Is there a way the application can tell?

With DANE as "an application" in mind:  When it comes to DANE, what bothers me is this, in "DNS-Based Authentication for TLS", the section "The Certificate Usage Field" (that is RFC 6698, section 2.1.1), for value "3 -- Certificate usage 3".  For that value, this is stated: "PKIX validation is not tested for certificate usage 3".  My reading of this is that the "problem" with PKIX certificate authorities has just been shifted over to DNS hosting services (in this case for "one"), concerns about the DNS hoster are on par with concerns regarding the certificate authorities.  (In essence, either could re-delegate a name.)  (Yes, this is a tangential off-shoot, anticipating questions about how DANE plays with this.)  In essence, usage 3 removes the benefit of pinning, which the application could use to detect a re-delegation.

---

From: Petr Špaček <[email-masked]>
Date: Thu, 9 Nov 2017 15:48:26 +0100

> With DANE as "an application" in mind:  When it comes to DANE, what bothers me is this, in "DNS-Based Authentication for TLS", the section "The Certificate Usage Field" (that is RFC 6698, section 2…

Nice write-up Edward! You have nicely summarized why Mark and me agree
that validator should use longest suffix match when selecting TA to
validate data.

Things might get even more complicated when negative trust anchors are
configured, bleh. Let me repeat that I very much prefer longest suffix
match because it is predictable, easy to understand, and thus more
secure than "use any".

(And again, this is relevant only to people who bothered to configure TA
for domain different than root, i.e. largely irrelevant for vast
majority of users.)

-- 
Petr Špaček  @  CZ.NIC

---

From: Evan Hunt <[email-masked]>
Date: Thu, 9 Nov 2017 17:48:05 +0000

> that validator should use longest suffix match when selecting TA to

+1.

> configured, bleh.

Fortuantely a negative trust anchor is a longest suffix match too.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Nov 2017 15:45:30 +0000

>    > that validator should use longest suffix match when selecting TA to

Hmmm, that wasn't my intent. ;)  I had been trying to justify the other conclusion.  But, if my work is leading you towards this "other" conclusion, I've been taking time to understand why.

I'm beginning to have a new understanding on this.  The overlooked (by me) point is that we are focusing on a situation where the local operator has chosen to explicitly configure a trust anchor.  Beside code distributions shipping with the IANA managed KSK (or its DS form) for the global public Internet's root zone, if any operator wants another trust anchor point, they have to take explicit action to configure it.  The question is - what is the expectation of the operator in doing this?

There was a time when TLDs were signed but the root zone was not.  Then operators had to configure trust anchors for the TLDs to enable validation.  When the root zone was signed in 2010, the TLDs had to remind all those with trust anchors to remove them (before the TLD could change it's KSK).  I can no longer find reports of the efforts to undo TLD trust anchors (Sweden and maybe CzechRep?) that I thought were once floating around.  "Fears" surrounding this would lead one to favor the more open "any" policies, on the other hand, mass migration from TLDs to root for the top of the trust chain was probably a one-time event as a result of the on-set of DNSSEC in the root zone.

I'm not sure that the need for robustness outweighs the expectation of someone explicitly adding a trust anchor anymore.

OTOH, in the sense "I am not sure" there's the example of split-DNS and poor query path management (i.e., leaks).  I'm not sure if robustness helps here, or is a bad-behavior enabler.

>    Fortuantely a negative trust anchor is a longest suffix match too.

This is an emerging "thing" - more active awareness and management of the trust anchor element of a validator.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Nov 2017 10:15:22 +0800

> I'm not sure that the need for robustness outweighs the expectation of someone explicitly adding a trust anchor anymore.

But that’s not your call to make, but the call of the entity deciding to put in that hard coded trust anchor.

We just ask you not to block us from doing as we have been doing for years.

> OTOH, in the sense "I am not sure" there's the example of split-DNS and poor query path management (i.e., leaks).  I'm not sure if robustness helps here, or is a bad-behavior enabler.

I would like split-DNS to die too but I dont think that’s happening soon.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Nov 2017 20:21:34 -0800

Paul Wouters wrote:
>
>> I'm not sure that the need for robustness outweighs the expectation
>> of someone explicitly adding a trust anchor anymore.
>

+1. all policy is local.

>> OTOH, in the sense "I am not sure" there's the example of split-DNS
>> and poor query path management (i.e., leaks).  I'm not sure if
>> robustness helps here, or is a bad-behavior enabler.
>

-1. like NAT, we will have a better internet if we embrace split-DNS 
rather than wishing it wasn't real or wishing it did not exist.

due to network partitions, both permanent and ephemeral, the global or 
universal namespace should be a last resort, after permitting namespace 
searches at the host, server, LAN, campus, corporate, league, and 
regional layers. names at any layer of this hierarchy should be treated 
as first-class, should be secure, and should be tagged so as to be 
either re-qualified when carried to higher or lower layers, or marked as 
unresolvable by those layers.

whether DNS can adapt remains to be seen. but declaring working and 
desired configurations such as split-DNS to be undesireable, or breaking 
them, or failing to support them, are head-in-sand moves. the internet 
historically responds to head-in-sand moves by moving on in its own way.

-- 
P Vixie

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Nov 2017 03:51:15 -0500 (EST)

> historically responds to head-in-sand moves by moving on in its own way.

For the record, while I don't like split-dns, I do actively support it,
even with DNSSEC, for instance in:

https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns

Paul

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Nov 2017 14:44:45 +0000

>But that’s not your call to make, but the call of the entity deciding to put in that hard-coded trust anchor.

To clarify, the "robustness" was the goal of the protocol design leading up to the 2004 publication of the current DNSSEC definition, it's not a call anyone is making now.

The goals of robustness, local policy, and other factors fed into the current design.  How these, sometimes conflicting, objectives were weighted was subjective and with more 20/20 hindsight, perhaps the weightings were wrong.
    
>We just ask you not to block us from doing as we have been doing for years.

I don't know how to take this - what's being discussed is the way the protocol was designed in the past versus how implementations have chosen to go.  In the spirit of code trumps spec, then specifications need to catch up if there's a deviation.

>I would like split-DNS to die too but I dont think that’s happening soon.

Arguing split-DNS would be another thread, I want to clarify that the "too" in your quote shouldn't implicate anything I've said about split-DNS meaning I wished it to "go away". (I.e., I see split-DNS as a reality.)

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 15 Nov 2017 01:27:00 -0200

> There was a time when TLDs were signed but the root zone was not.  Then operators had to configure trust anchors for the TLDs to enable validation.  When the root zone was signed in 2010, the TLDs…

Yes. And add to that cases were TLDs rolled just before adding to the
root.

https://eng.registro.br/pipermail/gter/2010-May/027981.html
https://eng.registro.br/pipermail/gter/2010-June/028053.html
https://eng.registro.br/pipermail/gter/2010-July/028138.html

Fred

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Nov 2017 23:11:03 -0500 (EST)

> Yes. And add to that cases were TLDs rolled just before adding to the

So what is the security model then?

Let's say .example rolled and now has a bad DS.

Someone overrides this with a local trust anchor so the domain does not
go dark.

- How do you know the roll was legitimate?
- How does an application make a security decision about a found TLSA
   record that depends on this trust anchor?

Now .example rolls to yet another key to fix their mistake and updates
the DS.

- How does the application know the roll is legitimate?
- How does an application make a security decision about a found TLSA
   record that depends on this trust anchor?
- Who, why and when does the local trust anchor get deleted. What if
   _this_ is the key that example.com lost the private key to?

Now same as above, but one of these rolls were done by an attacker and is
malicious.

Trusting "any"thing is just a path to madness.

Paul

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Nov 2017 12:42:57 +0000

To begin...thanks, Frederico, I was trying to find that case but had forgotten which ccTLD was involved.  (Web searches failed me...)

>    So what is the security model then?

Keep in mind that DNSSEC is enabling the receiver to validate the DNS protocol was followed.   (Including, if the DNS has bad data in it, the bad data is protected.)
 
>Let's say .example rolled and now has a bad DS.

This has happened a number of times already.
    
>Someone overrides this with a local trust anchor so the domain does not go dark.

Or configures a negative trust anchor.

>- How do you know the roll was legitimate?

In-band, you can't tell.  But word of mouth speeds quickly, for better or worse.  One quip from one case was "twitter is faster than nagios!"

(I don't know how a DNS message receiver would realize/detect a roll, outside of STD 69's automated updates process.)

>- How does an application make a security decision about a found TLSA record that depends on this trust anchor?

That is a matter for the application, not the DNS.

...

>Now same as above, but one of these rolls were done by an attacker and is malicious.

I am scratching my head a bit trying to first imagine a validator even detecting a key rollover, legit or not.  As it is now, caches are fickle, if what's cached doesn't have the key needed, they SERVFAIL the answer, not get a new copy of the keys (because of rollover-and-die, an issue documented many years ago).  They don't distinguish between a botched rollover and someone one-time forging a response.

>Trusting "any"thing is just a path to madness.
 
Not trusting anything is a path to paranoia. ;)  Madness or paranoia...

The case for "any" trusted chain is rooted in the desire to retain as much robustness when slapping on security.  This assumes that the greater issue lies in operational errors than re-delegation of zones.  The track record shows that operator error is the greater source of DNSSEC invalidations, on the other hand, the thought that data gets misdirected is a concern.

Ask this question...when a validator begins to systematically SERVFAIL data, what happens now?  Followed actions include checking DNSVIZ to see if there's a DNSSEC problem with the authority and potentially negative trust anchors being applied.  (This in the response to trouble tickets being lodged, support desk calls, etc.)  With this as the current response, would preferring trust anchors over DS records (to put this problem tritely) be effective?  Once a validator notes a re-delegation, the operator might just open the flood gates and let all the traffic go to the re-delegation anyway.  (Not, myself, understanding if the operator, when adding a negative trust anchor would realize there was a positive trust anchor for the same name.)