Subject: [dnsext] CNAME check Re: [WGLC: draft-ietf-dnsext-dnssec-bis-updates-16]

From: "Yao Jiankang" <[email-masked]>
Date: Wed, 1 Feb 2012 21:50:14 +0800

For Section 4.3.  "Check for CNAME",

In order to accommade the possible CNAME synthesis extension, how about
adding the following sentence or sentence with the similar meaning in the 
section 4.3?

"
When validating the CNAME, if the CNAME has not matching RRSIG and the 
validator can not decide whether the CNAME is the synthesis of other names 
such as the DNAME, this CNAME should be neglected."

Jiankang Yao

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 01, 2012 8:27 PM
Subject: [dnsext] [WGLC: draft-ietf-dnsext-dnssec-bis-updates-16]

>
> I have read the document and support its publication.
>
> /bill
>
> At 12:49 AM 1/20/2012, Andrew Sullivan wrote:
>>Dear colleagues,
>>
>>This message initiates a three week Working Group Last Call on the
>>document draft-ietf-dnsext-dnssec-bis-updates-16.  LC will close on
>>2012-01-11 at 00:00 UTC.
>>
>>The WG's standard conventions, which require five reviewers who state
>>that they have read the draft and support its publication as a
>>necessary but not sufficient determinant of rough consensus, are in
>>force.  Please review the document and post to the list any comments
>>you have before the close of LC.  If you cannot meet that deadline,
>>but are willing to commit to completing a review and can give me a
>>firm date for it (and that date is within a reasonable horizon), I
>>will announce an extension of the LC deadline.  I'd appreciate it if
>>you'd tell me of this need sooner rather than later.  Specific
>>comments are much better than generic ones, and specific comments with
>>suggested text (if you find some text wanting) are particularly
>>encouraged.
>>
>>Speaking only personally, this draft is the product of several years
>>of WG work: the -00 of the draft was submitted in 2005.  Moreover, it
>>is the product of a lot of heated discussion and careful teasing out
>>of the issues involved.  I would be sad to discover that we could not
>>find (rather) more than five reviewers for this document.
>>
>>I will be the shepherd for this document if it is sent to the IESG.
>>
>>Best regards,
>>
>>Andrew
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext 

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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Feb 2012 10:16:13 -0500

Hi,

No hat.

> "
> When validating the CNAME, if the CNAME has not matching RRSIG and
> the validator can not decide whether the CNAME is the synthesis of
> other names such as the DNAME, this CNAME should be neglected."

In the case of DNAME, you shouldn't need to worry about the synthetic
CNAME because if you are validating you already know about DNSSEC.
Therefore, you can validate the DNAME and know that the CNAME is
synthetic.  So I don't think this text is necessary.

If you're talking about some future example, then I don't think it
will work.  Suppose that we invented RRTYPE FOO that was an xNAME.
FOO did backward compatibility by synthesizing CNAMEs for FOO-unaware
resolvers of some type (let's pretend we signalled awareness using
EDNS0).

Now, imagine a FOO-unaware validating resolver that follows the advice
you suggest.  It queries a signed zone with a FOO record.  The
resolver doesn't know about FOO.  Therefore, it doesn't know that
there could be a synthetic CNAME at that name, resulting from the FOO
record.  Therefore, it will treat the unsigned CNAME as bogus, and the
backwards compatibility doesn't happen.  

Ok, so let's suppose we went further than you did, and said any time
you see a CNAME in a signed zone that is not signed, you should assume
that the unsigned CNAME is synthetic rather than bogus.  This of
course would be a massive hole in DNSSEC: anyone who could convince
you to accept a CNAME any time could undermine your validation.
Therefore, it wouldn't be acceptable.

Is there some other scenario you can see that I haven't outlined
above?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Feb 2012 11:05:01 -0500

Hi,

No hat.

On Wed, Feb 01, 2012 at 11:40:23PM +0800, Yao Jiankang wrote:

> My suggested word is that "this CNAME should be neglected". It means
> that the FOO-unaware validating resolver(when doing DNSSEC checking)
> will see this unsigned CNAME as nothing, not accept it, and also not
> report it as bogus. When a unsigned CNAME appears,  the FOO-unaware
> validating resolver(when doing DNSSEC checking)  just sees nothing
> and negelcts this CNAME. So I do not think that it will cause any
> hole in DNSSEC.

Ok, so the resolver ignores the unsigned CNAME (i.e. it's as though it
wasn't received), and returns what to the initiator of the query
(i.e. the originating resolver or the application or whatever)?
NOERROR with an empty answer?  I don't understand how this is any
better than treating the result as bogus; the originator of the query
still can't get to the destination it was querying for, right?

Best,

A

---

From: "Yao Jiankang" <[email-masked]>
Date: Thu, 2 Feb 2012 09:46:02 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 02, 2012 12:05 AM
Subject: Re: [dnsext] CNAME check Re: [WGLC: 
draft-ietf-dnsext-dnssec-bis-updates-16]

> still can't get to the destination it was querying for, right?
For example,
Assume that the DNSEXT supports BNAME in the future.
 the FOO-unaware validating resolver(when doing DNSSEC checking) will not 
regard the BNAME's CNAME synthesis as bogus. So the section 5.2. " BNAME 
alias algorithm identifiers" is not needed.
 the FOO-unaware validating resolver(when DNSSEC check is not enabled) can 
use the CNAME.(unsigned CNAME is only neglected when DNSSEC check is 
enabled)

Jiankang Yao

Otherwise, the