Subject: [DNSOP] Validating responses when following unsigned CNAME chains...

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Apr 2020 17:50:06 -0400

Is there an RFC or draft that talks about what the right thing is to do when an unsigned CNAME points to a record in a signed zone?

That is, suppose we are doing validation. The CNAME doesn’t validate, because it’s not signed. When we look up the record the CNAME points to, do we set the DO bit? Do we validate the answer? Or do we assume that because the CNAME isn’t signed, we don’t need to validate what it points to?

I think the answer is that we validate, but I’m curious to know what others think of this.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 29 Apr 2020 18:56:03 -0400

On Wed, Apr 29, 2020 at 5:50 PM Ted Lemon <[email-masked]> wrote:

> Is there an RFC or draft that talks about what the right thing is to do
> when an unsigned CNAME points to a record in a signed zone?

That is, suppose we are doing validation. The CNAME doesn’t validate,
> because it’s not signed. When we look up the record the CNAME points to, do
> we set the DO bit? Do we validate the answer? Or do we assume that because
> the CNAME isn’t signed, we don’t need to validate what it points to?
>

Hi Ted,

I believe a validating resolver always sets the DO-bit in outbound queries.
The answer in your example can't be authenticated (i.e. no AD bit can be
set) because not all the answers (namely the CNAME) in the response have
been authenticated (per RFC 4035, Section 3.2.3).

But a resolver would still authenticate the RR type at the signed target of
the CNAME (assuming the target has an unbroken chain to the trust anchor),
and record that RRset as authenticated. Otherwise, if it later received a
query directly for the target name/type, it could not return the answer
that it incorrectly didn't bother to authenticate.

Shumon.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Apr 2020 09:27:32 +1000

> On 30 Apr 2020, at 07:50, Ted Lemon <[email-masked]> wrote:
> 

Ted you need to be more precise.  The CNAME validates as insecure.  The output of the validation
process is “provably secure”, “provably insecure”, “bogus”, or “indeterminate” (e.g. because you
can’t get intermediate records in the chain and which you should treat as bogus).  Named combines
the last two as a bogus.  It doesn’t try to distinguish the failure modes.  SERVFAIL will be returned
in either case.

provably insecure:  proved no DS records at a delegation at or above the name, proved that there are only
	unsupported algorithms in the DS RRset at a delegation at or above the name, not under a trust-anchor.

You always validate everything that is under a trust anchor.

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

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Apr 2020 19:30:39 -0400

On Apr 29, 2020, at 6:56 PM, Shumon Huque <[email-masked]> wrote:
> I believe a validating resolver always sets the DO-bit in outbound queries. The answer in your example can't be authenticated (i.e. no AD bit can be set) because not all the answers (namely the CNAME) in the response have been authenticated (per RFC 4035, Section 3.2.3).
> 
> But a resolver would still authenticate the RR type at the signed target of the CNAME (assuming the target has an unbroken chain to the trust anchor), and record that RRset as authenticated. Otherwise, if it later received a query directly for the target name/type, it could not return the answer that it incorrectly didn't bother to authenticate.

Maybe the embedded assumption I’m making here wasn’t clear. I’m talking about a stub resolver implementation. I think that all stub resolvers should be able to be asked to do validation, and should do validation if asked. You could argue that they should be required to do it, but I don’t think we’re there yet, and I’m probably a bit in the rough on requiring resolvers to do validation if asked.

The question is, if the stub resolver can validate, and has been asked to validate, in that case what do we do if the CNAME is not in a secure zone?  Your response makes it sound like you know the answer, but I don’t think it’s specified anywhere. So I’m asking (a) if anybody knows that is specified somewhere, and if so where, and (b) if it is not specified, what do we all think the correct answer is.

Your answer actually brings up a second, also interesting, question: if a stub resolver sets the DO bit, and the CNAME is not in a secure zone, but the answer is in a secure zone, do we set the AD bit? It looks like according to RFC4035, section 3.2.3, we do not. So in that case, is the resolver obliged to validate the answer it gets by following the CNAME? It can’t set the AD bit in this case, right?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Apr 2020 19:31:32 -0400

> 	unsupported algorithms in the DS RRset at a delegation at or above the name, not under a trust-anchor.

When I’m talking about an unsigned CNAME, this is what I mean.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 29 Apr 2020 20:01:23 -0400

> I think the answer is that we validate, but I’m curious to know what others think of this.

See this chain 
https://mailarchive.ietf.org/arch/msg/dnsext/_kxMmGeBUI8OW03tWlcgcCW9QlU/ 
(Yup - 12 years ago).

I don't think I ever managed to convince anyone this was a problem.

If you've got a validated CNAME, that points into an unsecured zone, 
then your state is probably Unsecure (if you treat it similar to a 
secure delegation to an unsigned zone) or Unknown.

If you've got an securely insecure (e.g. delegation was to an insecure 
zone at some point) CNAME that points into a secure zone, I would say 
your result is probably Bogus  or Unsecure as you haven't any way to 
evaluate trust.  I don't think you can bootstrap security this way.

Mike

---

From: Shumon Huque <[email-masked]>
Date: Wed, 29 Apr 2020 20:01:37 -0400

