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

On Thu, Apr 30, 2020 at 11:14 AM Ted Lemon 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

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

On Thu, Apr 30, 2020 at 2:47 PM Ted Lemon wrote: > On Apr 30, 2020, at 2:31 PM, Michael StJohns > 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'

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

On Apr 30, 2020, at 2:31 PM, Michael StJohns 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 > th

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

On 4/30/2020 11:15 AM, Ted Lemon wrote: On Apr 29, 2020, at 8:01 PM, Michael StJohns > 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

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

On Apr 30, 2020, at 12:00 PM, Brian Somers wrote: > 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. Yes, now that I read it with that in mind I see that you are correct. Thanks! _

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

On Apr 30, 2020, at 8:17 AM, Ted Lemon wrote: > > On Apr 29, 2020, at 11:38 PM, Brian Somers wrote: >> 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 insec

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

On Apr 29, 2020, at 11:38 PM, Brian Somers wrote: > 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

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

On Apr 29, 2020, at 8:01 PM, Michael StJohns 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

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

On Apr 29, 2020, at 8:01 PM, Shumon Huque wrote: > > On Wed, Apr 29, 2020 at 7:30 PM Ted Lemon > 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 resp

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

On Thu, Apr 30, 2020 at 5:39 AM Vladimír Čunát wrote: > On 4/30/20 2:01 AM, Shumon Huque wrote: > > It definitely can't set the AD bit. So, I suppose your argument is why > > bother authenticating the target. That's a defensible question. [...] > > Certainly not defensible. The AD bit isn't the

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

On 4/30/20 2:01 AM, Shumon Huque wrote: > It definitely can't set the AD bit. So, I suppose your argument is why > 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 someth

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

On Thursday, 30 April 2020 02:12:15 UTC Shumon Huque wrote: > ... > > Deployed validator code says Insecure. It can't be Bogus, because the > validator has determined that the CNAME is a demonstrably insecure zone, +1. -- Paul ___ DNSOP mailing list

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

On Apr 29, 2020, at 7:12 PM, Shumon Huque wrote: > 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). Absolutely. You only get the AD bit

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

On Wed, Apr 29, 2020 at 8:02 PM Michael StJohns wrote: > 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. > Mike, perhaps there was some confusion on this poi

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

On Wed, Apr 29, 2020 at 7:30 PM Ted Lemon 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 any

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

On 4/29/2020 5:50 PM, Ted Lemon 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 t

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

On Apr 29, 2020, at 7:27 PM, Mark Andrews wrote: > 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. When I’m talking about

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

On Apr 29, 2020, at 6:56 PM, Shumon Huque 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 > authenticat

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

> On 30 Apr 2020, at 07:50, Ted Lemon 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

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

On Wed, Apr 29, 2020 at 5:50 PM Ted Lemon 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 u

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

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