Re: [dnsext] Update to RFC 5155. Maybe?

"Blacka, David" <davidb@verisign.com> Tue, 18 December 2012 23:33 UTC

Return-Path: <davidb@verisign.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D371821E8047 for <dnsext@ietfa.amsl.com>; Tue, 18 Dec 2012 15:33:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwlUothNMbMM for <dnsext@ietfa.amsl.com>; Tue, 18 Dec 2012 15:33:09 -0800 (PST)
Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 11C6D21E805D for <dnsext@ietf.org>; Tue, 18 Dec 2012 15:33:08 -0800 (PST)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUND9M+56A9K1I5QGXQMpJaGuDK7Ea/SS@postini.com; Tue, 18 Dec 2012 15:33:08 PST
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qBINX4gY022387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Dec 2012 18:33:04 -0500
Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Tue, 18 Dec 2012 18:33:04 -0500
From: "Blacka, David" <davidb@verisign.com>
To: Edward Lewis <Ed.Lewis@neustar.biz>
Thread-Topic: [dnsext] Update to RFC 5155. Maybe?
Thread-Index: AQHN3T4/jj5QsHN+sUytFPi+4h6oZZgfiWIA
Date: Tue, 18 Dec 2012 23:33:03 +0000
Message-ID: <FF0B61CC074B174BA3D9A01E8E6C04880DF75B7B@BRN1WNEXMBX02.vcorp.ad.vrsn.com>
References: <20121206211100.14488.62562.idtracker@ietfa.amsl.com> <82AEB125-F110-40A1-A527-F18BB567EBE4@neustar.biz> <50CAF418.5060304@nlnetlabs.nl> <6B0BDF89-EDEB-44AF-83E8-6EDC599B3DAD@neustar.biz> <33CB3A55-89FE-4ABA-A9F8-0C537FADC15A@neustar.biz> <20121217203354.0B2E62D200AD@drugs.dv.isc.org> <95C76953-2D89-4EBC-86D7-BDBBE0379041@neustar.biz>
In-Reply-To: <95C76953-2D89-4EBC-86D7-BDBBE0379041@neustar.biz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <531C0A31FCDE524EBE7547BCC63CE3E9@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: dnsext mailing list <dnsext@ietf.org>
Subject: Re: [dnsext] Update to RFC 5155. Maybe?
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Dec 2012 23:33:10 -0000

On Dec 18, 2012, at 11:39 AM, Edward Lewis <Ed.Lewis@neustar.biz> wrote:

> The first proposed path (adding paragraphs) begins with this, as has already been posted:
> 
> Replace section 7.2.3 with the following.
> 
> 7.2.3.  No Data Responses, QTYPE is not DS
> 
>   If the No Data Response is a result of an empty non-terminal derived 
>   from an insecure delegation covered by an Opt-Out NSEC3 RR, the 
>   closest provable encloser proof MUST be included in the response.  
>   The included NSEC3 RR that covers the "next closer" name for the 
>   delegation MUST have the Opt-Out flag set to one. 
> 
>   In all other cases, the server MUST include the NSEC3 RR that matches 
>   QNAME.  This NSEC3 RR MUST NOT have the bits corresponding to either 
>   the QTYPE or CNAME set in its Type Bit Maps field.
> 
> Replace section 8.5 with the following.
> 
> 8.5.  Validating No Data Responses, QTYPE is not DS
> 
>   If there is an NSEC3 RR that matches QNAME present, the validator must 
>   check that both the QTYPE and the CNAME type are not set in its Type 
>   Bit Maps field.
> 
>   If there is no NSEC3 RR present that matches QNAME, then the validator 
>   MUST verify a closest provable encloser proof for the QNAME.  The 
>   validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that 
>   covers the "next closer" name to the delegation name. This test covers 
>   the case where the response is due to an Empty Non-Terminal derived 
>   from an insecure delegation covered by an Opt-Out NSEC3 RR.
> 
>   Note that this test also covers the case where the NSEC3 RR exists
>   because it corresponds to an empty non-terminal, in which case the
>   NSEC3 RR will have an empty Type Bit Maps field.

I would (at least) swap paragraph 3 and 2 here.  The "this test" in "Note that this test" is referring to the test in paragraph 1.

> 
> There are two other blurbs to add.  First is that the Empty Non-Terminals concerned here include those that have descendant Empty Non-Terminals also eligible for exemption.  And then there is some confusion over having to "verify a closest provable encloser proof" as this means up to 3 NSEC3 RRs are involved.  One demonstrating opt-out is in play, a second that there is no NSEC3 for the name in question, and then a proof about wildcards.  The latter though does not play a role in the processing of the DNS response (ignoring DNSSEC), so that's a bit off the rails.  In addition, there's some looseness when there are "stacked" Empty Non-Terminals - which NSEC3 is used to show that there's no NSEC3 for the desired name.

I've been a bit confused by your confusion about ENTs with descendant ENTs.  When the text says "an empty non-terminal derived from an insecure delegation", it always seemed clear to me that it covers this case.  That is, both of your ENTs are "derived from an insecure delegation", it doesn't matter that they are nested.

I also don't understand the confusion about which NSEC3s are used: you include the NSEC3 matching the closest provable encloser (IOW, the NSEC3 matching the first ancestor that actually has one), and the NSEC3 covering the "next closest name".  That means you would use the same NSEC3s in the responses for all of the generated ENTs.  This is not "loose".

The "verify a closest provable encloser proof" is described in section 8.3 ("Closest Encloser Proof").  If you read that section, it only talks about *two* NSEC3 records (on purpose.)  You only need the third in an NXDOMAIN response.  I can understand some confusion, however, about *why* we don't include the wildcard-covering NSEC3 in opt-out NODATA cases.  I think MarkA explained that better than I might have.

> The other path tries to remedy that, but also is targeted at solving the issue that debugging the problem here was very complex, despite the seemingly simple patch job needed.  Here are some proposed changes to NSEC3 opt-out, which limit its options but bring it in line with what is deployed and implemented.
> 
> Restrict a NSEC3 "chain" (defined by the parameters in the NSEC3PARAM record) to being opt-out or not only.  I.e., no longer support spans that are opt-out here and there, every span between NSEC3'd names is opt-out eligible.

Restrict how?

> Include all Empty Non-Terminals in the NSEC3 chain.  

This would be a big change to signer implementations, and does not represent encoding current operational practice (at least to my knowledge).

> These changes permits DNSSEC code to be called RFC 5155 "fully" compliant - as no one (apparently) has taken time to implement this fully.

I'm not sure what you mean here.  Are you suggesting that if you haven't implemented a zone signer that generates a zone that mixes opt-out and non-opt-out NSEC3 RRs in a zone, you haven't fully implemented RFC 5155?

--
David Blacka                          <davidb@verisign.com> 
Principal               Verisign Infrastructure Engineering