On Wed, Apr 29, 2020 at 7:30 PM Ted Lemon <[email-masked]> wrote:

> The question is, if the stub resolver can validate, and has been asked to
> validate, in that case what do we do if the CNAME is not in a secure zone?
> Your response makes it sound like you know the answer, but I don’t think
> it’s specified anywhere. So I’m asking (a) if anybody knows that is
> specified somewhere, and if so where, and (b) if it is not specified, what
> do we all think the correct answer is.
>

If there is an unsigned CNAME (or DNAME) in the path the answer, then I'm
100% sure that the answer cannot be deemed authenticated. You may be right
that this case is not clearly explained in the spec (I can't recall really,
maybe some else can quote specific text if they know). But conceptually,
DNSSEC requires you to prove an unbroken chain of authenticated signatures
from the queried name back to the trust anchor (including paths redirected
via aliases). Otherwise attackers have a trivial points (the unsigned
aliases) at which to spoof answers.

The answer obtained is still viable, just insecure. Downstream clients of
the stub that need confirmed authenticated answers (e.g. DANE) could
determine this by inspecting the AD bit in the response from the stub.

Your answer actually brings up a second, also interesting, question: if a
> stub resolver sets the DO bit, and the CNAME is not in a secure zone, but
> the answer is in a secure zone, do we set the AD bit? It looks like
> according to RFC4035, section 3.2.3, we do not. So in that case, is the
> resolver obliged to validate the answer it gets by following the CNAME? It
> can’t set the AD bit in this case, right?
>

It definitely can't set the AD bit. So, I suppose your argument is why
bother authenticating the target. That's a defensible question. It might be
reasonable behavior if the stub has no cache. But I'd expect validating
stubs to have some sort of cache to amortize the cost of extra queries and
computation. If it's caching, then the unvalidated target cannot reasonably
be returned if a subsequent query comes directly for the target, so why
would it not bother to validate it earlier.

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 29 Apr 2020 22:12:15 -0400

> I don't think I ever managed to convince anyone this was a problem.

Mike, perhaps there was some confusion on this point 12 years ago, but
deployed validator code all agree on what the state is. I encourage
implementers to confirm (or correct me if I misstate something).

> secure delegation to an unsigned zone) or Unknown.

Assuming the unsecured target zone can be proved to such (because of an
authenticated "insecure" referral, or opt-out referral on the way down to
that
zone), then the state is Insecure - the validator will return the answer,
but not
set AD=1. If the zone is unsigned, yet had a secure referral from the parent
(signed DS), then the state is Bogus, and the validator will return SERVFAIL
(unless the downstream querier set CD=1 and the validator implements a
BAD cache, in which case it will return the bogus answer).

> evaluate trust.  I don't think you can bootstrap security this way.

Deployed validator code says Insecure. It can't be Bogus, because the
validator
has determined that the CNAME is a demonstrably insecure zone,

Shumon.

---

From: Brian Somers <[email-masked]>
Date: Wed, 29 Apr 2020 20:38:59 -0700

> implementers to confirm (or correct me if I misstate something).

Absolutely.  You only get the AD bit if *ALL* RRs in the Answer & Auth
sections are validated as secure.

….
> : If you've got an securely insecure (e.g. delegation was to an insecure 
> : zone at some point) CNAME that points into a secure zone, I would say 
> : your result is probably Bogus  or Unsecure as you haven't any way to 
> : evaluate trust.  I don't think you can bootstrap security this way..
> 
> Deployed validator code says Insecure.. It can't be Bogus, because the validator

Furthermore, the CNAME alias RRset must be validated unless the CD bit is set.
A validating resolver MUST validate and can only return RRsets if they are proven
to be either insecure or secure.  If the aliased RRset is bogus, the answer is
SERVFAIL.

—
Brian

---

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Apr 2020 06:39:26 +0000

On Thursday, 30 April 2020 02:12:15 UTC Shumon Huque wrote:
> ...
> validator has determined that the CNAME is a demonstrably insecure zone,

+1.

-- 
Paul

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 30 Apr 2020 11:39:05 +0200

On 4/30/20 2:01 AM, Shumon Huque wrote:
> bother authenticating the target. That's a defensible question. [...]

Certainly not defensible.  The AD bit isn't the only part.  What if the
CNAME target is spoofed (BOGUS) or something?  Actually, I believe most
end-clients don't look at AD, so it's just the SERVFAILs that protect
them from using spoofed data.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 30 Apr 2020 07:57:58 -0400

On Thu, Apr 30, 2020 at 5:39 AM Vladimír Čunát <[email-masked]>
wrote:

> CNAME target is spoofed (BOGUS) or something?

Yeah, that's a good point, and I agree. The whole response can be spoofed
anyway because the preceding CNAME is insecure. But as a general
security principle, validators should validate everything they are able, in
order
to reduce the number of points in the system where spoofing can happen
undetected.

> Actually, I believe most

In this discussion, I'd read the AD parts as a proxy for the validator's
assessment of the security state of the response (from which the AD
setting is derived). It's true that the majority of clients don't look at
AD,
but there are notable exceptions - quite a few DANE SMTP client
implementations do I believe.

