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

From: Shumon Huque <[email-masked]>
Date: Fri, 1 May 2020 07:41:11 -0400

On Thu, Apr 30, 2020 at 2:47 PM Ted Lemon <[email-masked]> wrote:

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

yes.

> * 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.
>

yes.

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

Depending on what we didn't get, this answer would be Bogus or
Indeterminate, per RFC 4035, Section 4.3. I think the practical effect of
this is the same for any client of the resolver: SERVFAIL (or if client set
checking disabled, return the partial answers with AD=0,CD=1).

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Fri, 1 May 2020 08:10:02 -0400

On Thu, Apr 30, 2020 at 11:14 AM Ted Lemon <[email-masked]> wrote:

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

Yes, I completely agree.

Whether or not the specs (clearly) state this is debatable. I quickly
scanned 4035 again, and I believe it is implied, from a combination of :

* Section 3.2.3 saying _all_ RRsets in the answer section, and relevant
RRsets in the authority section need to be authenticated before determining
whether AD=1 can be set, and the further statement that the resolver MUST
follow the procedure in Section 5 to determine whether the RRs are
authentic.

* Section 5 , which describes full chain DNSSEC authentication.

This implies to me that _any_ RRset that the validator is processing needs
to be subjected to the full DNSSEC validation algorithm to determine its
security state.

CNAME redirections aren't explicitly described, but are arguably covered by
the above. The only mention of the CNAME case, is the exception to 3.2.3
that allows unsigned CNAMEs to be included in the answer and assessed to be
authentic because they were provably synthesized by a signed DNAME.

Shumon.