IETF Logo Mail Archive

[dnsext] Restating the question in Re: RFC 5155 errata to be

Edward Lewis <ed.lewis@neustar.biz> Wed, 12 December 2012 21:48 UTC

Return-Path: <ed.lewis@neustar.biz>
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 A1E8321E8082 for <dnsext@ietfa.amsl.com>; Wed, 12 Dec 2012 13:48:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.636
X-Spam-Level:
X-Spam-Status: No, score=-100.636 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
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 FNj+WG2cL33u for <dnsext@ietfa.amsl.com>; Wed, 12 Dec 2012 13:48:21 -0800 (PST)
Received: from eastrmfepo103.cox.net (eastrmfepo103.cox.net [68.230.241.215]) by ietfa.amsl.com (Postfix) with ESMTP id B641521E8045 for <dnsext@ietf.org>; Wed, 12 Dec 2012 13:48:20 -0800 (PST)
Received: from eastrmimpo209 ([68.230.241.224]) by eastrmfepo103.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121212214820.MKSJ8874.eastrmfepo103.cox.net@eastrmimpo209> for <dnsext@ietf.org>; Wed, 12 Dec 2012 16:48:20 -0500
Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo209 with cox id aloK1k0063cuADQ01loKEW; Wed, 12 Dec 2012 16:48:19 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020203.50C8FBA3.00FA,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=E5JPVNhl c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=8iiSDJudvygA:10 a=hGBaWAWWAAAA:8 a=nDjYw78bczoA:10 a=A1X0JdhQAAAA:8 a=M8xBIN4vBFyAXt3uEVYA:9 a=wPNLvfGTeEIA:10 a=9k6G2--EmesA:10 a=GnRyT0hFZOalCtqEkfQA:9 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=dw8j2zucSZjQ-d4H:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_A41018B4-6349-409B-BBA7-F9AFEAF8B59E"
From: Edward Lewis <ed.lewis@neustar.biz>
In-Reply-To: <CAH1iCiqEzt0cwHFhmtHvEpWrMjfAdQOunNJfeWvNcdPKpneJSQ@mail.gmail.com>
Date: Wed, 12 Dec 2012 16:48:18 -0500
Message-Id: <27758FE3-D2C6-4F96-9053-376D94FC4626@neustar.biz>
References: <20121206211100.14488.62562.idtracker@ietfa.amsl.com> <82AEB125-F110-40A1-A527-F18BB567EBE4@neustar.biz> <CAH1iCiqEzt0cwHFhmtHvEpWrMjfAdQOunNJfeWvNcdPKpneJSQ@mail.gmail.com>
To: dnsext mailing list <dnsext@ietf.org>
X-Mailer: Apple Mail (2.1283)
Cc: Edward Lewis <ed.lewis@neustar.biz>
Subject: [dnsext] Restating the question in Re: RFC 5155 errata to be
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: Wed, 12 Dec 2012 21:48:21 -0000

I'll begin by admitting I don't understand your message.  So I'll try to ask again.

Yes, it's a MAY.  That means the signer can omit the NSEC3, and that's what matters.  And in the customer's case, the open source signer they are using omits the NSEC3.  (Subtext here - I have no control over the customer's choice nor the design and implementation of the open source code.)

So, let me restate my question.

Using these terms:

"X" is a digit used for convenience
ent"X" - a name that owns no RR set
del"X" - a name that owns an NS set but no DS set
fqdn - a name that goes up to the root
labX - a name that is signed despite opt-out (i.e., has an RR set other than/in addition to NS).

name                  ent in question      does it have NSEC3?
lab1.fqdn.            none                 of course
ent1.fqdn.            node does not exist  it doesn't exist
del1.ent2.fqdn.       ent2.fqdn.           it MAY not, it could
del2.ent3.fqdn.       ent3.fqdn.           it MUST have one
lab2.ent3.fqdn.
del3.ent5.ent4.fqdn.  ent4.fqdn.           not too sure, I guess it MAY not

Upshot - I believe that it is okay to omit the NSEC3 for an ENT whose descendants are ENTs and insecure delegations.

For those following this to this point.  Yes, this is a minor, rare, not that really a big deal case.  I get that.  But it can be fixed.

On Dec 12, 2012, at 15:22, Brian Dickson wrote:

> 
> 
> On Wed, Dec 12, 2012 at 11:22 AM, Edward Lewis <ed.lewis@neustar.biz> wrote:
>  
> I do have a question to start off discussion.
> 
> Does the exemption apply to an empty non-terminal whose descendants are only insecure delegations or to empty non-terminals whose descendants are exclusively insecure delegations or empty non-terminals?
> 
> I think that the only way to formally distinguish between the two scenarios is:
> o   Something would be the former but not the latter, if there were exactly one terminal below the non-terminal-in-question, which was an insecure delegation.
> o   Something would be the latter but not the former, if there were multiple terminals below the non-terminal-in-question, all of which were insecure delegations.
> o   If you have terminal.non-empty1.non-empty2.example.com, which category does "non-empty2" fall into? I think this ambiguity suggests using the latter is safer.
> 
> IMHO, because omitting the empty non-terminals is a MAY, the validator MUST handle the absence correctly regardless, and there should be no problem allowing the zone publisher to do either.
> 
> Which means the less-restrictive one, e.g. the latter exemption.
> 
> Brian

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

v2.23.0 | Report a Bug | By Email