Shumon.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Apr 2020 11:14:26 -0400

On Apr 29, 2020, at 8:01 PM, Shumon Huque <[email-masked]> wrote:
> 
> On Wed, Apr 29, 2020 at 7:30 PM Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> If there is an unsigned CNAME (or DNAME) in the path the answer, then I'm 100% sure that the answer cannot be deemed authenticated. You may be right that this case is not clearly explained in the spec (I can't recall really, maybe some else can quote specific text if they know). But conceptually, DNSSEC requires you to prove an unbroken chain of authenticated signatures from the queried name back to the trust anchor (including paths redirected via aliases). Otherwise attackers have a trivial points (the unsigned aliases) at which to spoof answers. 

I don’t think that’s the issue in this case. The CNAME wasn’t signed, so there was never any question of the answer being protected from spoofing. Your conclusion seems unassailable—this answer can’t be called authentic.

> The answer obtained is still viable, just insecure. Downstream clients of the stub that need confirmed authenticated answers (e.g. DANE) could determine this by inspecting the AD bit in the response from the stub.
> 
> It definitely can't set the AD bit. So, I suppose your argument is why bother authenticating the target. That's a defensible question. It might be reasonable behavior if the stub has no cache. But I'd expect validating stubs to have some sort of cache to amortize the cost of extra queries and computation. If it's caching, then the unvalidated target cannot reasonably be returned if a subsequent query comes directly for the target, so why would it not bother to validate it earlier.

To be clear, I think that if we’ve been asked to do DNSSEC, we should always validate what we can when the answer includes some data that is provably insecure and some data that is provably secure and can be validated. I just don’t think the specs explicitly say that, so I’m wondering if people agree with me on this.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Apr 2020 11:15:46 -0400

On Apr 29, 2020, at 8:01 PM, Michael StJohns <[email-masked]> wrote:
> If you've got an securely insecure (e.g. delegation was to an insecure zone at some point) CNAME that points into a secure zone, I would say your result is probably Bogus  or Unsecure as you haven't any way to evaluate trust.  I don't think you can bootstrap security this way.

I agree that you can’t bootstrap security this way. I would agree that the answer can’t have the AD bit set. However, I don’t see why this arrangement should be considered bogus.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Apr 2020 11:17:22 -0400

> to be either insecure or secure.  If the aliased RRset is bogus, the answer is

Ah. I like this answer. Is there a place where this is stated in the RFC that we can point to?

---

From: Brian Somers <[email-masked]>
Date: Thu, 30 Apr 2020 09:00:00 -0700

> Ah. I like this answer. Is there a place where this is stated in the RFC that we can point to?

I would say RFC 4035 sections 4.2 and 4.3 say this.  Section 5.5 re-iterates that
SERVFAIL should be sent if signatures don’t validate.

—
Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Apr 2020 12:34:13 -0400

> SERVFAIL should be sent if signatures don’t validate.

Yes, now that I read it with that in mind I see that you are correct. Thanks!

---

From: Michael StJohns <[email-masked]>
Date: Thu, 30 Apr 2020 14:31:13 -0400

On 4/30/2020 11:15 AM, Ted Lemon wrote:
> On Apr 29, 2020, at 8:01 PM, Michael StJohns <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> If you've got an securely insecure (e.g. delegation was to an 
>> insecure zone at some point) CNAME that points into a secure zone, I 
>> would say your result is probably Bogus  or Unsecure as you haven't 
>> any way to evaluate trust.  I don't think you can bootstrap security 
>> this way.
>
> I agree that you can’t bootstrap security this way. I would agree that 
> the answer can’t have the AD bit set. However, I don’t see why this 
> arrangement should be considered bogus.
>
Because an attacker can twiddle with a CNAME.  So while the recipient 
sees a CNAME pointing at a validatable end item, that may not have been 
the end name the publisher provided.   I'd probably say unsecure though, 
as I don't expect the client can detect bogus in this case unless there 
was a rule saying this was a bogus configuration.

Mike

ps - What's the validation level for a secured CNAME that points at an 
unsecured CNAME that points to a secured A record?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Apr 2020 14:46:20 -0400

On Apr 30, 2020, at 2:31 PM, Michael StJohns <[email-masked]> wrote:
> Because an attacker can twiddle with a CNAME.  So while the recipient sees a CNAME pointing at a validatable end item, that may not have been the end name the publisher provided.   I'd probably say unsecure though, as I don't expect the client can detect bogus in this case unless there was a rule saying this was a bogus configuration.
> 
> Mike
> 
> ps - What's the validation level for a secured CNAME that points at an unsecured CNAME that points to a secured A record? 
> 
I think that what we’re really talking about is that we have some chain of items where some items are provably not signed, and some are provably signed and have been validated. Any items that do not match one of these two criteria can be treated as “unknown.”  So:

* If _all_ the items are provably signed and have been validated, the answer sets the AD bit.
* If _some_ of the items have been validated, and others are provably not signed, then the answer doesn’t set the AD bit, but an answer is sent.
* If we have a partial answer because we didn’t get some answers, is that any different than the case where we got bogus answers?