From iesg-secretary@ietf.org Thu Dec 6 13:11:00 2012 Return-Path: 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 DD2AD21F8983; Thu, 6 Dec 2012 13:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, 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 e6KE-xvG2T5I; Thu, 6 Dec 2012 13:11:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D38821F898B; Thu, 6 Dec 2012 13:11:00 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121206211100.14488.62562.idtracker@ietfa.amsl.com> Date: Thu, 06 Dec 2012 13:11:00 -0800 Cc: dnsext chair , dnsext mailing list , RFC Editor Subject: [dnsext] Protocol Action: 'Domain Name System (DNS) IANA Considerations' to Best Current Practice (draft-ietf-dnsext-rfc6195bis-05.txt) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 21:11:01 -0000 The IESG has approved the following document: - 'Domain Name System (DNS) IANA Considerations' (draft-ietf-dnsext-rfc6195bis-05.txt) as Best Current Practice This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis/ Technical Summary This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. Working Group Summary This document is to a large extent the same as its predecessor, but the working group has made some simplifications in process and these were not controversial. There is strong consensus behind this document. Document Quality There are many DNS implementations. This document is high quality due to reviews by a number of strong reviewers/experts including Alfred Hoenes and Mark Andrews. Personnel The document Shepherd is Olafur Gudmundsson ogud@ogud.com Ralph Droms is the Responsible Area Director. From ed.lewis@neustar.biz Wed Dec 12 08:22:51 2012 Return-Path: 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 30F2821F852E for ; Wed, 12 Dec 2012 08:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.993 X-Spam-Level: X-Spam-Status: No, score=-99.993 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_50=0.001, HTML_MESSAGE=0.001, 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 jF7s8WScJAl3 for ; Wed, 12 Dec 2012 08:22:37 -0800 (PST) Received: from eastrmfepo101.cox.net (eastrmfepo101.cox.net [68.230.241.213]) by ietfa.amsl.com (Postfix) with ESMTP id 693A921F8531 for ; Wed, 12 Dec 2012 08:22:31 -0800 (PST) Received: from eastrmimpo306 ([68.230.241.238]) by eastrmfepo101.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121212162230.CHIV2891.eastrmfepo101.cox.net@eastrmimpo306> for ; Wed, 12 Dec 2012 11:22:30 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo306 with cox id agNV1k00C3cuADQ01gNVme; Wed, 12 Dec 2012 11:22:29 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020204.50C8AF45.01CA,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=EqRQXFgA c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=hGBaWAWWAAAA:8 a=nVOIQaYKPe4A:10 a=lify1Jt94XxGpU6yRR0A:9 a=CjuIK1q_8ugA:10 a=gRJmqdQGuta-Zgw8hw8A:9 a=_W_S_7VecoQA:10 a=3eLt2EyK_XUBNbMZ: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=_0D788F2C-04BF-4CF0-BE65-8C9331D5F832" From: Edward Lewis In-Reply-To: <20121206211100.14488.62562.idtracker@ietfa.amsl.com> Date: Wed, 12 Dec 2012 11:22:28 -0500 Message-Id: <82AEB125-F110-40A1-A527-F18BB567EBE4@neustar.biz> References: <20121206211100.14488.62562.idtracker@ietfa.amsl.com> To: dnsext mailing list X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: [dnsext] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:22:52 -0000 --Apple-Mail=_0D788F2C-04BF-4CF0-BE65-8C9331D5F832 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii "A customer reported" a difference between two implementations' = responses for a particular query. (I.e., this isn't just from a reading = of the specs, operationally it was noticed.) I talked to a few people = about this already, even obtained proposed errata text, but wanted to = bring this to the open list. The query that is causing the fuss is asking for an A record at an empty = non-terminal in a particular context. The name is in a zone with DNSSEC = on, using NSEC3 and opt-out. Below the empty non-terminal are opt-out = (insecured) delegations. In RFC 5155, section 7.1, bullet #2 there is a = clause that exempts such empty non-terminals from having an NSEC3 = record. What RFC 5155 misses is giving corresponding instructions to the server = and verifier concerning this exemption. Here are proposed changes (that will be filed as an errata at some = point) open to discussion. The origin of the changes is from one of the = original editors of RFC 5155 (meaning that it is in keeping with the = spirit of RFC 5155. I've taken the liberty to reorder two paragraphs = (in whole) because (in my opinion) it read more naturally the way it is = presented. I.e., if I'm wrong, it'll be reverted. Again, this is open = to conversation. Here are the proposed changes: 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=20= from an insecure delegation covered by an Opt-Out NSEC3 RR, the=20 closest provable encloser proof MUST be included in the response. =20 The included NSEC3 RR that covers the "next closer" name for the=20 delegation MUST have the Opt-Out flag set to one.=20 In all other cases, the server MUST include the NSEC3 RR that matches=20= QNAME. This NSEC3 RR MUST NOT have the bits corresponding to either=20= 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=20= check that both the QTYPE and the CNAME type are not set in its Type=20= Bit Maps field. If there is no NSEC3 RR present that matches QNAME, then the validator=20= MUST verify a closest provable encloser proof for the QNAME. The=20 validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that=20= covers the "next closer" name to the delegation name. This test covers=20= the case where the response is due to an Empty Non-Terminal derived=20 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 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? --Apple-Mail=_0D788F2C-04BF-4CF0-BE65-8C9331D5F832 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii "A customer reported"  a = difference between two implementations' responses for a particular = query.  (I.e., this isn't just from a reading of the specs, = operationally it was noticed.)  I talked to a few people about this = already, even obtained proposed errata text, but wanted to bring this to = the open list.

The query that is causing the = fuss is asking for an A record at an empty non-terminal in a particular = context.  The name is in a zone with DNSSEC on, using NSEC3 and = opt-out.  Below the empty non-terminal are opt-out (insecured) = delegations.  In RFC 5155, section 7.1, bullet #2 there is a clause = that exempts such empty non-terminals from having an NSEC3 = record.

What RFC 5155 misses is giving = corresponding instructions to the server and verifier concerning this = exemption.

Here are proposed changes (that will = be filed as an errata at some point) open to discussion.  The = origin of the changes is from one of the original editors of RFC 5155 = (meaning that it is in keeping with the spirit of RFC 5155.  I've = taken the liberty to reorder two paragraphs (in whole) because (in my = opinion) it read more naturally the way it is presented.  I.e., if = I'm wrong, it'll be reverted.  Again, this is open to = conversation.

Here are the proposed = changes:

Replace section 7.2.3 with the = following.

7.2.3.  No Data Responses, QTYPE = is not DS

   from an insecure delegation covered by an = Opt-Out NSEC3 RR, the   closest provable encloser proof MUST be = included in the response.  
 
 
  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 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?

= --Apple-Mail=_0D788F2C-04BF-4CF0-BE65-8C9331D5F832-- From brian.peter.dickson@gmail.com Wed Dec 12 12:22:27 2012 Return-Path: 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 A4C911F0CDC for ; Wed, 12 Dec 2012 12:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 6PWQ4QfAnTnO for ; Wed, 12 Dec 2012 12:22:21 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 933221F0CD6 for ; Wed, 12 Dec 2012 12:22:16 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so802187eek.31 for ; Wed, 12 Dec 2012 12:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0FowkmwtygK+Z+m6bIqFuVzVzrbuM9NJFBTcpPOrWHE=; b=unfb9XpKGRrXZxdFsFEHOef6YxWYFufM9PYgqcvoDh1XRJJNuQuJteQhTQL6quNLWt QwfmKH1rGW9ngawwJy3jnSYTKeeVOD+INGnVMQHlQSlZQgzzsLE9g/Sk9rgXbIsdondH cfVNlshs1q5Jc652CyOaZZXJADzdoz/TDBOTs7b3qTnOGhL+RGEB2rGEuLSlvDrMPQsb icWAqKPD5IurpzcLVahnc9ffXhzDNLoNePK+c9rl/puCQAgg3dhvRMotacdTibYewftP 1fxJYB5w4EV8gCoBlU0F1NCUUVdU7o25yd/O7kpRruKMYpSvJWQ6lUwyc0T/ZGlViGiT dUug== MIME-Version: 1.0 Received: by 10.14.173.65 with SMTP id u41mr5701056eel.13.1355343734930; Wed, 12 Dec 2012 12:22:14 -0800 (PST) Received: by 10.223.173.199 with HTTP; Wed, 12 Dec 2012 12:22:14 -0800 (PST) In-Reply-To: <82AEB125-F110-40A1-A527-F18BB567EBE4@neustar.biz> References: <20121206211100.14488.62562.idtracker@ietfa.amsl.com> <82AEB125-F110-40A1-A527-F18BB567EBE4@neustar.biz> Date: Wed, 12 Dec 2012 15:22:14 -0500 Message-ID: From: Brian Dickson To: Edward Lewis Content-Type: multipart/alternative; boundary=047d7b6226b0de7c7204d0ad8d72 Cc: dnsext mailing list Subject: Re: [dnsext] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 20:22:27 -0000 --047d7b6226b0de7c7204d0ad8d72 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 12, 2012 at 11:22 AM, Edward Lewis 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 --047d7b6226b0de7c7204d0ad8d72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Dec 12, 2012 at 11:22 AM, Edward= Lewis <ed.lewis@neustar.biz> wrote:
=A0
I do have a question to start off discussion.

<= /div>
Does the exemption apply to an empty non-terminal whose descendan= ts are only insecure delegations or to empty non-terminals whose descendant= s are exclusively insecure delegations or empty non-terminals?

I think that the only wa= y to formally distinguish between the two scenarios is:
o =A0 Som= ething would be the former but not the latter, if there were exactly one te= rminal below the non-terminal-in-question, which was an insecure delegation= .
o =A0 Something would be the latter but not the former, if there were = multiple terminals below the non-terminal-in-question, all of which were in= secure delegations.
o =A0 If you have terminal.non-empty1.non-empty2.example.c= om, 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 sho= uld be no problem allowing the zone publisher to do either.

Which means the less-restrictive one, e.g. the latter exemption.=

Brian
--047d7b6226b0de7c7204d0ad8d72-- From ed.lewis@neustar.biz Wed Dec 12 13:48:21 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 In-Reply-To: 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> To: dnsext mailing list X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 21:48:21 -0000 --Apple-Mail=_A41018B4-6349-409B-BBA7-F9AFEAF8B59E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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: >=20 >=20 > On Wed, Dec 12, 2012 at 11:22 AM, Edward Lewis = wrote: > =20 > I do have a question to start off discussion. >=20 > 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? >=20 > 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. >=20 > 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. >=20 > Which means the less-restrictive one, e.g. the latter exemption. >=20 > Brian = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_A41018B4-6349-409B-BBA7-F9AFEAF8B59E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
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.

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-e= mpty1.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.

= --Apple-Mail=_A41018B4-6349-409B-BBA7-F9AFEAF8B59E-- From fanf2@hermes.cam.ac.uk Thu Dec 13 01:38:11 2012 Return-Path: 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 E8D6821F8890 for ; Thu, 13 Dec 2012 01:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.055 X-Spam-Level: X-Spam-Status: No, score=-3.055 tagged_above=-999 required=5 tests=[AWL=-2.545, BAYES_05=-1.11, J_CHICKENPOX_22=0.6] 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 K+3stIUBF7NH for ; Thu, 13 Dec 2012 01:38:11 -0800 (PST) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0DF21F84FC for ; Thu, 13 Dec 2012 01:38:11 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58341) by ppsw-43.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Tj5F3-0005S5-o5 (Exim 4.72) (return-path ); Thu, 13 Dec 2012 09:38:09 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Tj5F3-0008Ra-GK (Exim 4.72) (return-path ); Thu, 13 Dec 2012 09:38:09 +0000 Date: Thu, 13 Dec 2012 09:38:09 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Edward Lewis In-Reply-To: <27758FE3-D2C6-4F96-9053-376D94FC4626@neustar.biz> Message-ID: References: <20121206211100.14488.62562.idtracker@ietfa.amsl.com> <82AEB125-F110-40A1-A527-F18BB567EBE4@neustar.biz> <27758FE3-D2C6-4F96-9053-376D94FC4626@neustar.biz> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870869256-104902095-1355391489=:27013" Sender: Tony Finch Cc: dnsext mailing list Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 09:38:12 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870869256-104902095-1355391489=:27013 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Edward Lewis wrote: > > For those following this to this point. =C2=A0Yes, this is a minor, rare,= not > that really a big deal case. =C2=A0I get that. =C2=A0But it can be fixed. It might not be all that rare. There are a number of TLDs with bits of undelegated 2LD hierarchy, such as co.at - though that isn't such a great example because co.at has a TXT record so avoids the empty non-terminal case. Tony. --=20 f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first= =2E Rough, becoming slight or moderate. Showers, rain at first. Moderate or goo= d, occasionally poor at first. --1870869256-104902095-1355391489=:27013-- From benlaurie@gmail.com Thu Dec 13 02:07:48 2012 Return-Path: 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 1D82D21F8528 for ; Thu, 13 Dec 2012 02:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 To3dAA3bCw3o for ; Thu, 13 Dec 2012 02:07:47 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8659A21F8514 for ; Thu, 13 Dec 2012 02:07:47 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so1934859vbb.31 for ; Thu, 13 Dec 2012 02:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MLdNieGAG9gdpOvQI9Z2rFLyO0GPpgFm7n3Dfchf8TY=; b=jUSUFx+A5uO82DUDMTxoDpPqRQBPWBl5cas2C8BQyragAHPBNneqpihv0v7VFJws38 9qMu9n3jOJtyUlXazY5rmQUaCJCELp4TeIFwKnGcgOZ6P4jOtK78i06FFhqP53P2CLfb K/QqF2ygP5OIHfR9s7IuHa30d4vuGRMsMM1ryxqiMUMmfcIY6KQGR+QR8P4wxNP3F7Zo j9dBX8NPXVBaF8KeCKYA8HntYskpYuAbzO3qTyk3mxR2RCJhZ7o4KUkO68Le5yorgWhw n7cdP23ZR4ym4uUFv2X/eEQ8qQkGHhvxmGUFq82DX+SQKSOYiEX9HQDNuOVfaBUB6vlV 7MPA== MIME-Version: 1.0 Received: by 10.52.26.115 with SMTP id k19mr1871915vdg.67.1355393266761; Thu, 13 Dec 2012 02:07:46 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.58.18.235 with HTTP; Thu, 13 Dec 2012 02:07:46 -0800 (PST) In-Reply-To: <27758FE3-D2C6-4F96-9053-376D94FC4626@neustar.biz> References: <20121206211100.14488.62562.idtracker@ietfa.amsl.com> <82AEB125-F110-40A1-A527-F18BB567EBE4@neustar.biz> <27758FE3-D2C6-4F96-9053-376D94FC4626@neustar.biz> Date: Thu, 13 Dec 2012 10:07:46 +0000 X-Google-Sender-Auth: gnRA0XeIKAYZpCHYr6GoiGkqsc4 Message-ID: From: Ben Laurie To: Edward Lewis Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext mailing list Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 10:07:48 -0000 On Wed, Dec 12, 2012 at 9:48 PM, Edward Lewis wrote: > Upshot - I believe that it is okay to omit the NSEC3 for an ENT whose > descendants are ENTs and insecure delegations. Good, because this matches my understanding. From ed.lewis@neustar.biz Thu Dec 13 05:55:49 2012 Return-Path: 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 033DC21F8AD2 for ; Thu, 13 Dec 2012 05:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.371 X-Spam-Level: X-Spam-Status: No, score=-100.371 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, 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 xtXowEQjNpgb for ; Thu, 13 Dec 2012 05:55:47 -0800 (PST) Received: from eastrmfepo202.cox.net (eastrmfepo202.cox.net [68.230.241.217]) by ietfa.amsl.com (Postfix) with ESMTP id 2A53D21F8AD1 for ; Thu, 13 Dec 2012 05:55:40 -0800 (PST) Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo202.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121213135539.NMIW6475.eastrmfepo202.cox.net@eastrmimpo210> for ; Thu, 13 Dec 2012 08:55:39 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo210 with cox id b1ve1k00e3cuADQ011vfVl; Thu, 13 Dec 2012 08:55:39 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020202.50C9DE5B.0099,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=R/2B6KtX c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=1INb2gYEbywA:10 a=hGBaWAWWAAAA:8 a=z7baZLgXu0MA:10 a=tfxheNegfN9ig3Z-NKsA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=iygZacO8AAAA:8 a=HcKlso_G38RVk8BNzbUA:9 a=_W_S_7VecoQA:10 a=Xtk2VM4ZHkkW1k91: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=_22316B54-FCE0-4AA0-994D-6F2ED51DAE27" From: Edward Lewis In-Reply-To: Date: Thu, 13 Dec 2012 08:55:40 -0500 Message-Id: <168D7501-D459-4268-913E-D39B4D7D82D5@neustar.biz> References: <20121206211100.14488.62562.idtracker@ietfa.amsl.com> <82AEB125-F110-40A1-A527-F18BB567EBE4@neustar.biz> <27758FE3-D2C6-4F96-9053-376D94FC4626@neustar.biz> To: dnsext mailing list X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 13:55:49 -0000 --Apple-Mail=_22316B54-FCE0-4AA0-994D-6F2ED51DAE27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I should clarify - configuring these empty non-terminals isn't that = rare, as you note, top level domains are rife with them. What's rare is = getting asked for, say, the A record at such a name. It's not like = "$empty-no-terminal/IN/ANY +dnssec" will yield as much data as a name = that actually owns records. On Dec 13, 2012, at 4:38, Tony Finch wrote: > It might not be all that rare. There are a number of TLDs with bits of > undelegated 2LD hierarchy, such as co.at - though that isn't such a = great > example because co.at has a TXT record so avoids the empty = non-terminal > case. = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_22316B54-FCE0-4AA0-994D-6F2ED51DAE27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Dec 13, 2012, at 4:38, Tony = Finch wrote:
It might not be all = that rare. There are a number of TLDs with bits of
undelegated = 2LD hierarchy, such as co.at - though that = isn't such a great
example because co.at = has a TXT record so avoids the empty = non-terminal
case.

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

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

= --Apple-Mail=_22316B54-FCE0-4AA0-994D-6F2ED51DAE27-- From ogud@ogud.com Thu Dec 13 14:03:26 2012 Return-Path: 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 1842F21F86D6 for ; Thu, 13 Dec 2012 14:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.264 X-Spam-Level: X-Spam-Status: No, score=-103.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, 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 ZulZUllLarp8 for ; Thu, 13 Dec 2012 14:03:25 -0800 (PST) Received: from smtp188.dfw.emailsrvr.com (smtp188.dfw.emailsrvr.com [67.192.241.188]) by ietfa.amsl.com (Postfix) with ESMTP id 33E1A21F8644 for ; Thu, 13 Dec 2012 14:03:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp18.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id B794E2680C4 for ; Thu, 13 Dec 2012 17:03:24 -0500 (EST) X-Virus-Scanned: OK Received: by smtp18.relay.dfw1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 7674026815D for ; Thu, 13 Dec 2012 17:03:24 -0500 (EST) Message-ID: <50CA50AA.1070206@ogud.com> Date: Thu, 13 Dec 2012 17:03:22 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "" Content-Type: multipart/alternative; boundary="------------080908000502000300020609" Subject: [dnsext] RFC2671bis issue that requires more discussion X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:03:26 -0000 This is a multi-part message in MIME format. --------------080908000502000300020609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Colleagues, During IETF last call the closing of the extended labels registry was called in question as premature. The discussion in question starts with this message: http://www.ietf.org/mail-archive/web/ietf/current/msg75147.html Thus the question to the working group is: Is the action recommenced in RFC2671bis to close the extended labels registry and obsolete the assignments in there (bit labels and expansion to larger label type identifier), a) based on solid experience b) justified and supported by the working group or should the document be revised? Olafur & Andrew ps: See: http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-10 --------------080908000502000300020609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Colleagues,

During IETF last call the closing of the extended labels registry was called in question as premature.
The discussion in question starts with this message:
http://www.ietf.org/mail-archive/web/ietf/current/msg75147.html

Thus the question to the working group is:
Is the action recommenced in RFC2671bis to close the extended labels registry and obsolete the assignments in there (bit labels and expansion to larger label type identifier),

    a) based on solid experience
    b) justified and supported by the working group

or should the document be revised?

    Olafur & Andrew

ps: See: http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-10

--------------080908000502000300020609-- From matthijs@nlnetlabs.nl Fri Dec 14 01:40:50 2012 Return-Path: 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 8DAAE21F86EF for ; Fri, 14 Dec 2012 01:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 n2PfifX+fDa9 for ; Fri, 14 Dec 2012 01:40:49 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C6421F86EC for ; Fri, 14 Dec 2012 01:40:48 -0800 (PST) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id qBE9eadC096983 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 14 Dec 2012 10:40:37 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.1 open.nlnetlabs.nl qBE9eadC096983 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1355478038; bh=svWPF9xxP/Gc546Ji2dbVBKxg8WUNzZC0TFKn3hFYSQ=; h=Date:From:To:Subject:References:In-Reply-To; b=dUF24zo5UboJbp3BVGpnWs+V6WnnnvFz301czrS81UDjMbHvPaZ+ZzQNvCUKNWYeA 4ST8BUvFGDNcrJNJmZFAaXA+vgCXeYbQK+dwnXfX23qaLRzTGzJmHmH68Km4saTp6f QQccDPPm9roIcDGALnqq1vWl/q/SqbMRxuawxlf8= Message-ID: <50CAF418.5060304@nlnetlabs.nl> Date: Fri, 14 Dec 2012 10:40:40 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <20121206211100.14488.62562.idtracker@ietfa.amsl.com> <82AEB125-F110-40A1-A527-F18BB567EBE4@neustar.biz> In-Reply-To: <82AEB125-F110-40A1-A527-F18BB567EBE4@neustar.biz> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Fri, 14 Dec 2012 10:40:37 +0100 (CET) Subject: Re: [dnsext] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 09:40:50 -0000 Hi, On 12/12/2012 05:22 PM, Edward Lewis wrote: > "A customer reported" a difference between two implementations' > responses for a particular query. (I.e., this isn't just from a > reading of the specs, operationally it was noticed.) I talked to a > few people about this already, even obtained proposed errata text, > but wanted to bring this to the open list. > > The query that is causing the fuss is asking for an A record at an > empty non-terminal in a particular context. The name is in a zone > with DNSSEC on, using NSEC3 and opt-out. Below the empty > non-terminal are opt-out (insecured) delegations. In RFC 5155, > section 7.1, bullet #2 there is a clause that exempts such empty > non-terminals from having an NSEC3 record. > > What RFC 5155 misses is giving corresponding instructions to the > server and verifier concerning this exemption. > > Here are proposed changes (that will be filed as an errata at some > point) open to discussion. The origin of the changes is from one > of the original editors of RFC 5155 (meaning that it is in keeping > with the spirit of RFC 5155. I've taken the liberty to reorder two > paragraphs (in whole) because (in my opinion) it read more > naturally the way it is presented. I.e., if I'm wrong, it'll be > reverted. Again, this is open to conversation. > > Here are the proposed changes: > > 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. This is new in essence the same behavior as QTYPE is DS, right? > 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 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 am not sure what distinction you are trying to make here. I think the exemption apply to an empty non-terminal that is derived from only insecure delegations. It is possible that the insecure delegation is not the direct descendant of the empty non-terminal (like in your example with ent4 and ent5 in a later follow-up mail) Best regards, Matthijs > > > > _______________________________________________ dnsext mailing > list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > From ed.lewis@neustar.biz Fri Dec 14 05:47:22 2012 Return-Path: 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 EF3BB21F855B for ; Fri, 14 Dec 2012 05:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.685 X-Spam-Level: X-Spam-Status: No, score=-100.685 tagged_above=-999 required=5 tests=[AWL=0.517, 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 ITyzNiCm+Rlc for ; Fri, 14 Dec 2012 05:47:19 -0800 (PST) Received: from eastrmfepo103.cox.net (eastrmfepo103.cox.net [68.230.241.215]) by ietfa.amsl.com (Postfix) with ESMTP id 98B2A21F8542 for ; Fri, 14 Dec 2012 05:47:19 -0800 (PST) Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo103.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121214134717.WSQQ8874.eastrmfepo103.cox.net@eastrmimpo210> for ; Fri, 14 Dec 2012 08:47:17 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo210 with cox id bRnG1k00E3cuADQ01RnGtg; Fri, 14 Dec 2012 08:47:16 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020204.50CB2DE5.0021,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=R/2B6KtX c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=_9IglDEDmCcA:10 a=hGBaWAWWAAAA:8 a=UTaRa_Gd1_sA:10 a=48vgC7mUAAAA:8 a=W_wj7Ibh1qXQph3U6UgA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=UIYj5LRcGmoA:10 a=rpmKdn9td4TT1KNM88cA:9 a=_W_S_7VecoQA:10 a=aHlL9lVAoknSHqVv: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=_6D2E74F2-3C37-437E-B9B7-A3D9CB55EE8C" From: Edward Lewis In-Reply-To: <50CAF418.5060304@nlnetlabs.nl> Date: Fri, 14 Dec 2012 08:47:16 -0500 Message-Id: <6B0BDF89-EDEB-44AF-83E8-6EDC599B3DAD@neustar.biz> References: <20121206211100.14488.62562.idtracker@ietfa.amsl.com> <82AEB125-F110-40A1-A527-F18BB567EBE4@neustar.biz> <50CAF418.5060304@nlnetlabs.nl> To: dnsext mailing list X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [dnsext] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 13:47:22 -0000 --Apple-Mail=_6D2E74F2-3C37-437E-B9B7-A3D9CB55EE8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 14, 2012, at 4:40, Matthijs Mekking wrote: > This is new in essence the same behavior as QTYPE is DS, right? What is new in the errata is, for the server, instructions to include = the SOA set and one NSEC3 set which demonstrates that the NSEC3 = corresponding to the QNAME is absent. For the validator, if a response = contains these two sets in the authority with no answer, then the answer = is valid. My assumption is that, as for any other name below where = security stops, the AD bit would not be set (in the case of a validator = being a component of a recursive server). > I am not sure what distinction you are trying to make here. >=20 > I think the exemption apply to an empty non-terminal that is derived > from only insecure delegations. It is possible that the insecure > delegation is not the direct descendant of the empty non-terminal > (like in your example with ent4 and ent5 in a later follow-up mail) The question is centered on the last sentence. I assume that the case = as described there would be included in the exemption, i.e., that the = exemption is not limited to empty non-terminals that have as descendants = only (ONLY) nodes that own only (ONLY) an NS set each. That is the = distinction. Referring to "an empty non-terminal that is derived from only insecure = delegations" I want to be sure that I understand. (Because the word = derived is not one we've used in this context before.) An empty = non-terminal name only exists only because it has descendants. Exists = in the sense that asking for data sets owned by it does not generate an = NXDOMAIN and the the existence of the empty non-terminal has a bearing = on wild card processing. If all of the descendants are opt-out insecure = delegations, that (I'm assuming) fits your description. I'd calling = restricting the omission of empty non-terminals from the NSEC3 to just = such empty non-terminals a "conservative" interpretation. In (http://www.ietf.org/mail-archive/web/dnsext/current/msg12823.html) = Ben notes that the "more liberal" interpretation is what he assumes. = I.e., the descendants of the empty non-terminal can also include empty = non-terminals that otherwise qualify for the exemption. = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_6D2E74F2-3C37-437E-B9B7-A3D9CB55EE8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
This is new in essence the same behavior as QTYPE is = DS, right?

What is new in the = errata is, for the server, instructions to include the SOA set and one = NSEC3 set which demonstrates that the NSEC3 corresponding to the QNAME = is absent.  For the validator, if a response contains these two = sets in the authority with no answer, then the answer is valid.  My = assumption is that, as for any other name below where security stops, = the AD bit would not be set (in the case of a validator being a = component of a recursive server).

I am not sure what distinction you are trying to make = here.

I think the exemption apply to an empty non-terminal that = is derived
from only insecure delegations. It is possible that the = insecure
delegation is not the direct descendant of the empty = non-terminal
(like in your example with ent4 and ent5 in a later = follow-up mail)

The question = is centered on the last sentence.  I assume that the case as = described there would be included in the exemption, i.e., that the = exemption is not limited to empty non-terminals that have as descendants = only (ONLY) nodes that own only (ONLY) an NS set each.  That is the = distinction.

Referring to "an empty non-terminal = that is derived from only insecure delegations" I want to be sure = that I understand.  (Because the word derived is not one we've used = in this context before.)  An empty non-terminal name only = exists only because it has descendants.  Exists in the sense = that asking for data sets owned by it does not generate an NXDOMAIN and = the the existence of the empty non-terminal has a bearing on wild card = processing.  If all of the descendants are opt-out insecure = delegations, that (I'm assuming) fits your description.  I'd = calling restricting the omission of empty non-terminals from the NSEC3 = to just such empty non-terminals a "conservative" = interpretation.

In (http://www.ietf.org/mail-archive/web/dnsext/current/msg12823.html) = Ben notes that the "more liberal" interpretation is what he assumes. =  I.e., the descendants of the empty non-terminal can also include = empty non-terminals that otherwise qualify for the = exemption.

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

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

= --Apple-Mail=_6D2E74F2-3C37-437E-B9B7-A3D9CB55EE8C-- From rafiee@hpi.uni-potsdam.de Fri Dec 14 09:18:45 2012 Return-Path: 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 47F9D21F8422; Fri, 14 Dec 2012 09:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[AWL=1.669, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] 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 bsrX9TZcjf6f; Fri, 14 Dec 2012 09:18:43 -0800 (PST) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 7640A21F8907; Fri, 14 Dec 2012 09:18:43 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 3012216A00E; Fri, 14 Dec 2012 18:18:41 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Fri, 14 Dec 2012 18:18:39 +0100 From: "Rafiee, Hosnieh" To: "Int-area@ietf.org" Date: Fri, 14 Dec 2012 18:18:37 +0100 Thread-Topic: Call for the adoption of draft-rafiee-intarea-CGA-TSIG Thread-Index: Ac3aHtFFFtVD9r7kR+GWjIzerXvptw== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924EB86C58A8MXMA1Rhpiuni_" MIME-Version: 1.0 Cc: "DNSOP@ietf.org" , "dnsext@ietf.org" , "Suresh Krishnan \(suresh.krishnan@ericsson.com\)" Subject: [dnsext] Call for the adoption of draft-rafiee-intarea-CGA-TSIG X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:18:45 -0000 --_000_EA738325B0580041A50A364F5F76B68924EB86C58A8MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I am presenting this document for adoption in either the intarea wg or the = dnsext wg or dnsop wg. I believe that I have considered all the comments th= at I received and incorporated what was applicable into this draft thus mak= ing it a much improved draft. I also read most of the RFCs dealing with SSH= and its use in DNS that Dave suggested. Even though you say that CGA is co= mplex, I proved in my draft, based on the experimental results, that it can= be generated less than 600 milliseconds. SSH also has its own complexity.= As you know, SSH uses different ports, and so, one needs to integrate SSH = with the current DNS implementations in order to have the authentication ac= cepted using port 22. It is for this reason that I do not believe that the = use of SSH is a good solution for the current problem, i.e., secure authent= ication in NDP and SEND enabled networks. My solution only involves the use of the same cached value available in the= node. I have implemented this solution and the implementation of CGA-TSIG = won the first place prize at the 5th IPv6 International Contest as a soluti= on for securing DNS against spoofing attacks. Here is a summary of what is being proffered: - Using the cached value, available in a node, for authentication purposes = for o A client to authenticate a resolver o A DNS server to authenticate another DNS server or a client who wants to = update its resource records on that server. - This approach is applicable in all networks using SEND to secure them - The implementation of this approach is now available for a Windows client= (that I will extend to Linux clients) and for PowerDNS as a server. For th= e client, it is easily installed. A user, with little computer experience, = can install it as he just needs to click on the "NEXT" button. But for Pow= erDNS, as the powerDNS has its own configuration, it is equally as easy. - Analysis of the data from our many experiments shows that the CGA genera= tion, using a sec value 1, which provides enough security for the network, = is less than 600 milliseconds. Finally, the purpose of this draft is to demonstrate how to minimize human = intervention, as much as possible, in performing the update process and res= olving a query . When, in a network ,a good node (a legitimate node) goes b= ad, because of a virus or an attacker takes control of one of the legitimat= e nodes in a network, CGA-TSIG will prevent spoofing attacks against this D= NS server. If there are any questions with regard to this draft, feel free to ask me = for clarification. Finally, do not forget to reply with +1 if you would like to support this s= olution. http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-01 Thank you, Hosnieh --_000_EA738325B0580041A50A364F5F76B68924EB86C58A8MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I am presenting this document for adopti= on in either the intarea wg or the dnsext wg or dnsop wg. I believe that I = have considered all the comments that I received and incorporated what was = applicable into this draft thus making it a much improved draft. I also rea= d most of the RFCs dealing with SSH and its use in DNS that Dave suggested.= Even though you say that CGA is complex, I proved in my draft, based on th= e experimental results, that it can be generated less than 600 milliseconds= .  SSH also has its own complexity. As you know, SSH uses different po= rts, and so, one needs to integrate SSH with the current DNS implementation= s in order to have the authentication accepted using port 22. It is for thi= s reason that I do not believe that the use of SSH is a good solution for t= he current problem, i.e., secure authentication in NDP and SEND enabled net= works.

My solution only involve= s the use of the same cached value available in the node. I have implemente= d this solution and the implementation of CGA-TSIG won the first place priz= e at the 5th IPv6 International Contest as a solution for securi= ng DNS against spoofing attacks.

Here is a summary of what is being proffered:

- Using the cached value, available in a node, for authentication= purposes for

o <= span style=3D'font-size:12.0pt;font-family:"Arial","sans-serif"'>A client t= o authenticate a resolver

A DNS server to authenticate another DNS server or a client who wants t= o update its resource records on that server.

- This approach is applicable in all networks using SEND to secure= them

- The implementation of this ap= proach is now available for a Windows client (that I will extend to Linux c= lients) and for PowerDNS as a server. For the client, it is easily installe= d. A user, with little computer experience, can install it as he just needs= to click on the  “NEXT” button. But for PowerDNS, as the = powerDNS has its own configuration, it is equally as easy.

-  Analysis of the data from our many experiment= s shows that the CGA generation, using a sec value 1, which provides enough= security for the network, is less than 600 milliseconds.

Finally, the purpose of this d= raft is to demonstrate how to minimize human intervention, as much as possi= ble, in performing the update process and resolving a query . When, in a ne= twork ,a good node (a legitimate node) goes bad, because of a virus or an a= ttacker takes control of one of the legitimate nodes in a network, CGA-TSIG= will prevent spoofing attacks against this DNS server.

If there are any  questions = with regard to this draft, feel free to ask me for clarification.

Finally, do not forget = to reply with +1 if you would like to support this solution.

http://tools.ietf.org/html/draf= t-rafiee-intarea-cga-tsig-01

Thank you,

Hosnieh

&n= bsp;

= --_000_EA738325B0580041A50A364F5F76B68924EB86C58A8MXMA1Rhpiuni_-- From matthijs@nlnetlabs.nl Mon Dec 17 03:00:28 2012 Return-Path: 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 9CCDF21F8A90 for ; Mon, 17 Dec 2012 03:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 xvMDnP48aTkM for ; Mon, 17 Dec 2012 03:00:27 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D3021F8A7E for ; Mon, 17 Dec 2012 03:00:23 -0800 (PST) Received: from [213.154.224.18] (zoidberg.nlnetlabs.nl [213.154.224.18]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id qBHB0BRj074626 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 17 Dec 2012 12:00:11 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.1 open.nlnetlabs.nl qBHB0BRj074626 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1355742017; bh=KEUPvQbqxrFNGOj6kMS7BDSCj0G/Q9E5QWMIvpHtZAo=; h=Date:From:To:Subject:References:In-Reply-To; b=YoWTs1aVLC09PWQLJsdj7yh8GdK+HdbENVdz7eN7Z7JpgU4LFHphhMt6e/TiSN0QO 0xWLWoYaSRCh7pL2QJX13OFcaUxeuX+Z54YP5KGrWROQvOtaXY4PHZ+I9VWxy+2QR/ ztBJiux/VoMFwITQrp8NoK36I2w+jN/sLpA1HaxE= Message-ID: <50CEFB3D.3000103@nlnetlabs.nl> Date: Mon, 17 Dec 2012 12:00:13 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: dnsext@ietf.org 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> In-Reply-To: <6B0BDF89-EDEB-44AF-83E8-6EDC599B3DAD@neustar.biz> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE645530EE094F63BAF6B2E1A" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Mon, 17 Dec 2012 12:00:12 +0100 (CET) Subject: Re: [dnsext] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 11:00:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE645530EE094F63BAF6B2E1A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/14/2012 02:47 PM, Edward Lewis wrote: >=20 > On Dec 14, 2012, at 4:40, Matthijs Mekking wrote: >=20 >> This is new in essence the same behavior as QTYPE is DS, right? >=20 > What is new in the errata is, for the server, instructions to include > the SOA set and one NSEC3 set which demonstrates that the NSEC3 > corresponding to the QNAME is absent. Your proposed errata text says that a closest provable encloser proof MUST be included. This can be more than one NSEC3 set. I am asking this because I support this errata. We are going to implement this in NSD. I want to confirm that the behavior of these new instructions is the same as 'No Data Responses, QTYPE is DS'. We can reuse code. For the validator, if a response > contains these two sets in the authority with no answer, then the answe= r > is valid. My assumption is that, as for any other name below where > security stops, the AD bit would not be set (in the case of a validator= > being a component of a recursive server). >=20 >> I am not sure what distinction you are trying to make here. >> >> I think the exemption apply to an empty non-terminal that is derived >> from only insecure delegations. It is possible that the insecure >> delegation is not the direct descendant of the empty non-terminal >> (like in your example with ent4 and ent5 in a later follow-up mail) >=20 > The question is centered on the last sentence. I assume that the case > as described there would be included in the exemption, i.e., that the > exemption is not limited to empty non-terminals that have as descendant= s > only (ONLY) nodes that own only (ONLY) an NS set each. That is the > distinction. >=20 > Referring to "an empty non-terminal that is derived from only insecure > delegations" I want to be sure that I understand. (Because the word > derived is not one we've used in this context before.)=20 I got the word from RFC 5155, Section 7.1 Zone Signing, bullet 2: Each empty non-terminal MUST have a corresponding NSEC3 RR, unless the empty non-terminal is only derived from an insecure delegation covered by an Opt-Out NSEC3 RR. An empty > non-terminal name only exists only because it has descendants. Exists > in the sense that asking for data sets owned by it does not generate an= > NXDOMAIN and the the existence of the empty non-terminal has a bearing > on wild card processing. If all of the descendants are opt-out insecur= e > delegations, that (I'm assuming) fits your description. I'd calling > restricting the omission of empty non-terminals from the NSEC3 to just > such empty non-terminals a "conservative" interpretation. >=20 > In (http://www.ietf.org/mail-archive/web/dnsext/current/msg12823.html) > Ben notes that the "more liberal" interpretation is what he assumes. > I.e., the descendants of the empty non-terminal can also include empty= > non-terminals that otherwise qualify for the exemption. I think we are on the same level here. I just want to make clear that all leaf node should be unsigned delegations. And all ents above are only derived from an insecure delegation (or more, but not from signed delegations or other authoritative data). If the leaf node would contain authoritative data, the ent must have an NSEC3. If the leaf node would be an empty non-terminal, well that's not possible: the whole path should not exist, because no ent in that path has a descendant. So, I guess I am in the 'liberal camp' as well. Best regards, Matthijs >=20 > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D- > Edward Lewis =20 > NeuStar You can leave a voice message at +1-571-434-= 5468 >=20 > There are no answers - just tradeoffs, decisions, and responses. >=20 >=20 >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 --------------enigE645530EE094F63BAF6B2E1A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQzvtAAAoJEA8yVCPsQCW5wzcH/jHd/iIoznJAyuVJdC50Um6e mcNSz3cjuY0kMVmVsx41l+yA++RX9okJiEqdjcWO/sYqrXc5y1AZWc2/7Ql9q4ek HMI4KWY/IC9Le4KaYEFTdsG4yuB46ID4wcWAyTAmOorBkL4S82ksZCdsXLN5jUPe AsnYuoE0d89TmP1Nu5CjsJ2UZevRw4FZ5NvOCcLhizUPM1n/oM2g6m8vv2aNB1av VUxTxLGbpUK7r6As35n+m4EELpdqAn9J3GRXyP8ugVQ8ykHj1eybgIimkWlnQ6Y6 RhlAUy5WpIe6nSvGBGhiy3/NkYAZr863XXVV7dBm3y7E/JXo/wq1IXD6aKnVnYo= =rdlt -----END PGP SIGNATURE----- --------------enigE645530EE094F63BAF6B2E1A-- From ed.lewis@neustar.biz Mon Dec 17 06:47:48 2012 Return-Path: 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 93D7521F8658 for ; Mon, 17 Dec 2012 06:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.49 X-Spam-Level: X-Spam-Status: No, score=-101.49 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, 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 IlWAgHEz6Hp4 for ; Mon, 17 Dec 2012 06:47:48 -0800 (PST) Received: from eastrmfepo102.cox.net (eastrmfepo102.cox.net [68.230.241.214]) by ietfa.amsl.com (Postfix) with ESMTP id 0478921F848B for ; Mon, 17 Dec 2012 06:47:47 -0800 (PST) Received: from eastrmimpo110 ([68.230.241.223]) by eastrmfepo102.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121217144747.LHUI18834.eastrmfepo102.cox.net@eastrmimpo110> for ; Mon, 17 Dec 2012 09:47:47 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo110 with cox id cenn1k0023cuADQ01ennoz; Mon, 17 Dec 2012 09:47:47 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020204.50CF3093.00E8,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=N5Wr5hBB c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=kj9zAlcOel0A:10 a=hGBaWAWWAAAA:8 a=aQ_bs-lrCkQA:10 a=hdSp49h4qcTkazhA5H4A:9 a=CjuIK1q_8ugA:10 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Edward Lewis In-Reply-To: <6B0BDF89-EDEB-44AF-83E8-6EDC599B3DAD@neustar.biz> Date: Mon, 17 Dec 2012 09:47:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <33CB3A55-89FE-4ABA-A9F8-0C537FADC15A@neustar.biz> 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> To: dnsext mailing list X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: [dnsext] A question on opt-out implementations X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 14:47:48 -0000 I wanted to ask this question in it's own thread. In RFC 5155, a zone can elect to opt-out (from the NSEC3 chain) unsigned = delegations and any empty non-terminals that "parent" only unsigned = delegations. But a zone does not have to be consistent - it can have = some unsigned delegations in the NSEC3 chain. Are there any implementations that enable mixing opt-out with normal = NSEC3 chain building? None of the tools I've played with allowed me to pick and choose, = offering only a flag that turns the feature "on". Has anyone run across a use case where picking and choosing is needed or = desired? I'm asking out of curiosity but also realizing that because of the "pick = and choose" nature, in many cases an extra NSEC3 record and RRSIG is = needed in responses. That just enlarges the response, not any other = damage, but if we are concerned about response size it is worth looking = into.= From marka@isc.org Mon Dec 17 12:34:09 2012 Return-Path: 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 509FF21F84CA for ; Mon, 17 Dec 2012 12:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 DPO4G-fZ67tJ for ; Mon, 17 Dec 2012 12:34:08 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 9011A21F84C6 for ; Mon, 17 Dec 2012 12:34:08 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 620DBC94E7; Mon, 17 Dec 2012 20:33:59 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1355776447; bh=8y+cT/C10uj/xhBeUb3GoJpUmB4JzVRHLKGN1yQ+H+Q=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=sFeTU7Ykw4i11v9/fyqWblXjKzvLf8aDada5/q1vH9A9hnKPLfb5YZjQYVse4rbJD OHFRwW/IW2V1upLbOf4TlgX3g5keri5yh9IWoMoon+xKrStisIELZvKO0k+5aqFTdW iROnSoKJigZgtmLQ4c5NS1tu3hxhPv5KoVK1Z5Ao= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Mon, 17 Dec 2012 20:33:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3d03:4f13:25d3:3805]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 29AE9216C3D; Mon, 17 Dec 2012 20:33:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0B2E62D200AD; Tue, 18 Dec 2012 07:33:53 +1100 (EST) To: Edward Lewis From: Mark Andrews 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> In-reply-to: Your message of "Mon, 17 Dec 2012 09:47:46 CDT." <33CB3A55-89FE-4ABA-A9F8-0C537FADC15A@neustar.biz> Date: Tue, 18 Dec 2012 07:33:53 +1100 Message-Id: <20121217203354.0B2E62D200AD@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext mailing list Subject: Re: [dnsext] A question on opt-out implementations X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 20:34:09 -0000 In message <33CB3A55-89FE-4ABA-A9F8-0C537FADC15A@neustar.biz>, Edward Lewis writes: > I wanted to ask this question in it's own thread. > > In RFC 5155, a zone can elect to opt-out (from the NSEC3 chain) unsigned > delegations and any empty non-terminals that "parent" only unsigned > delegations. But a zone does not have to be consistent - > it can have some unsigned delegations in the NSEC3 chain. > > Are there any implementations that enable mixing opt-out with normal > NSEC3 chain building? > > None of the tools I've played with allowed me to pick and choose, > offering only a flag that turns the feature "on". Because there is no rational reason to mix and match. We are dealing with hashed names and changing the iteration or salt will change which names fall within a range when hashed. > Has anyone run across a use case where picking and choosing is needed or > desired? There won't be. > I'm asking out of curiosity but also realizing that because of the "pick > and choose" nature, in many cases an extra NSEC3 record and RRSIG is > needed in responses. That just enlarges the response, not any other > damage, but if we are concerned about response size it is worth looking > into. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ed.lewis@neustar.biz Tue Dec 18 08:39:17 2012 Return-Path: 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 01E8821F8A70 for ; Tue, 18 Dec 2012 08:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.245 X-Spam-Level: X-Spam-Status: No, score=-101.245 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, 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 bmKxsoy+1Yjs for ; Tue, 18 Dec 2012 08:39:15 -0800 (PST) Received: from eastrmfepo203.cox.net (eastrmfepo203.cox.net [68.230.241.218]) by ietfa.amsl.com (Postfix) with ESMTP id 3100821F8AA5 for ; Tue, 18 Dec 2012 08:39:07 -0800 (PST) Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo203.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121218163906.WUYC29905.eastrmfepo203.cox.net@eastrmimpo210> for ; Tue, 18 Dec 2012 11:39:06 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo210 with cox id d4f51k00t3cuADQ014f6pG; Tue, 18 Dec 2012 11:39:06 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020207.50D09C2A.0142,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=R/2B6KtX c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=lfhf77dOo4cA:10 a=hGBaWAWWAAAA:8 a=2wkWlQ6YoiIA:10 a=RL0RLb9fkoNnM12wMJQA:9 a=CjuIK1q_8ugA:10 a=AW4evaw7Adk3Aast:21 a=COHeP7mDHUvbcau-:21 a=_W_S_7VecoQA:10 a=1NnByFLOlG-FeoPL: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=_AF466B40-1C8C-4216-891E-D0D69A8F2FCB" From: Edward Lewis In-Reply-To: <20121217203354.0B2E62D200AD@drugs.dv.isc.org> Date: Tue, 18 Dec 2012 11:39:05 -0500 Message-Id: <95C76953-2D89-4EBC-86D7-BDBBE0379041@neustar.biz> 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> To: dnsext mailing list X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 16:39:17 -0000 --Apple-Mail=_AF466B40-1C8C-4216-891E-D0D69A8F2FCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This and last week I posted on a topic involving RFC 5155 and what = appeared to be missing text. I think I've reached that proverbial "rock = and a hard place" position. One problem - for some reason people seem = to be ditching the open discussion that the WG is supposed to foster. = Most of the replies I have received to my messages have been off-list, = making this a headache for me to discern what, at least in my opinion = (which is not necessarily representative of the WG) of what should be = done. I encourage folks to speak on-list... I see that there are two alternatives. One is to take RFC 5155 as is = and fill in the missing text. The other is to step back and take a look = at how RFC 5155 has been put into practice. It is unfortunate to me = that the two alternatives aren't in sync. One path involves adding a few paragraphs to RFC 5155. But the problem = comes in some details. There are two questions that remain open, = including what NSEC3 records are needed to close off the proof. I want to interject this piece of commentary. When DNSSEC was = formulated, NSEC was an "optimal" solution to negative answers, = "optimal" far as protocol engineering was concerned. One side effect of = enabling zone walking was an undesired side effect which what NSEC3 = addresses - but in doing so, we had to "give up something" in terms of = needing more bytes in a response. Another side effect was the huge cost = of transitioning into DNSSEC, which the opt-out feature, tacked on to = NSEC3 addresses. In doing so, we had to give up being able to secure = the unsigned delegations and we created a conflict with how DNS' wild = card mechanism worked. This isn't meant to be a criticism of RFC 5155, = just putting it into context and why it took more than a simple effort = to write. Tradeoffs aside, NSEC3 with opt-out has been a workable solution to two = major drawbacks of the original DNSSEC design. It is deployed in 76 of = the 98 signed operational zones at the upper reaches of the DNS = hierarchy. (Those numbers include the root zone, the immediate TLDs but = omit the 11 test TLDs in place. Exact numbers aside though, NSEC3 is = deployed in operations.) The 76 zones represent about 25% of the total = top zones - including the non-DNSSEC zones. But the version of NSEC3 in operations today is a subset of the NSEC3 = that is in RFC 5155. So far as I can tell, no one has fully implemented = RFC 5155 functionality. Which makes me wonder, if we crimped the = options, can we solve the holes (here) in a better way. So snother path = to fixing the current problem with RFC 5155 is to remove some of the = options available - options that haven't been implemented and cause = complications in the processing of the records. This is something done = in other protocols as the documents advance through the standards = process, something that rarely, if ever, happens in DNS. The downside = of taking on a more aggressive clean up is that there is code deployed = according to the current way things are done. 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=20= from an insecure delegation covered by an Opt-Out NSEC3 RR, the=20 closest provable encloser proof MUST be included in the response. =20 The included NSEC3 RR that covers the "next closer" name for the=20 delegation MUST have the Opt-Out flag set to one.=20 In all other cases, the server MUST include the NSEC3 RR that matches=20= QNAME. This NSEC3 RR MUST NOT have the bits corresponding to either=20= 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=20= check that both the QTYPE and the CNAME type are not set in its Type=20= Bit Maps field. If there is no NSEC3 RR present that matches QNAME, then the validator=20= MUST verify a closest provable encloser proof for the QNAME. The=20 validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that=20= covers the "next closer" name to the delegation name. This test covers=20= the case where the response is due to an Empty Non-Terminal derived=20 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. 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. 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. Include all Empty Non-Terminals in the NSEC3 chain. Part of this stems = from the signer electing to NSEC3 a name based on something the client = cannot verify. When I first was handed the situation, it was unclear if = we had a server malfunction, a signer malfunction, or both, because it = was not clear that the data in question was an Empty Non-Terminal over = opted-out delegations. Lacking the ability to zone walk (which is the = goal of NSEC3), we could not verify this until we got a look at the = zone's contents. A zone may have multiple NSEC3PARAM records (needed for transitions) and = each chain is independent as far as opt-out or not. Again, this is = needed just for transitions as it doesn't make much sense to use both = opt-out and regular NSEC3. This is stated for completeness. The impact of these "radical" steps is to reduce the number of NSEC3 and = RRSIG(NSEC3) in some negative answers. We still need three in NXDOMAIN = situations, so this isn't a terribly great gain but for NoError, NoData = cases it can help. These changes permits DNSSEC code to be called RFC = 5155 "fully" compliant - as no one (apparently) has taken time to = implement this fully. Always signing Empty Non-Terminals brings more = harmony with wild cards and proofs involving them and by limiting the = exemption to only names with NS records and no DS records, that can be = verified in periods of troubleshooting. Comments on list are desired. Conversation on this is desired. This is = presented as a two way choice, but these are not the only two choices = available. --Apple-Mail=_AF466B40-1C8C-4216-891E-D0D69A8F2FCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This and last week I posted on = a topic involving RFC 5155 and what appeared to be missing text.  I = think I've reached that proverbial "rock and a hard place" position. =  One problem - for some reason people seem to be ditching the open = discussion that the WG is supposed to foster.  Most of the replies = I have received to my messages have been off-list, making this a = headache for me to discern what, at least in my opinion (which is not = necessarily representative of the WG) of what should be done.  I = encourage folks to speak on-list...

I see that there = are two alternatives.  One is to take RFC 5155 as is and fill in = the missing text.  The other is to step back and take a look at how = RFC 5155 has been put into practice.  It is unfortunate to me that = the two alternatives aren't in sync.

One path = involves adding a few paragraphs to RFC 5155.  But the problem = comes in some details.  There are two questions that remain open, = including what NSEC3 records are needed to close off the = proof.

I want to interject this piece of = commentary.  When DNSSEC was formulated, NSEC was an "optimal" = solution to negative answers, "optimal" far as protocol engineering was = concerned.  One side effect of enabling zone walking was an = undesired side effect which what NSEC3 addresses - but in doing so, we = had to "give up something" in terms of needing more bytes in a response. =  Another side effect was the huge cost of transitioning into = DNSSEC, which the opt-out feature, tacked on to NSEC3 addresses. =  In doing so, we had to give up being able to secure the unsigned = delegations and we created a conflict with how DNS' wild card mechanism = worked.  This isn't meant to be a criticism of RFC 5155, just = putting it into context and why it took more than a simple effort to = write.

Tradeoffs aside, NSEC3 with opt-out has = been a workable solution to two major drawbacks of the original DNSSEC = design.  It is deployed in 76 of the 98 signed operational zones at = the upper reaches of the DNS hierarchy.  (Those numbers include the = root zone, the immediate TLDs but omit the 11 test TLDs in place. =  Exact numbers aside though, NSEC3 is deployed in operations.) =  The 76 zones represent about 25% of the total top zones - = including the non-DNSSEC zones.

But the version = of NSEC3 in operations today is a subset of the NSEC3 that is in RFC = 5155.  So far as I can tell, no one has fully implemented RFC 5155 = functionality.  Which makes me wonder, if we crimped the options, = can we solve the holes (here) in a better way.  So snother path to = fixing the current problem with RFC 5155 is to remove some of the = options available - options that haven't been implemented and cause = complications in the processing of the records.  This is something = done in other protocols as the documents advance through the standards = process, something that rarely, if ever, happens in DNS.  The = downside of taking on a more aggressive clean up is that there is code = deployed according to the current way things are = done.

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

   from an insecure delegation covered by an = Opt-Out NSEC3 RR, the   closest provable encloser proof MUST be = included in the response.  
 
 
  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.

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.

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.

Include all Empty Non-Terminals in = the NSEC3 chain.  Part of this stems from the signer electing to = NSEC3 a name based on something the client cannot verify.  When I = first was handed the situation, it was unclear if we had a server = malfunction, a signer malfunction, or both, because it was not clear = that the data in question was an Empty Non-Terminal over opted-out = delegations.  Lacking the ability to zone walk (which is the goal = of NSEC3), we could not verify this until we got a look at the zone's = contents.

A zone may have multiple NSEC3PARAM = records (needed for transitions) and each chain is independent as far as = opt-out or not.  Again, this is needed just for transitions as it = doesn't make much sense to use both opt-out and regular NSEC3. =  This is stated for completeness.

The = impact of these "radical" steps is to reduce the number of NSEC3 and = RRSIG(NSEC3) in some negative answers.  We still need three in = NXDOMAIN situations, so this isn't a terribly great gain but for = NoError, NoData cases it can help.  These changes permits DNSSEC = code to be called RFC 5155 "fully" compliant - as no one (apparently) = has taken time to implement this fully.  Always signing Empty = Non-Terminals brings more harmony with wild cards and proofs involving = them and by limiting the exemption to only names with NS records and no = DS records, that can be verified in periods of = troubleshooting.

Comments on list are desired. =  Conversation on this is desired.  This is presented as a two = way choice, but these are not the only two choices = available.

= --Apple-Mail=_AF466B40-1C8C-4216-891E-D0D69A8F2FCB-- From matthijs@nlnetlabs.nl Tue Dec 18 12:31:42 2012 Return-Path: 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 2938A1F0CE1 for ; Tue, 18 Dec 2012 12:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_45=0.6, 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 k-lQmMrvh71n for ; Tue, 18 Dec 2012 12:31:41 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A45661F0CB2 for ; Tue, 18 Dec 2012 12:31:40 -0800 (PST) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id qBIKVNdH022486 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 18 Dec 2012 21:31:24 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.1 open.nlnetlabs.nl qBIKVNdH022486 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1355862685; bh=fTV0V3GjhWgVH5fvNxZ2C6vvZGVg9DMzyw1a0/DUwEM=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=u7fwCrs76u9u4tw9HMDT+YoAPDbOmg31Z/RHbJzS87e8wEaYzhuuUKEL1We+fSr8h Hzn64mjueJj3j5GBhMXKYUjzx6Emlc7YOhNpmqVjzoMBeLuAXCTtgGRmZALl37k+EF H+RlS28awKDD4o2AF247eDbVHQA5LCQQ9ZXkrKI4= Message-ID: <50D0D2A1.701@nlnetlabs.nl> Date: Tue, 18 Dec 2012 21:31:29 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Edward Lewis 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> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Tue, 18 Dec 2012 21:31:24 +0100 (CET) Cc: dnsext mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 20:31:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 12/18/2012 05:39 PM, Edward Lewis 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. I am wondering if for QTYPE is not DS, we need another NSEC3 record, namely the one covering the wildcard. Example: del1.ent2.fqdn. (del1 being an unsigned delegation, ent2 an empty non-terminal) A query for should result in NODATA, but there is no matching NSEC3. Do closest encloser proof with closest provable encloser (NSEC3 matching fqdn.) and next closer (NSEC3 covering ent2.fqdn.). But because there was no matching NSEC3, we still did not proof if ent2.fqdn. could have been expanded from *.fqdn. Hence, we need the NSEC3 denying the source of synthesis. > 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. If the NSEC3 covering the wildcard is required, then the validator of course needs to verify it. > 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. Technically, the proof about wildcards is not part of the closest encloser proof. You would need 2 NSEC3 records at most: One matching the closest (provable) encloser, one covering the next closer. The next closer covering NSEC3 has its Opt-Out bit set, saying the NSEC3 possibly covers insecure delegations (or in this new case: insecure nodata). > 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. Even though there are no implementations (known of) that do the mixture, I don't see why we would restrict this. Mixture is not what is causing this problem. Besides, if some NSEC3s can have the Opt-Out bit clear, because they do not cover unsigned delegations, it adds a little bit more security to the zone (less spans that do not assert the (non-)existence of insecure delegations). > Include all Empty Non-Terminals in the NSEC3 chain. Part of this > stems from the signer electing to NSEC3 a name based on something > the client cannot verify. When I first was handed the situation, > it was unclear if we had a server malfunction, a signer > malfunction, or both, because it was not clear that the data in > question was an Empty Non-Terminal over opted-out delegations. > Lacking the ability to zone walk (which is the goal of NSEC3), we > could not verify this until we got a look at the zone's contents. We played with that thought, because that would make validators happy right now: Just add the NSEC3 at the empty non-terminal and the validator can verify the NODATA with a single NSEC3. I honestly think that is a good alternative. It might be problematic for zones with a lot of structure, like reverse zones (are they even using NSEC3 Opt-Out?). If there would be consensus on such change, your earlier proposed errata is also not needed. > A zone may have multiple NSEC3PARAM records (needed for > transitions) and each chain is independent as far as opt-out or > not. Again, this is needed just for transitions as it doesn't make > much sense to use both opt-out and regular NSEC3. This is stated > for completeness. I would like to keep chains independent. > The impact of these "radical" steps is to reduce the number of > NSEC3 and RRSIG(NSEC3) in some negative answers. We still need > three in NXDOMAIN situations, so this isn't a terribly great gain > but for NoError, NoData cases it can help. These changes permits > DNSSEC code to be called RFC 5155 "fully" compliant - as no one > (apparently) has taken time to implement this fully. Always > signing Empty Non-Terminals brings more harmony with wild cards and > proofs involving them and by limiting the exemption to only names > with NS records and no DS records, that can be verified in periods > of troubleshooting. I think it is rather a strong statement to say that no implementation is fully compliant. What requirements are lacking in nowadays implementations? I do agree that there is a flaw in RFC 5155 (possible for signer to leave out NSEC3 on empty non-terminal to insecure delegation, but validator expects it when quering for that empty non-terminal). I would advise to fix that problem, but not take it as an opportunity to make more radical changes*. Best regards, Matthijs *If we do, I know of a whole bunch of other stuff we could do to reduce the number of NSEC3s needed in responses. > Comments on list are desired. Conversation on this is desired. > This is presented as a two way choice, but these are not the only > two choices available. > > > > > _______________________________________________ dnsext mailing list > dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ0NKgAAoJEA8yVCPsQCW5SFMH/3D8UC5TwVRDVV/+jB0L7qN8 qRSGiqNUR84Woy7pO/1rrUnJpb6DQjkmry2Y9kCW1Qw7e660lrP4cQM7YC11bEYR j+zDad2Nl58mUNmr8sN8vx6KERHPK2eEzonv+n1K1Cn2FdCEwjv8agMP81k8Y+bq io3Z7BdkXIB7OWqjWnmAVwBe6t/0hO/mKSBTramXFm82Kp29dkkjt3NFrxMo67cN VV9srM/AwAKR+v1CnLTNx3+ktsQRGjKq6AZw5sW3yR765fEQN5R5/Cc/zqJ3uTC4 WV+Z47HaCW8Wzx8FwZSuIgKJmLI9Dntbw5FEE7hwXLA19vLJ8KMeQ8LU2VI145o= =JYV3 -----END PGP SIGNATURE----- From marka@isc.org Tue Dec 18 14:22:20 2012 Return-Path: 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 7668121E805A for ; Tue, 18 Dec 2012 14:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_45=0.6] 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 NwK2u4rJGHkD for ; Tue, 18 Dec 2012 14:22:19 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6BE21E8054 for ; Tue, 18 Dec 2012 14:22:19 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 33F58C9508; Tue, 18 Dec 2012 22:22:09 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1355869338; bh=TVP+2zLp9YrvL2opXlGgasMPzK58TnBKFnfTr4+ddDE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Dgqs44R8sVXVU+64jVDGebvShN/nR0drVWyaG0tBQsNx+pdBalaqJwmIlICaKWgXr mg1WxvlgcNJUckyUqRjuH8YHjWSbIbHn8SiZ1zgJAX8/kz2LZEjj5B2uy+HNmbJes7 eJtuLZYeNx+xKSjvF5QokyDncrivVWUptM7Dce2M= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Tue, 18 Dec 2012 22:22:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4144:a5b5:175d:fbda]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 97FFA216C3D; Tue, 18 Dec 2012 22:22:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id BA7BE2D30DA4; Wed, 19 Dec 2012 09:22:02 +1100 (EST) To: Matthijs Mekking From: Mark Andrews 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> <50D0D2A1.701@nlnetlabs.nl> In-reply-to: Your message of "Tue, 18 Dec 2012 21:31:29 BST." <50D0D2A1.701@nlnetlabs.nl> Date: Wed, 19 Dec 2012 09:22:02 +1100 Message-Id: <20121218222202.BA7BE2D30DA4@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Edward Lewis , dnsext mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 22:22:20 -0000 In message <50D0D2A1.701@nlnetlabs.nl>, Matthijs Mekking writes: > Hi, > > On 12/18/2012 05:39 PM, Edward Lewis 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. > > I am wondering if for QTYPE is not DS, we need another NSEC3 record, > namely the one covering the wildcard. Example: > > del1.ent2.fqdn. > > (del1 being an unsigned delegation, ent2 an empty non-terminal) > > A query for should result in NODATA, but there is no > matching NSEC3. Do closest encloser proof with closest provable > encloser (NSEC3 matching fqdn.) and next closer (NSEC3 covering > ent2.fqdn.). But because there was no matching NSEC3, we still did not > proof if ent2.fqdn. could have been expanded from *.fqdn. Hence, we > need the NSEC3 denying the source of synthesis. OPTOUT and wildcards are incompatible with each other. There is no way to prove that there wasn't a delegation that should have blocked the wildcard. > > 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. > > If the NSEC3 covering the wildcard is required, then the validator of > course needs to verify it. > > > 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. > > Technically, the proof about wildcards is not part of the closest > encloser proof. You would need 2 NSEC3 records at most: One matching > the closest (provable) encloser, one covering the next closer. The > next closer covering NSEC3 has its Opt-Out bit set, saying the NSEC3 > possibly covers insecure delegations (or in this new case: insecure > nodata). > > > 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. > > Even though there are no implementations (known of) that do the > mixture, I don't see why we would restrict this. Mixture is not what > is causing this problem. > > Besides, if some NSEC3s can have the Opt-Out bit clear, because they > do not cover unsigned delegations, it adds a little bit more security > to the zone (less spans that do not assert the (non-)existence of > insecure delegations). In addition to not flipping optout state in a chain, no one implements selecting which insecure delegations are to be opted out. Implementations just uses the delegation state secure/insecure to make the decision. > > Include all Empty Non-Terminals in the NSEC3 chain. Part of this > > stems from the signer electing to NSEC3 a name based on something > > the client cannot verify. When I first was handed the situation, > > it was unclear if we had a server malfunction, a signer > > malfunction, or both, because it was not clear that the data in > > question was an Empty Non-Terminal over opted-out delegations. > > Lacking the ability to zone walk (which is the goal of NSEC3), we > > could not verify this until we got a look at the zone's contents. > > We played with that thought, because that would make validators happy > right now: Just add the NSEC3 at the empty non-terminal and the > validator can verify the NODATA with a single NSEC3. I honestly think > that is a good alternative. It might be problematic for zones with a > lot of structure, like reverse zones (are they even using NSEC3 > Opt-Out?). If there would be consensus on such change, your earlier > proposed errata is also not needed. NSEC3 doesn't prevent zone walking in zones with a known structure. The only way to prevent zone walking in these zones is to lie in your negative responses. > > A zone may have multiple NSEC3PARAM records (needed for > > transitions) and each chain is independent as far as opt-out or > > not. Again, this is needed just for transitions as it doesn't make > > much sense to use both opt-out and regular NSEC3. This is stated > > for completeness. > > I would like to keep chains independent. > > > The impact of these "radical" steps is to reduce the number of > > NSEC3 and RRSIG(NSEC3) in some negative answers. We still need > > three in NXDOMAIN situations, so this isn't a terribly great gain > > but for NoError, NoData cases it can help. These changes permits > > DNSSEC code to be called RFC 5155 "fully" compliant - as no one > > (apparently) has taken time to implement this fully. Always > > signing Empty Non-Terminals brings more harmony with wild cards and > > proofs involving them and by limiting the exemption to only names > > with NS records and no DS records, that can be verified in periods > > of troubleshooting. > > I think it is rather a strong statement to say that no implementation > is fully compliant. What requirements are lacking in nowadays > implementations? > > I do agree that there is a flaw in RFC 5155 (possible for signer to > leave out NSEC3 on empty non-terminal to insecure delegation, but > validator expects it when quering for that empty non-terminal). I > would advise to fix that problem, but not take it as an opportunity to > make more radical changes*. > > Best regards, > Matthijs > > > *If we do, I know of a whole bunch of other stuff we could do to > reduce the number of NSEC3s needed in responses. > > > > Comments on list are desired. Conversation on this is desired. > > This is presented as a two way choice, but these are not the only > > two choices available. > > > > > > > > > > _______________________________________________ dnsext mailing list > > dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJQ0NKgAAoJEA8yVCPsQCW5SFMH/3D8UC5TwVRDVV/+jB0L7qN8 > qRSGiqNUR84Woy7pO/1rrUnJpb6DQjkmry2Y9kCW1Qw7e660lrP4cQM7YC11bEYR > j+zDad2Nl58mUNmr8sN8vx6KERHPK2eEzonv+n1K1Cn2FdCEwjv8agMP81k8Y+bq > io3Z7BdkXIB7OWqjWnmAVwBe6t/0hO/mKSBTramXFm82Kp29dkkjt3NFrxMo67cN > VV9srM/AwAKR+v1CnLTNx3+ktsQRGjKq6AZw5sW3yR765fEQN5R5/Cc/zqJ3uTC4 > WV+Z47HaCW8Wzx8FwZSuIgKJmLI9Dntbw5FEE7hwXLA19vLJ8KMeQ8LU2VI145o= > =JYV3 > -----END PGP SIGNATURE----- > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From davidb@verisign.com Tue Dec 18 15:33:09 2012 Return-Path: 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 ; 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 ; 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 ; 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" To: Edward Lewis 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: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 23:33:10 -0000 On Dec 18, 2012, at 11:39 AM, Edward Lewis wrote: > The first proposed path (adding paragraphs) begins with this, as has alre= ady been posted: >=20 > Replace section 7.2.3 with the following. >=20 > 7.2.3. No Data Responses, QTYPE is not DS >=20 > If the No Data Response is a result of an empty non-terminal derived=20 > from an insecure delegation covered by an Opt-Out NSEC3 RR, the=20 > closest provable encloser proof MUST be included in the response. =20 > The included NSEC3 RR that covers the "next closer" name for the=20 > delegation MUST have the Opt-Out flag set to one.=20 >=20 > In all other cases, the server MUST include the NSEC3 RR that matches=20 > QNAME. This NSEC3 RR MUST NOT have the bits corresponding to either=20 > the QTYPE or CNAME set in its Type Bit Maps field. >=20 > Replace section 8.5 with the following. >=20 > 8.5. Validating No Data Responses, QTYPE is not DS >=20 > If there is an NSEC3 RR that matches QNAME present, the validator must= =20 > check that both the QTYPE and the CNAME type are not set in its Type=20 > Bit Maps field. >=20 > If there is no NSEC3 RR present that matches QNAME, then the validator= =20 > MUST verify a closest provable encloser proof for the QNAME. The=20 > validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that= =20 > covers the "next closer" name to the delegation name. This test covers= =20 > the case where the response is due to an Empty Non-Terminal derived=20 > from an insecure delegation covered by an Opt-Out NSEC3 RR. >=20 > 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 t= hat this test" is referring to the test in paragraph 1. >=20 > 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 a= re 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 l= atter though does not play a role in the processing of the DNS response (ig= noring DNSSEC), so that's a bit off the rails. In addition, there's some l= ooseness 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 delega= tion", it always seemed clear to me that it covers this case. That is, bot= h 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 incl= ude the NSEC3 matching the closest provable encloser (IOW, the NSEC3 matchi= ng the first ancestor that actually has one), and the NSEC3 covering the "n= ext closest name". That means you would use the same NSEC3s in the respons= es 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 r= esponse. I can understand some confusion, however, about *why* we don't in= clude the wildcard-covering NSEC3 in opt-out NODATA cases. I think MarkA e= xplained 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 seeming= ly simple patch job needed. Here are some proposed changes to NSEC3 opt-ou= t, which limit its options but bring it in line with what is deployed and i= mplemented. >=20 > Restrict a NSEC3 "chain" (defined by the parameters in the NSEC3PARAM rec= ord) 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 eligibl= e. Restrict how? > Include all Empty Non-Terminals in the NSEC3 chain. =20 This would be a big change to signer implementations, and does not represen= t 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 im= plemented a zone signer that generates a zone that mixes opt-out and non-op= t-out NSEC3 RRs in a zone, you haven't fully implemented RFC 5155? -- David Blacka =20 Principal Verisign Infrastructure Engineering From johnl@taugh.com Tue Dec 18 19:59:38 2012 Return-Path: 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 8FA7E21E8042 for ; Tue, 18 Dec 2012 19:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 uxgN+ZNQki2E for ; Tue, 18 Dec 2012 19:59:37 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A0FD621E803F for ; Tue, 18 Dec 2012 19:59:37 -0800 (PST) Received: (qmail 6480 invoked from network); 19 Dec 2012 03:59:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=194f.50d13ba7.k1212; bh=tSVVAEaBDr5nnXAe2XYsAeHHGeuteajbZDkZPlLl7Ug=; b=n/F64OybrNSDnm5bKXcfVhA2UF/tWhfH25rytKhYvH3d+OnqCODynLPm7nHkHzLNBAq+l8FJw0XX/XXWL5n4x0Twg9Ep+THrewJEqKS6PbmeVmsqfFSFlEBWVUBLCT7VDDwMn6WfdOIw7A3TT3666aFbquYhSf4nh2dDyrpRElU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=194f.50d13ba7.k1212; bh=tSVVAEaBDr5nnXAe2XYsAeHHGeuteajbZDkZPlLl7Ug=; b=ph+hyXi4BdpYpaT6GQF9yP2YCkRwnYlyKepOfpql4+UzFs+nhbZbLixuIpaiVzhN4X/rXMf0uREsGUlJPgxAEop6QRXFoZtVY/ZfDE2nllbCZ9p6VkaVb0gmBbmgkv+RBhUMO8mR4LmSNuDT/rW3COiYhQiG5Dwlbm1hjVC/v24= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 19 Dec 2012 03:59:13 -0000 Date: 18 Dec 2012 22:59:35 -0500 Message-ID: From: "John R Levine" To: dnsext@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [dnsext] New Version Notification for draft-levine-dnsextlang-05.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 03:59:38 -0000 This version has a significant change suggested by Paul Vixie. Rather than storing the format information about new RR types in a local file, this now makes the primary place a known subtree of the DNS itself, which should make it possible for software to automagically update itself as new RRs are added. Take a look, let me know what you think. (Preferably in that order.) Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. ---------- Forwarded message ---------- A new version of I-D, draft-levine-dnsextlang-05.txt has been successfully submitted by John Levine and posted to the IETF repository. Filename: draft-levine-dnsextlang Revision: 05 Title: An Extension Language for the DNS Creation date: 2012-12-18 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-levine-dnsextlang-05.txt Status: http://datatracker.ietf.org/doc/draft-levine-dnsextlang Htmlized: http://tools.ietf.org/html/draft-levine-dnsextlang-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-levine-dnsextlang-05 Abstract: Adding new RRTYPEs to the DNS requires that DNS servers and provisioning software be upgraded to support each new RRTYPE in Master files. This document defines a DNS extension language intended to allow most new RRTYPEs to be supported by adding entries to configuration data read by the DNS software, with no software changes needed for each RRTYPE. From alex@alex.org.uk Wed Dec 19 01:16:13 2012 Return-Path: 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 4338621F8AD8 for ; Wed, 19 Dec 2012 01:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] 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 bUe8AfdIQYjG for ; Wed, 19 Dec 2012 01:16:12 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id 576C121F8A75 for ; Wed, 19 Dec 2012 01:16:04 -0800 (PST) Received: by mail.avalus.com (Postfix) with ESMTPSA id CAFD6C5617B; Wed, 19 Dec 2012 09:15:52 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alex Bligh In-Reply-To: <20121218222202.BA7BE2D30DA4@drugs.dv.isc.org> Date: Wed, 19 Dec 2012 09:15:51 +0000 Content-Transfer-Encoding: 7bit Message-Id: 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> <50D0D2A1.701@nlnetlabs.nl> <20121218222202.BA7BE2D30DA4@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1084) Cc: Edward Lewis , dnsext mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 09:16:13 -0000 On 18 Dec 2012, at 22:22, Mark Andrews wrote: > > OPTOUT and wildcards are incompatible with each other. There is no > way to prove that there wasn't a delegation that should have blocked > the wildcard. The second sentence is correct, but that doesn't imply the first. It just means with a wildcard under opt-out there is no way to prove a wildcard should not have been blocked by a non-wildcard RR. That's a calculated risk, like the calculated risk you take with OPTOUT in general. If your zone looks like $origin example.com *.bar IN MX test1.example2.com. foo.bar IN MX test2.example2.com. baz IN MX test3.example2.com. then as far as I can see you risk the *.bar response being incorrectly attributed to a query for foo.bar, but not to a query for baz. -- Alex Bligh From matthijs@nlnetlabs.nl Wed Dec 19 01:54:56 2012 Return-Path: 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 74CB821F8A9C for ; Wed, 19 Dec 2012 01:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_45=0.6, 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 NN+WeUmMoSqh for ; Wed, 19 Dec 2012 01:54:55 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE6D21F8A94 for ; Wed, 19 Dec 2012 01:54:54 -0800 (PST) Received: from [213.154.224.18] (zoidberg.nlnetlabs.nl [213.154.224.18]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id qBJ9sjsn025601 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 19 Dec 2012 10:54:45 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.3 open.nlnetlabs.nl qBJ9sjsn025601 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1355910887; bh=JLBD+xZ7DP1tt7NL2OuexVaya9QRnSLz146NJCNTmXA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=fcVoIraK7ZIMwsxJjyAVoEqmJBGmTY4uSSt7Dyix5Iumxf3/hjzzXcuJqXbIyIBuX nMYkJteXMgtUyM8+9ODOHIdyeyuzBLvuU9BYOHwRU4N4nt4FYsGelD+Cd9Ek0SAJUJ zrcKpuswLpOFAydklZ7skpC39y7T1r1Yy/28sJls= Message-ID: <50D18EE5.5080505@nlnetlabs.nl> Date: Wed, 19 Dec 2012 10:54:45 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mark Andrews 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> <50D0D2A1.701@nlnetlabs.nl> <20121218222202.BA7BE2D30DA4@drugs.dv.isc.org> In-Reply-To: <20121218222202.BA7BE2D30DA4@drugs.dv.isc.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7B15BC8804107196BA5B54D7" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 19 Dec 2012 10:54:46 +0100 (CET) Cc: Edward Lewis , dnsext mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 09:54:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7B15BC8804107196BA5B54D7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/18/2012 11:22 PM, Mark Andrews wrote: > In message <50D0D2A1.701@nlnetlabs.nl>, Matthijs Mekking writes: >> Hi, >> >> On 12/18/2012 05:39 PM, Edward Lewis 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. >> >> I am wondering if for QTYPE is not DS, we need another NSEC3 record, >> namely the one covering the wildcard. Example: >> >> del1.ent2.fqdn. >> >> (del1 being an unsigned delegation, ent2 an empty non-terminal) >> >> A query for should result in NODATA, but there is no= >> matching NSEC3. Do closest encloser proof with closest provable >> encloser (NSEC3 matching fqdn.) and next closer (NSEC3 covering >> ent2.fqdn.). But because there was no matching NSEC3, we still did not= >> proof if ent2.fqdn. could have been expanded from *.fqdn. Hence, we >> need the NSEC3 denying the source of synthesis. >=20 > OPTOUT and wildcards are incompatible with each other. There is no > way to prove that there wasn't a delegation that should have blocked > the wildcard. You are right, I gave it more thought. An example convinced me of the incompatibility. Let me share it with the list: There is no way to prove a wildcard should not have been blocked by a opted-out empty non-terminal: fqdn. ;apex (has matching NSEC3, cpe for ent.fqdn and ns.ent.fqdn *.fqdn. ;wildcard (has matching NSEC3) ent.fqdn. ;empty non-terminal (no matching NSEC3) ns.ent.fqdn ;unsigned delegation (no matching NSEC3) foo.fqdn. ;authoritative data (has matching NSEC3) A query for could not provide a NSEC3 covering the source of synthesis (*.fqdn.), because that name has a matching NSEC3. In other words, ent.fqdn should have been wildcard expanded. But this is wrong, because the name ent.fqdn. does exist. >>> 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=20 >>> 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=20 >>> validator MUST verify a closest provable encloser proof for the=20 >>> 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. >> >> If the NSEC3 covering the wildcard is required, then the validator of >> course needs to verify it. >> >>> There are two other blurbs to add. First is that the Empty=20 >>> 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. >> >> Technically, the proof about wildcards is not part of the closest >> encloser proof. You would need 2 NSEC3 records at most: One matching >> the closest (provable) encloser, one covering the next closer. The >> next closer covering NSEC3 has its Opt-Out bit set, saying the NSEC3 >> possibly covers insecure delegations (or in this new case: insecure >> nodata). >> >>> 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. >> >> Even though there are no implementations (known of) that do the >> mixture, I don't see why we would restrict this. Mixture is not what >> is causing this problem. >> >> Besides, if some NSEC3s can have the Opt-Out bit clear, because they >> do not cover unsigned delegations, it adds a little bit more security >> to the zone (less spans that do not assert the (non-)existence of >> insecure delegations). >=20 > In addition to not flipping optout state in a chain, no one implements > selecting which insecure delegations are to be opted out. > Implementations just uses the delegation state secure/insecure to make > the decision. But a signer implementation is able to detect whether the NSEC3 is covering unsigned delegations or not. If not, it could set the Opt-Out bit to 0 for that NSEC3. No need to select delegations to create a mixed Opt-Out on/off chain. >>> Include all Empty Non-Terminals in the NSEC3 chain. Part of this=20 >>> stems from the signer electing to NSEC3 a name based on something >>> the client cannot verify. When I first was handed the situation, >>> it was unclear if we had a server malfunction, a signer >>> malfunction, or both, because it was not clear that the data in >>> question was an Empty Non-Terminal over opted-out delegations. >>> Lacking the ability to zone walk (which is the goal of NSEC3), we >>> could not verify this until we got a look at the zone's contents. >> >> We played with that thought, because that would make validators happy >> right now: Just add the NSEC3 at the empty non-terminal and the >> validator can verify the NODATA with a single NSEC3. I honestly think >> that is a good alternative. It might be problematic for zones with a >> lot of structure, like reverse zones (are they even using NSEC3 >> Opt-Out?). If there would be consensus on such change, your earlier >> proposed errata is also not needed. >=20 > NSEC3 doesn't prevent zone walking in zones with a known structure. > The only way to prevent zone walking in these zones is to lie in > your negative responses. That was not my point. If signers would be adding NSEC3s on all empty non-terminals, we would also resolve the problem. Then only signer implementations need code modification, instead of server and validator implementations. >>> A zone may have multiple NSEC3PARAM records (needed for >>> transitions) and each chain is independent as far as opt-out or >>> not. Again, this is needed just for transitions as it doesn't make >>> much sense to use both opt-out and regular NSEC3. This is stated >>> for completeness. >> >> I would like to keep chains independent. >> >>> The impact of these "radical" steps is to reduce the number of >>> NSEC3 and RRSIG(NSEC3) in some negative answers. We still need >>> three in NXDOMAIN situations, so this isn't a terribly great gain >>> but for NoError, NoData cases it can help. These changes permits >>> DNSSEC code to be called RFC 5155 "fully" compliant - as no one >>> (apparently) has taken time to implement this fully. Always >>> signing Empty Non-Terminals brings more harmony with wild cards and >>> proofs involving them and by limiting the exemption to only names >>> with NS records and no DS records, that can be verified in periods >>> of troubleshooting. >> >> I think it is rather a strong statement to say that no implementation >> is fully compliant. What requirements are lacking in nowadays >> implementations? >> >> I do agree that there is a flaw in RFC 5155 (possible for signer to >> leave out NSEC3 on empty non-terminal to insecure delegation, but >> validator expects it when quering for that empty non-terminal). I >> would advise to fix that problem, but not take it as an opportunity to= >> make more radical changes*. >> >> Best regards, >> Matthijs >> >> >> *If we do, I know of a whole bunch of other stuff we could do to >> reduce the number of NSEC3s needed in responses. >> >> >>> Comments on list are desired. Conversation on this is desired. >>> This is presented as a two way choice, but these are not the only >>> two choices available. >>> >>> >>> >>> >>> _______________________________________________ dnsext mailing list >>> dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext >>> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with undefined - http://www.enigmail.net/ >> >> iQEcBAEBAgAGBQJQ0NKgAAoJEA8yVCPsQCW5SFMH/3D8UC5TwVRDVV/+jB0L7qN8 >> qRSGiqNUR84Woy7pO/1rrUnJpb6DQjkmry2Y9kCW1Qw7e660lrP4cQM7YC11bEYR >> j+zDad2Nl58mUNmr8sN8vx6KERHPK2eEzonv+n1K1Cn2FdCEwjv8agMP81k8Y+bq >> io3Z7BdkXIB7OWqjWnmAVwBe6t/0hO/mKSBTramXFm82Kp29dkkjt3NFrxMo67cN >> VV9srM/AwAKR+v1CnLTNx3+ktsQRGjKq6AZw5sW3yR765fEQN5R5/Cc/zqJ3uTC4 >> WV+Z47HaCW8Wzx8FwZSuIgKJmLI9Dntbw5FEE7hwXLA19vLJ8KMeQ8LU2VI145o=3D >> =3DJYV3 >> -----END PGP SIGNATURE----- >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext --------------enig7B15BC8804107196BA5B54D7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ0Y7qAAoJEA8yVCPsQCW56ygIANnu0r+PcKJ4WoGhP5gBWiGg Jp905N7kHkNhs0f7Chh8d1Y8dTpKMtxRcCR5P+omCWjMWv5IV7SN1OmyrOts+WQn DKn+dnznCY8b98AY84hdMSYO9mBkgDdPaFkj1GNdLMOkukBHxj8nqgS0UusxrSPn j7eo6mGzE9jjkz/tscWz39GSjuk0MS0hjXKSWnDR+l80MGoHq+Kw0gxwBzD1xvW4 ugXkJ8PC0rUFLmrykkY/0+ReoWnxZVvTGj+lVQfuSxh4+Mdj3nmc8Jb2QTZKXu2O E3RKr+Z8QJbrGC7YUs9gHKgI306TB0wzRyJ7DZcK/A4AQ/8spZyVTm+GN1NQ0LQ= =zGVU -----END PGP SIGNATURE----- --------------enig7B15BC8804107196BA5B54D7-- From ed.lewis@neustar.biz Wed Dec 19 06:48:34 2012 Return-Path: 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 55F5521F84FB for ; Wed, 19 Dec 2012 06:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.581 X-Spam-Level: X-Spam-Status: No, score=-101.581 tagged_above=-999 required=5 tests=[AWL=1.018, BAYES_00=-2.599, 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 r+vUIsbOvNa8 for ; Wed, 19 Dec 2012 06:48:33 -0800 (PST) Received: from eastrmfepo202.cox.net (eastrmfepo202.cox.net [68.230.241.217]) by ietfa.amsl.com (Postfix) with ESMTP id B518A21F84C1 for ; Wed, 19 Dec 2012 06:48:33 -0800 (PST) Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo202.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121219144833.NSOW6475.eastrmfepo202.cox.net@eastrmimpo210> for ; Wed, 19 Dec 2012 09:48:33 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo210 with cox id dSoY1k00W3cuADQ01SoYjN; Wed, 19 Dec 2012 09:48:33 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020204.50D1D3C1.0061,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=R/2B6KtX c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=3AUgi09Yx-sA:10 a=kj9zAlcOel0A:10 a=hGBaWAWWAAAA:8 a=W5eCSmW0TOMA:10 a=TneC9dG3Nbe76KVbL_AA:9 a=CjuIK1q_8ugA:10 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Edward Lewis In-Reply-To: <95C76953-2D89-4EBC-86D7-BDBBE0379041@neustar.biz> Date: Wed, 19 Dec 2012 09:48:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> 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> To: dnsext mailing list X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:48:34 -0000 First, thanks to those who posted to the list, I don't want to stem the = tide now. Keep thoughts coming. But two things popped up in the responses so far that I can provide some = clarifying comments on: One, about "compliance" - yes, I was saying that no implementations = were fully because they didn't allow pick-and-choose opt-out. But the = comment id driven by some other thoughts. The IETF claims "running code = and rough consensus" but the running code today differs from the spec. = And as an operator I hear "the IETF wants operators to come in and help" = but my observation is that when a protocol seems confusing and resulting = in higher support costs, the spec still holds sway. I was hoping that = there'd be willingness to bring the spec into the reality space and not = remain in the conceptual space. Two, about the need or not for the wildcard NSEC3 in the proofs - that = idea came from an off-list conversation with someone who derived the = NSEC3 idea and document. Unfortunately, that was private communication = and not on the list, so I have to shuttle back and forth the ideas. = (This is why I want the discussion to remain on the open, transparent = list.) I'll wait for a few more comments before updating what I am thinking. = I want to encourage folks to pitch in as this is a working group effort. = It's not about anyone's individual perspectives or opinions.= From miekg@atoom.net Thu Dec 20 02:45:45 2012 Return-Path: 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 6FAF921F8797 for ; Thu, 20 Dec 2012 02:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 G1Yo-i3DhwC9 for ; Thu, 20 Dec 2012 02:45:41 -0800 (PST) Received: from elektron.atoom.net (elektron.atoom.net [IPv6:2001:7b8:32a::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8F121F87A3 for ; Thu, 20 Dec 2012 02:45:41 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id 07B253FFFF; Thu, 20 Dec 2012 11:45:39 +0100 (CET) Date: Thu, 20 Dec 2012 11:45:39 +0100 From: Miek Gieben To: Edward Lewis Message-ID: <20121220104539.GA929@miek.nl> Mail-Followup-To: Edward Lewis , dnsext mailing list 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Cc: dnsext mailing list Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 10:45:45 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "[dnsext] Clarifying a few points in...= " ] > First, thanks to those who posted to the list, I don't want to stem the t= ide now. Keep thoughts coming. I agree with Mark that "OPTOUT and wildcards are incompatible with each oth= er". Also Matthijs and I are working on getting http://tools.ietf.org/html/draft-gieben-auth-denial-of-existence-dns-01 through the ISE stream. A reviewer asked if would could add text about opt-= opt (right now, we say nothing about it). But of course that work does not exclude the need to file an errata against 5155. Regards, --=20 Miek Gieben http://miek.nl --FCuugMFkClbJLl1L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlDS7FMACgkQJYuFzziA0PZa5wCePWt5qUUIiNFqPXG+L6kfxtys Cy4AoMb9CeYA7cW9apmv2dHLiMd8IX27 =KYs8 -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From davidb@verisign.com Thu Dec 20 06:05:44 2012 Return-Path: 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 691CF21F88E1 for ; Thu, 20 Dec 2012 06:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, 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 Brbef8lEbIgk for ; Thu, 20 Dec 2012 06:05:44 -0800 (PST) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id B104321F8626 for ; Thu, 20 Dec 2012 06:05:40 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUNMbNMxmpMKm56rCyH5oswqRidJeg4u9@postini.com; Thu, 20 Dec 2012 06:05:43 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qBKE5Zfh030313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Dec 2012 09:05:35 -0500 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 09:05:35 -0500 From: "Blacka, David" To: Miek Gieben Thread-Topic: [dnsext] Clarifying a few points in Re: Update to RFC 5155. Maybe? Thread-Index: AQHN3ffyYdwgNDfw0UGE4hpcqv0FM5gh1i6AgAA32wA= Date: Thu, 20 Dec 2012 14:05:34 +0000 Message-ID: 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> In-Reply-To: <20121220104539.GA929@miek.nl> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Edward Lewis , dnsext mailing list Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 14:05:44 -0000 On Dec 20, 2012, at 5:45 AM, Miek Gieben wrote: > [ Quoting in "[dnsext] Clarifying a few points in.= .." ] >> First, thanks to those who posted to the list, I don't want to stem the = tide now. Keep thoughts coming. >=20 > I agree with Mark that "OPTOUT and wildcards are incompatible with each o= ther". "incompatible" suggests to most people that using wildcards and NSEC3 Opt-O= ut causes something to break, which isn't true at all. Instead, you just don't have the same security guarantees for wildcards tha= t you do when not using Opt-Out, which is the basic tradeoff with Opt-Out. -- David Blacka =20 Principal Verisign Infrastructure Engineering From fanf2@hermes.cam.ac.uk Thu Dec 20 06:55:17 2012 Return-Path: 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 75C4D21F88DD for ; Thu, 20 Dec 2012 06:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.59 X-Spam-Level: X-Spam-Status: No, score=-5.59 tagged_above=-999 required=5 tests=[AWL=1.009, BAYES_00=-2.599, 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 X+sPB2T8XOIs for ; Thu, 20 Dec 2012 06:55:12 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 251A121F88F5 for ; Thu, 20 Dec 2012 06:55:11 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42007) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1TlhWY-0003Fd-WM (Exim 4.72) (return-path ); Thu, 20 Dec 2012 14:55:02 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TlhWX-0008KT-VI (Exim 4.72) (return-path ); Thu, 20 Dec 2012 14:55:01 +0000 Date: Thu, 20 Dec 2012 14:55:01 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: "Blacka, David" In-Reply-To: Message-ID: 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Edward Lewis , dnsext mailing list Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 14:55:17 -0000 Blacka, David wrote: > > "incompatible" suggests to most people that using wildcards and NSEC3 > Opt-Out causes something to break, which isn't true at all. > > Instead, you just don't have the same security guarantees for wildcards > that you do when not using Opt-Out, which is the basic tradeoff with > Opt-Out. I understood the incompatibility to be that you can't have opt-out delegations under a wildcard: they have to have a full complement of NSEC3 records. And if they have all their NSEC3 records then there is no loss of security relative to other insecure delegations when there is no wildcard interfering. And there can still be opt-out delegations in other parts of the zone that do not have wildcards. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From davidb@verisign.com Thu Dec 20 14:17:03 2012 Return-Path: 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 7DF0821F8A77 for ; Thu, 20 Dec 2012 14:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 70z66Yr8Vmd9 for ; Thu, 20 Dec 2012 14:17:02 -0800 (PST) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id F3E9221F8A76 for ; Thu, 20 Dec 2012 14:16:58 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKUNOOWv58c3Wczw9MCCw1J295Ot9+zAdE@postini.com; Thu, 20 Dec 2012 14:17:02 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qBKMGqf3013199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Dec 2012 17:16:52 -0500 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 17:16:52 -0500 From: "Blacka, David" To: Tony Finch Thread-Topic: [dnsext] Clarifying a few points in Re: Update to RFC 5155. Maybe? Thread-Index: AQHN3ffyYdwgNDfw0UGE4hpcqv0FM5gh1i6AgAA32wCAAA3RgIAAe3EA Date: Thu, 20 Dec 2012 22:16:51 +0000 Message-ID: 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> In-Reply-To: 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: <4AD8250191E05745B379221B6D03B756@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Edward Lewis , dnsext mailing list Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 22:17:03 -0000 On Dec 20, 2012, at 9:55 AM, Tony Finch wrote: > Blacka, David wrote: >>=20 >> "incompatible" suggests to most people that using wildcards and NSEC3 >> Opt-Out causes something to break, which isn't true at all. >>=20 >> Instead, you just don't have the same security guarantees for wildcards >> that you do when not using Opt-Out, which is the basic tradeoff with >> Opt-Out. >=20 > I understood the incompatibility to be that you can't have opt-out > delegations under a wildcard: they have to have a full complement of NSEC= 3 > records. And if they have all their NSEC3 records then there is no loss o= f > security relative to other insecure delegations when there is no wildcard > interfering. And there can still be opt-out delegations in other parts of > the zone that do not have wildcards. This is why using the word "incompatible" is wrong. You can put delegations (insecure and otherwise) and wildcards anywhere you= want in a zone signed with NSEC3 Opt-Out, just like any other zone. You j= ust don't get the same security guarantees (meaning, an attacker could spoo= f a wildcard response into a NOERROR/NODATA or some other delegation.) -- David Blacka =20 Principal Verisign Infrastructure Engineering From fanf2@hermes.cam.ac.uk Thu Dec 20 18:17:58 2012 Return-Path: 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 816CE21E802E for ; Thu, 20 Dec 2012 18:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 hvIkyMoOiA2F for ; Thu, 20 Dec 2012 18:17:57 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6E44F21F8996 for ; Thu, 20 Dec 2012 18:17:57 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from host86-171-50-37.range86-171.btcentralplus.com ([86.171.50.37]:62298 helo=[192.168.1.66]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1TlsBP-0005cT-Yf (Exim 4.72) (return-path ); Fri, 21 Dec 2012 02:17:55 +0000 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> X-Mailer: iPhone Mail (9B206) From: Tony Finch Date: Fri, 21 Dec 2012 02:17:51 +0000 To: "Blacka, David" Sender: Tony Finch Cc: Edward Lewis , dnsextmailing list Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 02:17:58 -0000 On 20 Dec 2012, at 22:16, "Blacka, David" wrote: >=20 > On Dec 20, 2012, at 9:55 AM, Tony Finch wrote: >=20 >> Blacka, David wrote: >>>=20 >>> "incompatible" suggests to most people that using wildcards and NSEC3 >>> Opt-Out causes something to break, which isn't true at all. >>>=20 >>> Instead, you just don't have the same security guarantees for wildcards >>> that you do when not using Opt-Out, which is the basic tradeoff with >>> Opt-Out. >>=20 >> I understood the incompatibility to be that you can't have opt-out >> delegations under a wildcard: they have to have a full complement of NSEC= 3 >> records. And if they have all their NSEC3 records then there is no loss o= f >> security relative to other insecure delegations when there is no wildcard= >> interfering. And there can still be opt-out delegations in other parts of= >> the zone that do not have wildcards. >=20 > This is why using the word "incompatible" is wrong. >=20 > You can put delegations (insecure and otherwise) and wildcards anywhere yo= u want in a zone signed with NSEC3 Opt-Out, just like any other zone. You j= ust don't get the same security guarantees (meaning, an attacker could spoof= a wildcard response into a NOERROR/NODATA or some other delegation.) If that is the case surely it is a serious bug. A resolver must be able to p= rove there is nothing but insecure delegations in an opt-out range, includin= g no wildcards. Tony. -- f.anthony.n.finch http://dotat.at/= From yaojk@cnnic.cn Thu Dec 20 22:32:14 2012 Return-Path: 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 1D8A821F8A9A for ; Thu, 20 Dec 2012 22:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.616 X-Spam-Level: X-Spam-Status: No, score=-98.616 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, MIME_BASE64_TEXT=1.753, 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 J+T8IcxFjVHY for ; Thu, 20 Dec 2012 22:32:13 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 3F21921F8A95 for ; Thu, 20 Dec 2012 22:32:11 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 21 Dec 2012 14:32:09 +0800 Message-ID: <3FF91D04B500497C84CF362E3967FE40@LENOVO47E041CF> From: "Jiankang YAO" To: "Edward Lewis" , "dnsext mailing list" 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> Date: Fri, 21 Dec 2012 14:32:15 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 06:32:14 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVkd2FyZCBMZXdpcyIgPGVk Lmxld2lzQG5ldXN0YXIuYml6Pg0KVG86ICJkbnNleHQgbWFpbGluZyBsaXN0IiA8ZG5zZXh0QGll dGYub3JnPg0KQ2M6ICJFZHdhcmQgTGV3aXMiIDxFZC5MZXdpc0BuZXVzdGFyLmJpej4NClNlbnQ6 IFdlZG5lc2RheSwgRGVjZW1iZXIgMTksIDIwMTIgMTA6NDggUE0NClN1YmplY3Q6IFtkbnNleHRd IENsYXJpZnlpbmcgYSBmZXcgcG9pbnRzIGluIFJlOiBVcGRhdGUgdG8gUkZDIDUxNTUuIE1heWJl Pw0KDQoNCj4gDQo+IEknbGwgd2FpdCBmb3IgYSBmZXcgbW9yZSBjb21tZW50cyBiZWZvcmUgdXBk YXRpbmcgd2hhdCBJIGFtIHRoaW5raW5nLiAgIEkgd2FudCB0byBlbmNvdXJhZ2UgZm9sa3MgdG8g cGl0Y2ggaW4gYXMgdGhpcyA+aXMgYSB3b3JraW5nIGdyb3VwIGVmZm9ydC4gIEl0J3Mgbm90IGFi b3V0IGFueW9uZSdzIGluZGl2aWR1YWwgcGVyc3BlY3RpdmVzIG9yIG9waW5pb25zLg0KPiANCj4N Cg0Kd2hpY2ggd29ya2luZyBncm91cCB5b3Ugd2lsbCBwaXRjaCBpbiBzaW5jZSB0aGUgZG5zZXh0 IHdpbGwgc29vbiBjbG9zZSBkb3duPw0KDQpJdCBzZWVtcyB0aGF0IHdlIG5lZWQgdG8gZmluZCBh IHdnIG9yIGNyZWF0IGEgbmV3IHdnIHRvIGRpc2N1c3MgdGhlIGRuc2V4dCByZWxhdGVkIHRoaW5n cy4NCg0KYW55IGlkZWE/DQoNCkppYW5rYW5nIFlhbw0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRuc2V4dCBtYWlsaW5nIGxpc3QNCj4gZG5z ZXh0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5z ZXh0 From miekg@atoom.net Thu Dec 20 23:32:12 2012 Return-Path: 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 A8E2B21F857A for ; Thu, 20 Dec 2012 23:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 ilnogyrPKX7Q for ; Thu, 20 Dec 2012 23:32:05 -0800 (PST) Received: from elektron.atoom.net (elektron.atoom.net [IPv6:2001:7b8:32a::2]) by ietfa.amsl.com (Postfix) with ESMTP id A4CC921F8456 for ; Thu, 20 Dec 2012 23:32:05 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id 1DE823FFFB; Fri, 21 Dec 2012 08:32:04 +0100 (CET) Date: Fri, 21 Dec 2012 08:32:04 +0100 From: Miek Gieben To: dnsextmailing list Message-ID: <20121221073203.GA6444@miek.nl> Mail-Followup-To: dnsextmailing list References: <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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 07:32:12 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "Re: [dnsext] Clarifying a few point..." ] > > This is why using the word "incompatible" is wrong. > >=20 > > You can put delegations (insecure and otherwise) and wildcards anywhere > > you want in a zone signed with NSEC3 Opt-Out, just like any other zone.= You > > just don't get the same security guarantees (meaning, an attacker could= spoof a > > wildcard response into a NOERROR/NODATA or some other delegation.) > > If that is the case surely it is a serious bug. A resolver must be able to > prove there is nothing but insecure delegations in an opt-out range, incl= uding > no wildcards. Why do you call this a bug? By allowing Opt-Out you forgo the security in t= hat range... Or do you call the Opt-Out feature in itself a bug? Regards, --=20 Miek Gieben http://miek.nl --jRHKVT23PllUwdXP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlDUEHMACgkQJYuFzziA0PY1KwCaAmAuKWK0I6LWrwdxe+swo8T+ r0cAnjbUpxR8mdLtLLV8T1A9mY+IxBre =e7jm -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From matthijs@nlnetlabs.nl Thu Dec 20 23:41:07 2012 Return-Path: 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 177E421F84C1 for ; Thu, 20 Dec 2012 23:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 LugmyuH4pAwL for ; Thu, 20 Dec 2012 23:41:05 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB59C21F8449 for ; Thu, 20 Dec 2012 23:41:03 -0800 (PST) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id qBL7eqRx077158 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 21 Dec 2012 08:40:53 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.3 open.nlnetlabs.nl qBL7eqRx077158 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1356075655; bh=eAGmM84j5G83hObeiIjDXQYK/8QhlT8DEgoaoqW5i/c=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=LvW3rzGtq2evAEAbGQ2li07l1eRjbh9Tx5ZpXDpfMWAM6Pjc6NI4Vpt3N+Ugz4r/c QAHSsyA2saqWf7Wn3Jpud+H8R6WjqZ4LyhSfyvOBx5MTcDgcAhmYhJPRRpvi6FmhAI 8noneXDCMyn3DslwoBUO3DvIm1r5PHhunvj75cSA= Message-ID: <50D41289.80903@nlnetlabs.nl> Date: Fri, 21 Dec 2012 08:40:57 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tony Finch 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> In-Reply-To: <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Fri, 21 Dec 2012 08:40:54 +0100 (CET) Cc: Edward Lewis , dnsextmailing list Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 07:41:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony, On 12/21/2012 03:17 AM, Tony Finch wrote: > On 20 Dec 2012, at 22:16, "Blacka, David" > wrote: > >> >> On Dec 20, 2012, at 9:55 AM, Tony Finch wrote: >> >>> Blacka, David wrote: >>>> >>>> "incompatible" suggests to most people that using wildcards >>>> and NSEC3 Opt-Out causes something to break, which isn't true >>>> at all. >>>> >>>> Instead, you just don't have the same security guarantees for >>>> wildcards that you do when not using Opt-Out, which is the >>>> basic tradeoff with Opt-Out. >>> >>> I understood the incompatibility to be that you can't have >>> opt-out delegations under a wildcard: they have to have a full >>> complement of NSEC3 records. And if they have all their NSEC3 >>> records then there is no loss of security relative to other >>> insecure delegations when there is no wildcard interfering. And >>> there can still be opt-out delegations in other parts of the >>> zone that do not have wildcards. >> >> This is why using the word "incompatible" is wrong. >> >> You can put delegations (insecure and otherwise) and wildcards >> anywhere you want in a zone signed with NSEC3 Opt-Out, just like >> any other zone. You just don't get the same security guarantees >> (meaning, an attacker could spoof a wildcard response into a >> NOERROR/NODATA or some other delegation.) > > If that is the case surely it is a serious bug. A resolver must be > able to prove there is nothing but insecure delegations in an > opt-out range, including no wildcards. Putting insecure delegations and wildcards in a *zone* with NSEC3 Opt-out (what David is saying) is something different than a Opt-Out NSEC3 that covers insecure delegations and wildcards (what you are saying). A zone with a wildcard configured somewhere, and with insecure delegations (possibly a few labels deep, so there are some empty non-terminals) is vulnerable to attacks where the insecure delegation or one of the derived empty non-terminals is expanded to the wildcard. Best regards, Matthijs > > Tony. -- f.anthony.n.finch http://dotat.at/ > _______________________________________________ dnsext mailing > list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ1BKFAAoJEA8yVCPsQCW59yMH/2ArpvF+GVsbx4QooQYy/y9+ CIVkNaPm1Na9AgK/JsCZDeoVqaXqhFwfpAzmbOZxnAIVogoc8VB0OKCZezIp8mfl VYYxys2ldP5vTqfx+ki5VRj0nXasbrtPwb3FBlsL+j2p2Eb8vGeo4E1DDrCu8k2Q a8ieiabYO70SN2GLlvDRWBxvE2Em9edNBQ0msg/2hMCYYSoox5ZbWOGIydKkl9Vr t6qOPTeVe3kw5GR99kFR4FwTvkKfROq3SXvZ9UCKNJQfX36CoE8H9hEdpPcq8gIy vs2/8uN37dxHar21fpIZ7392DbaaB+ws2mh7Fl5YKVeDpByPfn0WUYP9qS1CJY0= =d2bS -----END PGP SIGNATURE----- From fanf2@hermes.cam.ac.uk Fri Dec 21 06:51:01 2012 Return-Path: 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 89C8021F8614 for ; Fri, 21 Dec 2012 06:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[AWL=0.841, BAYES_00=-2.599, 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 tLqbRze8psIu for ; Fri, 21 Dec 2012 06:51:00 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8B05D21F85DF for ; Fri, 21 Dec 2012 06:51:00 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:50006) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Tm3w5-0006CV-Wb (Exim 4.72) (return-path ); Fri, 21 Dec 2012 14:50:53 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Tm3w5-0002jP-2o (Exim 4.72) (return-path ); Fri, 21 Dec 2012 14:50:53 +0000 Date: Fri, 21 Dec 2012 14:50:53 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Matthijs Mekking In-Reply-To: <50D41289.80903@nlnetlabs.nl> Message-ID: 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> <50D41289.80903@nlnetlabs.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Edward Lewis , dnsextmailing list Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 14:51:01 -0000 Matthijs Mekking wrote: > > A zone with a wildcard configured somewhere, and with insecure > delegations (possibly a few labels deep, so there are some empty > non-terminals) is vulnerable to attacks where the insecure delegation > or one of the derived empty non-terminals is expanded to the wildcard. I'm confused. Can you explain this in more detail? I don't understand what additional security problem is caused by wildcards. Can't you just avoid the problem by not having opt-out NSEC3 records for the part of the zone affected by the wildcard? I understand that an attacker can spoof insecure delegations within an opt-out range. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From matthijs@nlnetlabs.nl Fri Dec 21 07:55:57 2012 Return-Path: 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 137A821F8749 for ; Fri, 21 Dec 2012 07:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 bFjm091KXhaF for ; Fri, 21 Dec 2012 07:55:49 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABCB21F86C3 for ; Fri, 21 Dec 2012 07:55:49 -0800 (PST) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id qBLFtcWm021959 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 21 Dec 2012 16:55:39 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.3 open.nlnetlabs.nl qBLFtcWm021959 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1356105340; bh=JUnB7qwlMlTrWbOwqvSKlNZkrMW8Pz+bhtCupz5C1Lg=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=ldMwVSSXmkLLsMXHPMj8d1bxwO3R6BzQfXNJVRC33As+fnAT3AMRiW0FFUcYxJdwL gYJz6lzdQy/evVoD1sk9EHtY8O0DKs7x7oxmjjC0vU3Rd1uod787w3oNHD3UTLeHp3 RQ+DnQvrGLrkcwVc5EgQb79hA17FusCCECTnaIiM= Message-ID: <50D48680.7080806@nlnetlabs.nl> Date: Fri, 21 Dec 2012 16:55:44 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tony Finch 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> <50D41289.80903@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Fri, 21 Dec 2012 16:55:40 +0100 (CET) Cc: Edward Lewis , dnsextmailing list Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 15:55:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/21/2012 03:50 PM, Tony Finch wrote: > Matthijs Mekking wrote: >> >> A zone with a wildcard configured somewhere, and with insecure >> delegations (possibly a few labels deep, so there are some empty >> non-terminals) is vulnerable to attacks where the insecure >> delegation or one of the derived empty non-terminals is expanded >> to the wildcard. > > I'm confused. Can you explain this in more detail? Let's try with an example. fqdn. IN SOA and stuff. *.fqdn. IN A 1.3.3.7 ns.ent.fqdn. IN NS somewhere. A query for can now be answered with ;; ANSWER SECTION ent.fqdn. IN A 1.3.3.7 (expanded from the wildcard) ;; AUTHORITY SECTION h(x).fqdn. IN NSEC3 ... (covering ent.fqdn.) h(x).fqdn. has its opt-out bit set, so the validator cannot assert or deny the existence of ent.fqdn. This is what I think David means with "wildcard response spoofed into a NOERROR/NODATA or some other delegation. > > I don't understand what additional security problem is caused by > wildcards. Can't you just avoid the problem by not having opt-out > NSEC3 records for the part of the zone affected by the wildcard? The part of the zone affected is the opt-out range. > I understand that an attacker can spoof insecure delegations within > an opt-out range. And it can spoof other stuff in the opt-out range. > > Tony. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ1IaAAAoJEA8yVCPsQCW5AdMH/RS8c5GZx7LLW9ccw2lGVsIn bAY1OGFIBmOZbcsORe6e/RdqgmAji3UyVyh7ADjE+xGZC5uawaqsjpxxfXwFbX7h lBjDf7NBPhZrzbeWtV8xEpke+cUYY7K+2qsOaEhfJvPaeBVn4C4xtLWAMGD8xv0q iEEgPjlESoDRSMJEoXp4czMqQdS/AuowuyCVc21I03/gDkMDTV31123ZlgQ1ph5M UdcF/0C++0tSmwVnoFMcFkHIu769s0L+EnoVReR/WCfemzQXCHyt+g4OdtrM56WN 8Pl95eyXQnQ4UpfaZ8Sn+dX68QQ4Q6UTmft/lIOevQN4wsiadot5PffaXjq3AyU= =1LMf -----END PGP SIGNATURE----- From fanf2@hermes.cam.ac.uk Fri Dec 21 08:04:37 2012 Return-Path: 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 BDE2E21F8767 for ; Fri, 21 Dec 2012 08:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.578 X-Spam-Level: X-Spam-Status: No, score=-5.578 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, J_CHICKENPOX_34=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 XccR-ISSb8HZ for ; Fri, 21 Dec 2012 08:04:36 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 824EC21F8778 for ; Fri, 21 Dec 2012 08:04:35 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59777) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Tm55K-0006Cf-Yw (Exim 4.72) (return-path ); Fri, 21 Dec 2012 16:04:30 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Tm55K-0001hf-QC (Exim 4.72) (return-path ); Fri, 21 Dec 2012 16:04:30 +0000 Date: Fri, 21 Dec 2012 16:04:30 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Matthijs Mekking In-Reply-To: <50D48680.7080806@nlnetlabs.nl> Message-ID: 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> <50D41289.80903@nlnetlabs.nl> <50D48680.7080806@nlnetlabs.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Edward Lewis , dnsextmailing list Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 16:04:37 -0000 Matthijs Mekking wrote: > > Let's try with an example. > > fqdn. IN SOA and stuff. > *.fqdn. IN A 1.3.3.7 > ns.ent.fqdn. IN NS somewhere. > > A query for can now be answered with > > ;; ANSWER SECTION > ent.fqdn. IN A 1.3.3.7 (expanded from the wildcard) > > ;; AUTHORITY SECTION > h(x).fqdn. IN NSEC3 ... (covering ent.fqdn.) > > h(x).fqdn. has its opt-out bit set, so the validator cannot assert or > deny the existence of ent.fqdn. This is what I think David means with > "wildcard response spoofed into a NOERROR/NODATA or some other delegation. My understanding is that would be a bug in your signer. You can't have opt-out NSEC3 records covering the part of a zone under a wildcard, which is what was meant by "incompatible". Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From matthijs@nlnetlabs.nl Fri Dec 21 08:52:49 2012 Return-Path: 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 E3F2421F892F for ; Fri, 21 Dec 2012 08:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.074 X-Spam-Level: X-Spam-Status: No, score=-102.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 2Grlc5k4RH4d for ; Fri, 21 Dec 2012 08:52:47 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9483A21F88C9 for ; Fri, 21 Dec 2012 08:52:45 -0800 (PST) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id qBLGqUkw026871 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 21 Dec 2012 17:52:30 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.3 open.nlnetlabs.nl qBLGqUkw026871 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1356108753; bh=LoXw953SK2vVkwr/XoxOM0fPW1Be9ITRBUfjZq3esdU=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=jrOR7CIfwW/UaNbbWjTb0Z3qIM+a2TaZAQtztMrviOtS4dK0sXw21fLD5pEfbdLvp 4VMpi86PlQI2KBotbnJatIxs1B6kJYw38iRb9ed63lO593iHVhnpzgrjPtYcy5n3vb IY86G5F4WHB5At4imB55NT0yiA1//wESV3iRMSk8= Message-ID: <50D493D3.3060007@nlnetlabs.nl> Date: Fri, 21 Dec 2012 17:52:35 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tony Finch 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> <50D41289.80903@nlnetlabs.nl> <50D48680.7080806@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Fri, 21 Dec 2012 17:52:31 +0100 (CET) Cc: Edward Lewis , dnsextmailing list Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 16:52:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/21/2012 05:04 PM, Tony Finch wrote: > Matthijs Mekking wrote: >> >> Let's try with an example. >> >> fqdn. IN SOA and stuff. *.fqdn. IN A 1.3.3.7 >> ns.ent.fqdn. IN NS somewhere. >> >> A query for can now be answered with >> >> ;; ANSWER SECTION ent.fqdn. IN A 1.3.3.7 (expanded from the >> wildcard) >> >> ;; AUTHORITY SECTION h(x).fqdn. IN NSEC3 ... (covering >> ent.fqdn.) >> >> h(x).fqdn. has its opt-out bit set, so the validator cannot >> assert or deny the existence of ent.fqdn. This is what I think >> David means with "wildcard response spoofed into a NOERROR/NODATA >> or some other delegation. > > My understanding is that would be a bug in your signer. You can't > have opt-out NSEC3 records covering the part of a zone under a > wildcard, which is what was meant by "incompatible". In this example, the wildcard is not covered by the opt-out NSEC3 record. The 'blocking' name is, because that is derived from an insecure delegation. Matthijs > > Tony. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ1JPTAAoJEA8yVCPsQCW5CWEH/3RLKffWSdo7bZDsF4wDCcdb Nj4qN/QTTz0yo9R7tc1pbRW7wVJIkDMGYlhYfzkXHeY5ncpWis7GxRApvyAJt/tQ AunUD1et6W/Um03pf5MOE3xY+VYgwo7JGRbK1UtJvNjWEEE0CvB/8YdpqYprIbxM DCsT/qkbwowxzy7f37H2nu5Tt7S5yt0RMSkl7z5pWIX5C7CbmmghvnLrsWuZ57F2 9TQsj2BZPoZoHyKtsSXbrTGTb/PvISCYHV5P+/I6Tjy+pztuDd4Gok0gWxhtZCnI oJ2EIBJkrQ9nM2Sw0bO0xS1oCVVeF2LmNSAqR1HzMHBhSBlrRnKl+15X4EZzamQ= =aPtY -----END PGP SIGNATURE----- From fanf2@hermes.cam.ac.uk Fri Dec 21 09:22:49 2012 Return-Path: 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 2FFC821F8A05 for ; Fri, 21 Dec 2012 09:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.631 X-Spam-Level: X-Spam-Status: No, score=-5.631 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, J_CHICKENPOX_34=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 7EYUmLFrlhAg for ; Fri, 21 Dec 2012 09:22:48 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 290A221F8AE1 for ; Fri, 21 Dec 2012 09:22:46 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:41463) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Tm6J0-0006LI-Wq (Exim 4.72) (return-path ); Fri, 21 Dec 2012 17:22:42 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Tm6J0-0000fT-5J (Exim 4.72) (return-path ); Fri, 21 Dec 2012 17:22:42 +0000 Date: Fri, 21 Dec 2012 17:22:42 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Matthijs Mekking In-Reply-To: <50D493D3.3060007@nlnetlabs.nl> Message-ID: 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> <50D41289.80903@nlnetlabs.nl> <50D48680.7080806@nlnetlabs.nl> <50D493D3.3060007@nlnetlabs.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Edward Lewis , dnsextmailing list Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 17:22:49 -0000 Matthijs Mekking wrote: > On 12/21/2012 05:04 PM, Tony Finch wrote: > > Matthijs Mekking wrote: > >> > >> Let's try with an example. > >> > >> fqdn. IN SOA and stuff. > >> *.fqdn. IN A 1.3.3.7 > >> ns.ent.fqdn. IN NS somewhere. > >> > >> A query for can now be answered with > >> > >> ;; ANSWER SECTION > >> ent.fqdn. IN A 1.3.3.7 (expanded from the wildcard) > >> ;; AUTHORITY SECTION > >> h(x).fqdn. IN NSEC3 ... (covering ent.fqdn.) > >> > >> h(x).fqdn. has its opt-out bit set, so the validator cannot > >> assert or deny the existence of ent.fqdn. This is what I think > >> David means with "wildcard response spoofed into a NOERROR/NODATA > >> or some other delegation. > > > > My understanding is that would be a bug in your signer. You can't > > have opt-out NSEC3 records covering the part of a zone under a > > wildcard, which is what was meant by "incompatible". > > In this example, the wildcard is not covered by the opt-out NSEC3 > record. The 'blocking' name is, because that is derived from an > insecure delegation. Yes, but the problem is that the wildcard is above the opt-out. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From suruti94@gmail.com Fri Dec 21 10:55:14 2012 Return-Path: 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 50D5F21F87D7 for ; Fri, 21 Dec 2012 10:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] 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 T81Ta-gJMMqk for ; Fri, 21 Dec 2012 10:55:13 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id E5EEC21F87D5 for ; Fri, 21 Dec 2012 10:55:12 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hn14so5340031wib.16 for ; Fri, 21 Dec 2012 10:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ESlZWiXM0h3z+nhKqiIIK23zvWb1xZPxoGH5wV2z7ec=; b=E0Ecc9wc2fx1334tvbr4wR6SVr6lJtVu4CDSv9Ei4GUGovZKjObcurMiloq+ImN/rd YuE6W9+bPB7DSO1aZ0gelg3ckyfm5/66Wz+tVLK0DvcbMt70/Fg5ETmuAU7/f089Iyjj /vRCQ672KK64CHiMYT5ksgejRZ8LUFHJ7NenYC/nTb84xBL51A3JxMdIY0zCCLIKMGpN sXj0ulOL28DodHg5yoPqahJJ6DRjXYghNZzIc7qjHVnLr1MZsGZZnEgCt9LBWmRAYcRL Q+S2zm+MQ2wcILZI/RxkSaasYyNNzkS6+f6lTyOSErtKvVXS+UazaKMYpFzK7bNQWrAN 4P0g== MIME-Version: 1.0 Received: by 10.180.93.3 with SMTP id cq3mr25014699wib.1.1356116111992; Fri, 21 Dec 2012 10:55:11 -0800 (PST) Received: by 10.194.167.9 with HTTP; Fri, 21 Dec 2012 10:55:11 -0800 (PST) In-Reply-To: <50D493D3.3060007@nlnetlabs.nl> 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> <50D41289.80903@nlnetlabs.nl> <50D48680.7080806@nlnetlabs.nl> <50D493D3.3060007@nlnetlabs.nl> Date: Fri, 21 Dec 2012 10:55:11 -0800 Message-ID: From: Mohan Parthasarathy To: Matthijs Mekking Content-Type: multipart/alternative; boundary=f46d043c805621272004d1616338 Cc: Edward Lewis , dnsextmailing list Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 18:55:14 -0000 --f46d043c805621272004d1616338 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 21, 2012 at 8:52 AM, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/21/2012 05:04 PM, Tony Finch wrote: > > Matthijs Mekking wrote: > >> > >> Let's try with an example. > >> > >> fqdn. IN SOA and stuff. *.fqdn. IN A 1.3.3.7 > >> ns.ent.fqdn. IN NS somewhere. > >> > >> A query for can now be answered with > >> > >> ;; ANSWER SECTION ent.fqdn. IN A 1.3.3.7 (expanded from the > >> wildcard) > >> > >> ;; AUTHORITY SECTION h(x).fqdn. IN NSEC3 ... (covering > >> ent.fqdn.) > >> > >> h(x).fqdn. has its opt-out bit set, so the validator cannot > >> assert or deny the existence of ent.fqdn. This is what I think > >> David means with "wildcard response spoofed into a NOERROR/NODATA > >> or some other delegation. > > > > My understanding is that would be a bug in your signer. You can't > > have opt-out NSEC3 records covering the part of a zone under a > > wildcard, which is what was meant by "incompatible". > > In this example, the wildcard is not covered by the opt-out NSEC3 > record. The 'blocking' name is, because that is derived from an > insecure delegation. > > I am not sure what you mean by "wildcard is not covered by opt-out NSEC3 record" - Did you mean to say that *.fqdn does not have the opt-out bit set ? Are you using a mix of opt-out and no opt-out in this example ? If the record returned in the Authority section has opt-out bit set, then it is insecure (not explicitly mentioned in section 7.2.6 of 5155) -mohan Matthijs > > > > > Tony. > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJQ1JPTAAoJEA8yVCPsQCW5CWEH/3RLKffWSdo7bZDsF4wDCcdb > Nj4qN/QTTz0yo9R7tc1pbRW7wVJIkDMGYlhYfzkXHeY5ncpWis7GxRApvyAJt/tQ > AunUD1et6W/Um03pf5MOE3xY+VYgwo7JGRbK1UtJvNjWEEE0CvB/8YdpqYprIbxM > DCsT/qkbwowxzy7f37H2nu5Tt7S5yt0RMSkl7z5pWIX5C7CbmmghvnLrsWuZ57F2 > 9TQsj2BZPoZoHyKtsSXbrTGTb/PvISCYHV5P+/I6Tjy+pztuDd4Gok0gWxhtZCnI > oJ2EIBJkrQ9nM2Sw0bO0xS1oCVVeF2LmNSAqR1HzMHBhSBlrRnKl+15X4EZzamQ= > =aPtY > -----END PGP SIGNATURE----- > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --f46d043c805621272004d1616338 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Dec 21, 2012 at 8:52 AM, Matthijs Mekking <matthijs@nl= netlabs.nl> wrote:
-----BEGIN PGP SIGNED MESS= AGE-----
Hash: SHA1

On 12/21/2012 05:04 PM, Tony Finch wrote:
> Matthijs Mekking <matthijs= @nlnetlabs.nl> wrote:
>>
>> Let's try with an example.
>>
>> fqdn. =A0 =A0 =A0 =A0IN SOA and stuff. *.fqdn. =A0 =A0 =A0IN A 1.3= .3.7
>> ns.ent.fqdn. IN NS somewhere.
>>
>> A query for <A, ent.fqdn.> can now be answered with
>>
>> ;; ANSWER SECTION ent.fqdn. =A0 =A0IN A 1.3.3.7 (expanded from the=
>> wildcard)
>>
>> ;; AUTHORITY SECTION h(x).fqdn. IN NSEC3 ... (covering
>> ent.fqdn.)
>>
>> h(x).fqdn. has its opt-out bit set, so the validator cannot
>> assert or deny the existence of ent.fqdn. This is what I think
>> David means with "wildcard response spoofed into a NOERROR/NO= DATA
>> or some other delegation.
>
> My understanding is that would be a bug in your signer. You can't<= br> > have opt-out NSEC3 records covering the part of a zone under a
> wildcard, which is what was meant by "incompatible".

In this example, the wildcard is not covered by the opt-out NSEC3
record. The 'blocking' name is, because that is derived from an
insecure delegation.

I am not sure what you mean by "wildcard i= s not covered by opt-out NSEC3 record" - Did you mean to say that *.fq= dn does not have the opt-out bit set ? Are you using a mix of opt-out and n= o opt-out in this example ?=A0

If the record returned in the Authority sec= tion has opt-out bit set, then it is insecure (not explicitly mentioned in = section 7.2.6 of 5155)

-mohan

Matthijs

>
> Tony.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ1JPTAAoJEA8yVCPsQCW5CWEH/3RLKffWSdo7bZDsF4wDCcdb
Nj4qN/QTTz0yo9R7tc1pbRW7wVJIkDMGYlhYfzkXHeY5ncpWis7GxRApvyAJt/tQ
AunUD1et6W/Um03pf5MOE3xY+VYgwo7JGRbK1UtJvNjWEEE0CvB/8YdpqYprIbxM
DCsT/qkbwowxzy7f37H2nu5Tt7S5yt0RMSkl7z5pWIX5C7CbmmghvnLrsWuZ57F2
9TQsj2BZPoZoHyKtsSXbrTGTb/PvISCYHV5P+/I6Tjy+pztuDd4Gok0gWxhtZCnI
oJ2EIBJkrQ9nM2Sw0bO0xS1oCVVeF2LmNSAqR1HzMHBhSBlrRnKl+15X4EZzamQ=3D
=3DaPtY
-----END PGP SIGNATURE-----
___________________________________= ____________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext

--f46d043c805621272004d1616338-- From ed.lewis@neustar.biz Fri Dec 21 11:23:44 2012 Return-Path: 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 DB7DD21F845D for ; Fri, 21 Dec 2012 11:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.929 X-Spam-Level: X-Spam-Status: No, score=-100.929 tagged_above=-999 required=5 tests=[AWL=0.273, 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 PUAm-091Bntb for ; Fri, 21 Dec 2012 11:23:44 -0800 (PST) Received: from eastrmfepo203.cox.net (eastrmfepo203.cox.net [68.230.241.218]) by ietfa.amsl.com (Postfix) with ESMTP id 01AEE21F8586 for ; Fri, 21 Dec 2012 11:23:43 -0800 (PST) Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo203.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121221192340.WJTI29905.eastrmfepo203.cox.net@eastrmimpo210> for ; Fri, 21 Dec 2012 14:23:40 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo210 with cox id eKPf1k00T3cuADQ01KPgUT; Fri, 21 Dec 2012 14:23:40 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020209.50D4B73C.0106,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=R/2B6KtX c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=vEb-JLZKi4kA:10 a=hGBaWAWWAAAA:8 a=qVfqAfe6hbUA:10 a=51_ngRED_UWKosc57IAA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=UGEwT_Dh9V-IVJQW:21 a=o2_0XHrNTYizWFQe:21 a=gOEtbwst4t-8DKlUusMA:9 a=_W_S_7VecoQA:10 a=W2p7w_BTirvtfC1R: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=_50AF24FA-A0A6-4656-A8EB-EB90CFB5F7B3" From: Edward Lewis X-Priority: 3 In-Reply-To: <3FF91D04B500497C84CF362E3967FE40@LENOVO47E041CF> Date: Fri, 21 Dec 2012 14:23:39 -0500 Message-Id: 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <3FF91D04B500497C84CF362E3967FE40@LENOVO47E041CF> To: dnsext mailing list X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: [dnsext] On dying WGs, bugs and incompatibilities, was Re: Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 19:23:45 -0000 --Apple-Mail=_50AF24FA-A0A6-4656-A8EB-EB90CFB5F7B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 21, 2012, at 1:32, Jiankang YAO wrote: > which working group you will pitch in since the dnsext will soon close = down? First, the process question. The plan to handle the situation here is = to submit an errata against RFC 5155. Instead of just doing so = outright, I wanted to get community feedback on what the right approach = is. This nugget of work is itself a "bug fix" against a completed RFC, = something that is permanent - unlike WGs which my design are supposed to = come and go. The "bug" or "incompatibility" of wildcards and opt-out has been long = known. But I don't think it's a major problem. On paper it looks like = someone can spoof in a delegation that blocks a wildcard synthesis. But = in operations, the zones that would need to use opt-out are not zones = that (generally) use wildcards. You could, easily, but, in reality, no = one does - outside of testing perhaps. A malicious person could steal a credit card to pay for a stolen = identity to register a name to host malware OR cache poison a bunch of = servers via a Kaminsky-style attack to insert a name to host malware. = I'm not trained to think like a black-hat, but is seems to me that the = former is a lot more common and promises more payoff. As far as the notion that opt-out would be used in zone where the names = are numbers - enum or reverse - opt-out isn't all that useful. Besides = the limited "guess space" in the number zones, operational use of enum = has greater issues with confidentiality of the zones. (I.e., bigger = fish to fry.) But ... What I'll repeat here is that I think that omitting ENTs from = the NSEC3 chain is a optimization that gains little and costs a lot. A = lot in debugging time, a lot in spec writing time (because of having to = expand the rules in the signer, server, and validator) and coding time. = Even if the spec and coding are sunk costs a this point, debugging and = other maintenance costs lie in the future. = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_50AF24FA-A0A6-4656-A8EB-EB90CFB5F7B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
which working group you will = pitch in since the dnsext will soon close = down?

First, the process = question.  The plan to handle the situation here is to submit an = errata against RFC 5155.  Instead of just doing so outright, I = wanted to get community feedback on what the right approach is. =  This nugget of work is itself a "bug fix" against a completed RFC, = something that is permanent - unlike WGs which my design are supposed to = come and go.

The "bug" or "incompatibility" of = wildcards and opt-out has been long known.  But I don't think it's = a major problem.  On paper it looks like someone can spoof in a = delegation that blocks a wildcard synthesis.  But in operations, = the zones that would need to use opt-out are not zones that (generally) = use wildcards.  You could, easily, but, in reality, no one does - = outside of testing perhaps.

A malicious person = could steal a credit card to pay for a stolen identity to register a = name to host malware OR cache poison a bunch of servers via a = Kaminsky-style attack to insert a name to host malware.  I'm not = trained to think like a black-hat, but is seems to me that the former is = a lot more common and promises more payoff.

As = far as the notion that opt-out would be used in zone where the names are = numbers - enum or reverse - opt-out isn't all that useful.  Besides = the limited "guess space" in the number zones, operational use of enum = has greater issues with confidentiality of the zones.  (I.e., = bigger fish to fry.)

But ... What I'll repeat = here is that I think that omitting ENTs from the NSEC3 chain is a = optimization that gains little and costs a lot.  A lot in debugging = time, a lot in spec writing time (because of having to expand the rules = in the signer, server, and validator) and coding time.  Even if the = spec and coding are sunk costs a this point, debugging and other = maintenance costs lie in the future.

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

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

= --Apple-Mail=_50AF24FA-A0A6-4656-A8EB-EB90CFB5F7B3-- From ogud@ogud.com Thu Dec 27 07:23:24 2012 Return-Path: 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 C120F21F8D3B for ; Thu, 27 Dec 2012 07:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.264 X-Spam-Level: X-Spam-Status: No, score=-103.264 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, 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 O7-YXWZR3WNe for ; Thu, 27 Dec 2012 07:23:24 -0800 (PST) Received: from smtp128.dfw.emailsrvr.com (smtp128.dfw.emailsrvr.com [67.192.241.128]) by ietfa.amsl.com (Postfix) with ESMTP id 0E64A21F88D0 for ; Thu, 27 Dec 2012 07:23:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 6B4623C023B; Thu, 27 Dec 2012 10:23:23 -0500 (EST) X-Virus-Scanned: OK Received: by smtp12.relay.dfw1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id B43BB3C0164; Thu, 27 Dec 2012 10:23:22 -0500 (EST) Message-ID: <50DC67E7.3010806@ogud.com> Date: Thu, 27 Dec 2012 10:23:19 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <50CA50AA.1070206@ogud.com> In-Reply-To: <50CA50AA.1070206@ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ogud@ogud.com Subject: Re: [dnsext] RFC2671bis issue that requires more discussion X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 15:23:24 -0000 There has been no discussion on this topic and I have not received any private messages about this topic. If I do not hear anything by January 5'th 2013 the chairs and AD will be free to do what ever they think is appropriate including keeping the registry open. Olafur On 13/12/2012 17:03, Olafur Gudmundsson wrote: > Dear Colleagues, > > During IETF last call the closing of the extended labels registry was > called in question as premature. > The discussion in question starts with this message: > http://www.ietf.org/mail-archive/web/ietf/current/msg75147.html > > Thus the question to the working group is: > Is the action recommenced in RFC2671bis to close the extended labels > registry and obsolete the assignments in there (bit labels and expansion > to larger label type identifier), > > a) based on solid experience > b) justified and supported by the working group > > or should the document be revised? > > Olafur & Andrew > > ps: See: > http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-10 > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From joao@bondis.org Thu Dec 27 07:47:22 2012 Return-Path: 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 D4ED421F8D52 for ; Thu, 27 Dec 2012 07:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 9J3hiYYAJ7bq for ; Thu, 27 Dec 2012 07:47:22 -0800 (PST) Received: from smtp1.bondis.org (unknown [IPv6:2001:ac0:1003::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0775B21F8D50 for ; Thu, 27 Dec 2012 07:47:21 -0800 (PST) Received: from book3.c-l-i.net (unknown [80.31.179.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: joao) by smtp1.bondis.org (Postfix) with ESMTPSA id 59C206204DF; Thu, 27 Dec 2012 16:47:18 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joao Damas In-Reply-To: <50DC67E7.3010806@ogud.com> Date: Thu, 27 Dec 2012 16:47:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4FBB201D-70D4-423C-8CCD-D01AD60262F2@bondis.org> References: <50CA50AA.1070206@ogud.com> <50DC67E7.3010806@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1499) Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC2671bis issue that requires more discussion X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 15:47:23 -0000 I have text ready to go. I am going to post it tomorrow to the list = (it's a special date in Spain and some other Spanish speaking countries) The added text is meant to address John Klensin's comments on the = label-registry by not closing the registry through this document but = trying to explain how hard that route can be for deployment of new = features. This is in the hope that future developers can weight pros and = cons of that route based on field experience, derived from binary = labels. Joao On 27 Dec 2012, at 16:23, Olafur Gudmundsson wrote: > There has been no discussion on this topic and I have not received any > private messages about this topic. > If I do not hear anything by January 5'th 2013 the chairs and AD will = be free to do what ever they think is appropriate including keeping the > registry open. >=20 > Olafur >=20 >=20 >=20 > On 13/12/2012 17:03, Olafur Gudmundsson wrote: >> Dear Colleagues, >>=20 >> During IETF last call the closing of the extended labels registry was >> called in question as premature. >> The discussion in question starts with this message: >> http://www.ietf.org/mail-archive/web/ietf/current/msg75147.html >>=20 >> Thus the question to the working group is: >> Is the action recommenced in RFC2671bis to close the extended labels >> registry and obsolete the assignments in there (bit labels and = expansion >> to larger label type identifier), >>=20 >> a) based on solid experience >> b) justified and supported by the working group >>=20 >> or should the document be revised? >>=20 >> Olafur & Andrew >>=20 >> ps: See: >> = http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-para= meters-10 >>=20 >>=20 >>=20 >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >>=20 >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From msheldon@godaddy.com Thu Dec 27 08:59:10 2012 Return-Path: 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 944E421F8A4A for ; Thu, 27 Dec 2012 08:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Lfx43Sk9uq-m for ; Thu, 27 Dec 2012 08:59:10 -0800 (PST) Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by ietfa.amsl.com (Postfix) with ESMTP id D797A21F86B8 for ; Thu, 27 Dec 2012 08:59:09 -0800 (PST) Received: from gem-wbe39.prod.mesa1.secureserver.net ([64.202.189.53]) by smtpoutwbe11.prod.mesa1.secureserver.net with bizsmtp id ggz81k00319aCvU01gz8mu; Thu, 27 Dec 2012 09:59:08 -0700 Received: (qmail 29261 invoked by uid 99); 27 Dec 2012 16:59:08 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 172.19.38.144 User-Agent: Workspace Webmail 5.6.30 Message-Id: <20121227095907.205a61dff9fc1684c258b274662bb912.188c1d4f4c.wbe@email00.secureserver.net> From: "Michael Sheldon" To: dnsext@ietf.org Date: Thu, 27 Dec 2012 09:59:07 -0700 Mime-Version: 1.0 Subject: Re: [dnsext] RFC2671bis issue that requires more discussion X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 16:59:10 -0000 While I cannot come up with any need for extended label types right now,=0A= it certainly could be a lack of imagination on my part. I see no harm in=0A= keeping the registry open.=0A=0AMichael Sheldon=0ADev-DNS Services=0AGoDadd= y.com=0A=0A> -------- Original Message --------=0A> Subject: Re: [dnsext] R= FC2671bis issue that requires more discussion=0A> From: Olafur Gudmundsson = =0A> Date: Thu, December 27, 2012 8:23 am=0A> To: dnsext@iet= f.org=0A> Cc: ogud@ogud.com=0A> =0A> =0A> There has been no discussion on t= his topic and I have not received any=0A> private messages about this topic= .=0A> If I do not hear anything by January 5'th 2013 the chairs and AD will= be =0A> free to do what ever they think is appropriate including keeping t= he=0A> registry open.=0A> =0A> =09Olafur=0A> =0A> =0A> =0A> On 13/12/2012 1= 7:03, Olafur Gudmundsson wrote:=0A> > Dear Colleagues,=0A> >=0A> > During I= ETF last call the closing of the extended labels registry was=0A> > called = in question as premature.=0A> > The discussion in question starts with this= message:=0A> > http://www.ietf.org/mail-archive/web/ietf/current/msg75147.= html=0A> >=0A> > Thus the question to the working group is:=0A> > Is the ac= tion recommenced in RFC2671bis to close the extended labels=0A> > registry = and obsolete the assignments in there (bit labels and expansion=0A> > to la= rger label type identifier),=0A> >=0A> > a) based on solid experience= =0A> > b) justified and supported by the working group=0A> >=0A> > or = should the document be revised?=0A> >=0A> > Olafur & Andrew=0A> >=0A> = > ps: See:=0A> > http://www.iana.org/assignments/dns-parameters/dns-paramet= ers.xml#dns-parameters-10=0A> >=0A> >=0A> >=0A> > _________________________= ______________________=0A> > dnsext mailing list=0A> > dnsext@ietf.org=0A> = > https://www.ietf.org/mailman/listinfo/dnsext=0A> >=0A> =0A> _____________= __________________________________=0A> dnsext mailing list=0A> dnsext@ietf.= org=0A> https://www.ietf.org/mailman/listinfo/dnsext From ed.lewis@neustar.biz Thu Dec 27 12:46:31 2012 Return-Path: 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 C421921F8CFC for ; Thu, 27 Dec 2012 12:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.341 X-Spam-Level: X-Spam-Status: No, score=-99.341 tagged_above=-999 required=5 tests=[AWL=-1.339, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 uKikeYhjdFJC for ; Thu, 27 Dec 2012 12:46:29 -0800 (PST) Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by ietfa.amsl.com (Postfix) with ESMTP id 1125921F8CF8 for ; Thu, 27 Dec 2012 12:46:28 -0800 (PST) Received: from eastrmimpo110 ([68.230.241.223]) by eastrmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121227204628.YWDV17456.eastrmfepo201.cox.net@eastrmimpo110> for ; Thu, 27 Dec 2012 15:46:28 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo110 with cox id gkmT1k00U3cuADQ01kmTnT; Thu, 27 Dec 2012 15:46:28 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020207.50DCB3A4.0073,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=N5Wr5hBB c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=TQE2bTnxFmcA:10 a=hGBaWAWWAAAA:8 a=jNJKH8nyEKgA:10 a=QfKxxUxMAAAA:8 a=6eNi9mUcLTzhORdhV8kA:9 a=wPNLvfGTeEIA:10 a=9k6G2--EmesA:10 a=o1-bKXAysiYXCCR6:21 a=CXGEreocBxbo1VDy:21 a=ZhvRuFtP0CYkiWGA3gUA:9 a=_W_S_7VecoQA:10 a=y3CfWACGumJWWdeD:21 a=iu2b7gTtmEAeA0CB:21 a=M83tMKi26KmGcInQ: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=_27D1F515-69FB-451F-8D40-F8299AFCB4AA" From: Edward Lewis In-Reply-To: <50D48680.7080806@nlnetlabs.nl> Date: Thu, 27 Dec 2012 15:46:27 -0500 Message-Id: <4257FFD6-2049-41B2-B13F-7606D129DE54@neustar.biz> 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> <50D41289.80903@nlnetlabs.nl> <50D48680.7080806@nlnetlabs.nl> To: dnsextmailing list X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 20:46:31 -0000 --Apple-Mail=_27D1F515-69FB-451F-8D40-F8299AFCB4AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The example is wrong...sorry, just getting aound to replying. If ns.ent.fqdn. has an NS record and ent.fqdn. is empty, then the = wildcard expansion won't happen if the latter is a QNAME. The conflict between wild cards and opt-out is better illustrated by = getting this example. If a malicious agent wants to forge a response to = "www.foo.fqdn. A" as a referral to ns666.servers.fqdn. and not = "www.foo.fqdn. A 1.3.3.7" they can succeed with available opt-out = records. I.e., you can forge into existence a delegation in an opt-out = range. BUT ... that is no worse than not having DNSSEC. That is the low-bar = yardstick that used when evaluating tradeoffs. While there are = advantages in many places, if you deploy a wildcard and opt-out you are = no better off with DNSSEC than without in the worst cases. And DNSSEC can't ensure data gets to the recipient, it can only help the = recipient decide to reject bad data. On the Internet, you can never = guarantee delivery of a signal, no matter what you do - even TCP only = guarantees what arrives comes in order. Ed ...Still thinking about this because I'm not sure of the optimization = here bypassing ENTs in the NSEC3) is worth the hassle.=20 On Dec 21, 2012, at 10:55, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 12/21/2012 03:50 PM, Tony Finch wrote: >> Matthijs Mekking wrote: >>>=20 >>> A zone with a wildcard configured somewhere, and with insecure=20 >>> delegations (possibly a few labels deep, so there are some empty=20 >>> non-terminals) is vulnerable to attacks where the insecure >>> delegation or one of the derived empty non-terminals is expanded >>> to the wildcard. >>=20 >> I'm confused. Can you explain this in more detail? >=20 > Let's try with an example. >=20 > fqdn. IN SOA and stuff. > *.fqdn. IN A 1.3.3.7 > ns.ent.fqdn. IN NS somewhere. >=20 > A query for can now be answered with >=20 > ;; ANSWER SECTION > ent.fqdn. IN A 1.3.3.7 (expanded from the wildcard) >=20 > ;; AUTHORITY SECTION > h(x).fqdn. IN NSEC3 ... (covering ent.fqdn.) >=20 > h(x).fqdn. has its opt-out bit set, so the validator cannot assert or > deny the existence of ent.fqdn. This is what I think David means with > "wildcard response spoofed into a NOERROR/NODATA or some other = delegation. >=20 >>=20 >> I don't understand what additional security problem is caused by=20 >> wildcards. Can't you just avoid the problem by not having opt-out=20 >> NSEC3 records for the part of the zone affected by the wildcard? >=20 > The part of the zone affected is the opt-out range. >=20 >> I understand that an attacker can spoof insecure delegations within >> an opt-out range. >=20 > And it can spoof other stuff in the opt-out range. >=20 >>=20 >> Tony. >>=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ >=20 > iQEcBAEBAgAGBQJQ1IaAAAoJEA8yVCPsQCW5AdMH/RS8c5GZx7LLW9ccw2lGVsIn > bAY1OGFIBmOZbcsORe6e/RdqgmAji3UyVyh7ADjE+xGZC5uawaqsjpxxfXwFbX7h > lBjDf7NBPhZrzbeWtV8xEpke+cUYY7K+2qsOaEhfJvPaeBVn4C4xtLWAMGD8xv0q > iEEgPjlESoDRSMJEoXp4czMqQdS/AuowuyCVc21I03/gDkMDTV31123ZlgQ1ph5M > UdcF/0C++0tSmwVnoFMcFkHIu769s0L+EnoVReR/WCfemzQXCHyt+g4OdtrM56WN > 8Pl95eyXQnQ4UpfaZ8Sn+dX68QQ4Q6UTmft/lIOevQN4wsiadot5PffaXjq3AyU=3D > =3D1LMf > -----END PGP SIGNATURE----- = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_27D1F515-69FB-451F-8D40-F8299AFCB4AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 www.foo.fqdn. A" as a referral to = ns666.servers.fqdn. and not "www.foo.fqdn. A 1.3.3.7" they can = succeed with available opt-out records.  I.e., you can forge into = existence a delegation in an opt-out range.

BUT = ... that is no worse than not having DNSSEC.  That is the low-bar = yardstick that used when evaluating tradeoffs.  While there are = advantages in many places, if you deploy a wildcard and opt-out you are = no better off with DNSSEC than without in the worst = cases.

And DNSSEC can't ensure data gets to the = recipient, it can only help the recipient decide to reject bad data. =  On the Internet, you can never guarantee delivery of a signal, no = matter what you do - even TCP only guarantees what arrives comes in = order.

Ed

...Still = thinking about this because I'm not sure of the optimization here = bypassing ENTs in the NSEC3) is worth the = hassle. 

On Dec 21, 2012, at 10:55, Matthijs = Mekking wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA1

On 12/21/2012 03:50 PM, Tony Finch wrote:
Matthijs Mekking <matthijs@nlnetlabs.nl> = wrote:

A zone with a wildcard = configured somewhere, and with insecure =
delegations (possibly a few labels deep, so there are some = empty
non-terminals) is vulnerable to attacks where the = insecure
delegation or one of the derived = empty non-terminals is expanded
to the = wildcard.

I'm confused. = Can you explain this in more detail?

Let's try with = an example.

fqdn.        IN = SOA and stuff.
*.fqdn.      IN A = 1.3.3.7
ns.ent.fqdn. IN NS somewhere.

A query for <A, = ent.fqdn.> can now be answered with

;; ANSWER = SECTION
ent.fqdn.    IN A 1.3.3.7 (expanded from the = wildcard)

;; AUTHORITY SECTION
h(x).fqdn. IN NSEC3 ... = (covering ent.fqdn.)

h(x).fqdn. has its opt-out bit set, so the = validator cannot assert or
deny the existence of ent.fqdn. This is = what I think David means with
"wildcard response spoofed into a = NOERROR/NODATA or some other delegation.


I don't = understand what additional security problem is caused by =
wildcards. Can't you just = avoid the problem by not having opt-out
NSEC3 records for the part of the zone affected by the = wildcard?

The part of the zone affected is the = opt-out range.

I understand that an = attacker can spoof insecure delegations = within
an opt-out = range.

And it can spoof other stuff in the opt-out = range.


Tony.


-----BEGIN PGP = SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using = GnuPG with undefined - http://www.enigmail.net/

iQEc= BAEBAgAGBQJQ1IaAAAoJEA8yVCPsQCW5AdMH/RS8c5GZx7LLW9ccw2lGVsIn
bAY1OGFIBm= OZbcsORe6e/RdqgmAji3UyVyh7ADjE+xGZC5uawaqsjpxxfXwFbX7h
lBjDf7NBPhZrzbeW= tV8xEpke+cUYY7K+2qsOaEhfJvPaeBVn4C4xtLWAMGD8xv0q
iEEgPjlESoDRSMJEoXp4cz= MqQdS/AuowuyCVc21I03/gDkMDTV31123ZlgQ1ph5M
UdcF/0C++0tSmwVnoFMcFkHIu769= s0L+EnoVReR/WCfemzQXCHyt+g4OdtrM56WN
8Pl95eyXQnQ4UpfaZ8Sn+dX68QQ4Q6UTmf= t/lIOevQN4wsiadot5PffaXjq3AyU=3D
=3D1LMf
-----END PGP = SIGNATURE-----

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

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

= --Apple-Mail=_27D1F515-69FB-451F-8D40-F8299AFCB4AA-- From matthijs@nlnetlabs.nl Thu Dec 27 14:22:59 2012 Return-Path: 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 BC81721F8D8E for ; Thu, 27 Dec 2012 14:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.059 X-Spam-Level: X-Spam-Status: No, score=-102.059 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 6LArtl-3QyFa for ; Thu, 27 Dec 2012 14:22:59 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5DA21F8D59 for ; Thu, 27 Dec 2012 14:22:58 -0800 (PST) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id qBRMMeYA055282 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 27 Dec 2012 23:22:43 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.3 open.nlnetlabs.nl qBRMMeYA055282 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1356646971; bh=g3mFUMh3PWz17jvLjed4Rza1hs0jypGmjdoMnoERVMs=; h=Date:From:To:Subject:References:In-Reply-To; b=bBT4UmwxkZJcYBlfTiO7ABuyu8q5N3CAyFG9t7ocsy+v/fMgRmyjvOJbxPWCAkNQM SU5zgbqyjEV65MXDrYEuWuJsQjmf2s8dlGT43U2OHXjH2rI0KcUz4EnsdDI7akNTyb ajzxsy/iuLWhADza+Aq59PMEC5kGmF/oHCjOsmOc= Message-ID: <50DCCA35.1040401@nlnetlabs.nl> Date: Thu, 27 Dec 2012 23:22:45 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: dnsext@ietf.org 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> <50D41289.80903@nlnetlabs.nl> <50D48680.7080806@nlnetlabs.nl> <4257FFD6-2049-41B2-B13F-7606D129DE54@neustar.biz> In-Reply-To: <4257FFD6-2049-41B2-B13F-7606D129DE54@neustar.biz> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Thu, 27 Dec 2012 23:22:45 +0100 (CET) Subject: Re: [dnsext] Clarifying a few points in Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 22:22:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/27/2012 09:46 PM, Edward Lewis wrote: > The example is wrong...sorry, just getting aound to replying. > > If ns.ent.fqdn. has an NS record and ent.fqdn. is empty, then the > wildcard expansion won't happen if the latter is a QNAME. Won't happen, but it can be forged with available NSEC3 records. > The conflict between wild cards and opt-out is better illustrated > by getting this example. If a malicious agent wants to forge a > response to "www.foo.fqdn. A" as a referral to ns666.servers.fqdn. > and not "www.foo.fqdn. A 1.3.3.7" they can succeed with available > opt-out records. I.e., you can forge into existence a delegation > in an opt-out range. If foo.fqdn. is an insecure delegation then yes (I would encourage you to write down the example). > BUT ... that is no worse than not having DNSSEC. That is the > low-bar yardstick that used when evaluating tradeoffs. While there > are advantages in many places, if you deploy a wildcard and opt-out > you are no better off with DNSSEC than without in the worst cases. I agree. I would even say: if you deploy opt-out you are no better off with DNSSEC than without in the worst cases. Best regards, Matthijs > And DNSSEC can't ensure data gets to the recipient, it can only > help the recipient decide to reject bad data. On the Internet, you > can never guarantee delivery of a signal, no matter what you do - > even TCP only guarantees what arrives comes in order. > > Ed > > ...Still thinking about this because I'm not sure of the > optimization here bypassing ENTs in the NSEC3) is worth the > hassle. > > On Dec 21, 2012, at 10:55, Matthijs Mekking wrote: > > On 12/21/2012 03:50 PM, Tony Finch wrote: >>>> Matthijs Mekking wrote: >>>>> >>>>> A zone with a wildcard configured somewhere, and with >>>>> insecure delegations (possibly a few labels deep, so there >>>>> are some empty non-terminals) is vulnerable to attacks >>>>> where the insecure delegation or one of the derived empty >>>>> non-terminals is expanded to the wildcard. >>>> >>>> I'm confused. Can you explain this in more detail? > > Let's try with an example. > > fqdn. IN SOA and stuff. *.fqdn. IN A 1.3.3.7 > ns.ent.fqdn. IN NS somewhere. > > A query for can now be answered with > > ;; ANSWER SECTION ent.fqdn. IN A 1.3.3.7 (expanded from the > wildcard) > > ;; AUTHORITY SECTION h(x).fqdn. IN NSEC3 ... (covering ent.fqdn.) > > h(x).fqdn. has its opt-out bit set, so the validator cannot assert > or deny the existence of ent.fqdn. This is what I think David > means with "wildcard response spoofed into a NOERROR/NODATA or some > other delegation. > >>>> >>>> I don't understand what additional security problem is >>>> caused by wildcards. Can't you just avoid the problem by not >>>> having opt-out NSEC3 records for the part of the zone >>>> affected by the wildcard? > > The part of the zone affected is the opt-out range. > >>>> I understand that an attacker can spoof insecure delegations >>>> within an opt-out range. > > And it can spoof other stuff in the opt-out range. > >>>> >>>> Tony. >>>> > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > Edward Lewis > NeuStar You can leave a voice message at > +1-571-434-5468 > > There are no answers - just tradeoffs, decisions, and responses. > > > > > _______________________________________________ dnsext mailing list > dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ3Mo1AAoJEA8yVCPsQCW5HW0IAMwllLuPn/aLgcam3k9meHZS 0e6lf/b9M7c/ngZkS4VM2gnYb2ANVeaz7W94L/bJQqri8i4mmJRXzjBAVD9P0fxG 3gOdQf9Ln/WVgWMUibwDkMyEZHNd9t6gRneBq48Qaiw7dli2yZPOxNe2lX1pqURf Jh7m4xr2XC9//PkRig7qMqsGBadQiE2CoQ6AY9oYTjl20Wjeo7cfYOUttbqwzOVE TOKWyB4gpQfMFb1qQ8Ebwo/BATS3gthtsc1CJr3l7KgBlkYfS1VcQiefftyS1x4n c9THpsabc/p2SgyZMNxl4zfLv1f3eDfzhyvzV5Wj9Rn3GLwNS4KwWy/GkTmGrQM= =5/xI -----END PGP SIGNATURE----- From rwfranks@gmail.com Thu Dec 27 16:19:30 2012 Return-Path: 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 C00C321F8A84 for ; Thu, 27 Dec 2012 16:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 i+G9x7MpznqD for ; Thu, 27 Dec 2012 16:19:30 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD47821F8438 for ; Thu, 27 Dec 2012 16:19:29 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id o1so7942722wic.17 for ; Thu, 27 Dec 2012 16:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=qv9rtBtvZoTAAO2lfGDe9QreUqO7oP0IP4El3TyrqbY=; b=tMF6AgOW5ckLQyyo7rpzGtE5fSFNeu02xc5aaKWMLgbDvu93DVONWdXgZ3m7Kh8GfI Vc9GYsocrQoIdlfJgf29SURDwyFBfSJ65ImMZMJHkjl4FAHahIVY5c3LAKlWqDP4GVeS 7CwhPOB0JowrOWQX06P3+GH6/DJbhF7guBfwdZnjZP+w0Tond5Xpuku0Uw1QaGBaXHCM mhIe3zXpMIdNSGt5DZ22SfIUrCP5y+Oyp+Esv/Ep7O+IbZb6CQcn6y0S5Axl3C1f6dB9 bZTL/2cSV+nR+T2LPNQvsldXO/Sar4ziyjIUzwGx7S8S2ZBF3Z4Yhkl/9EHONTHxy8ty VnbA== Received: by 10.194.9.4 with SMTP id v4mr51406232wja.50.1356653968772; Thu, 27 Dec 2012 16:19:28 -0800 (PST) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.194.18.65 with HTTP; Thu, 27 Dec 2012 16:19:08 -0800 (PST) In-Reply-To: <50DC67E7.3010806@ogud.com> References: <50CA50AA.1070206@ogud.com> <50DC67E7.3010806@ogud.com> From: Dick Franks Date: Fri, 28 Dec 2012 00:19:08 +0000 X-Google-Sender-Auth: aaj6dMHsuWQKfefiWiP9PFtZCdk Message-ID: To: Olafur Gudmundsson Content-Type: text/plain; charset=UTF-8 Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC2671bis issue that requires more discussion X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 00:19:30 -0000 IMHO draft RFC2671bis should not be revised. The text requesting closure of the registry has been present since draft 2 (July 2009). WG participants had ample opportunity to post objections to this proposal before the draft was submitted to IESG for approval, but declined to do so. The silent majority are either content for the registry to be closed, or hold no opinion strongly enough to warrant breaking the silence. Further contributions should now be confined to addressing the specific comments raised during the IESG review process, and participants need to make some genuine effort to stay on-topic long enough to get this ID published. Attempts to change the text beyond the minimum required to satisfy IESG should be stoutly rejected, otherwise we will be headed for another five years of pointless bickering! Dick -- On 27 December 2012 15:23, Olafur Gudmundsson wrote: > There has been no discussion on this topic and I have not received any > private messages about this topic. > If I do not hear anything by January 5'th 2013 the chairs and AD will be > free to do what ever they think is appropriate including keeping the > registry open. > > Olafur > > > > > On 13/12/2012 17:03, Olafur Gudmundsson wrote: >> >> Dear Colleagues, >> >> During IETF last call the closing of the extended labels registry was >> called in question as premature. >> The discussion in question starts with this message: >> http://www.ietf.org/mail-archive/web/ietf/current/msg75147.html >> >> Thus the question to the working group is: >> Is the action recommenced in RFC2671bis to close the extended labels >> registry and obsolete the assignments in there (bit labels and expansion >> to larger label type identifier), >> >> a) based on solid experience >> b) justified and supported by the working group >> >> or should the document be revised? >> >> Olafur & Andrew >> >> ps: See: >> >> http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-10 >> >> >> >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >> > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From sm@resistor.net Fri Dec 28 03:30:47 2012 Return-Path: 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 31F0D21F87EA for ; Fri, 28 Dec 2012 03:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.62 X-Spam-Level: X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, 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 I0llwNkrxC53 for ; Fri, 28 Dec 2012 03:30:46 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1C921F86EA for ; Fri, 28 Dec 2012 03:30:46 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qBSBUebY003465 for ; Fri, 28 Dec 2012 03:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1356694244; bh=ysEO6ryL0Y5R3vIcApzYMgaNY3qHXYg0jsTqarvRsWY=; h=Date:To:From:Subject:In-Reply-To:References; b=Mu2hM+GBHFrBLUUwYwCzPDbJtJmj4pKXFQBde6WU5GFKlZDvxzzeOLfhZaPuPqXNT c4VW6u7RQMvPf2jhQhQg5vJq+SiN8PznYs20Uk9rb/yUZfNNeLDG6GPFnHiwAJDip7 lK5vO93H9fuNjkz7MCTWCscsBfVVjA+7Dwhn5JEc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1356694244; i=@resistor.net; bh=ysEO6ryL0Y5R3vIcApzYMgaNY3qHXYg0jsTqarvRsWY=; h=Date:To:From:Subject:In-Reply-To:References; b=x9Qg+CfDIX7xRg8wTBLskjoUeUsNCRRSUtDo+E5FgIQUwDtv6J5R6HDh+NbYHNAYD /ZUsqCr6MfF04Nl2SsPGGyZBp5SJjRPYIWy7zD1kkyJs9gqis9ODrPFQFiBkz+bV+H iZ7o65DOqZEs94cc3XLqrwXmdY0RmLo/4Dyt+UFo= Message-Id: <6.2.5.6.2.20121228031506.0b79b690@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 28 Dec 2012 03:26:11 -0800 To: dnsext@ietf.org From: SM In-Reply-To: References: <50CA50AA.1070206@ogud.com> <50DC67E7.3010806@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dnsext] RFC2671bis issue that requires more discussion X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 11:30:47 -0000 At 16:19 27-12-2012, Dick Franks wrote: >Further contributions should now be confined to addressing the >specific comments raised during the IESG review process, and >participants need to make some genuine effort to stay on-topic long >enough to get this ID published. Attempts to change the text beyond >the minimum required to satisfy IESG should be stoutly rejected, >otherwise we will be headed for another five years of pointless >bickering! The issue was actually raised during the Last Call. The approach mentioned by Joao might address the issue [1]. It's easier to leave the registry open instead of using "no WG discussion" as an argument to close the registry. Regards, -sm 1. http://www.ietf.org/mail-archive/web/dnsext/current/msg12856.html From rwfranks@gmail.com Fri Dec 28 04:59:37 2012 Return-Path: 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 D36C121F8D22 for ; Fri, 28 Dec 2012 04:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 HsJ5GVM+VTyy for ; Fri, 28 Dec 2012 04:59:37 -0800 (PST) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by ietfa.amsl.com (Postfix) with ESMTP id 08ED721F8CFB for ; Fri, 28 Dec 2012 04:59:36 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id r5so4787692wey.7 for ; Fri, 28 Dec 2012 04:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=DcKoMZyz4GGzulT5pSeWJ8Q1BA4+ZIVT6D+CLPiw4go=; b=NEGsTLsHbRrgOhupTUXJDLTOQ5Ilu90LY5YH5z2FGQPmqH7DlBJDDwl/rnVTvevTjN wo3kz/4YagD7Bc3Yr2BLdT/FpF3KWgQfDcmMWnB6jZZ/bxOoQ6sup8x8xAElhL9Tx3rY Dk0oLIIRnoumSBdsx6CQAYKtMddK5LaajpsUc+uLbwhL7mi1g/x0UM+yhB+mXCkPSQhx tMrg4iMnu/nxNJcxdruDmubc/JhV4JptbFF6oVIZC65OzIKyXdqjvWwz/aFczjpYtEOz LI/cxsxMugPdeyMGE57hnQ1sbxS8TO87ojHDNxy1XOb9LGBZSeHSFDjgTJ7jdhu+apxv FkbA== Received: by 10.181.13.75 with SMTP id ew11mr52686986wid.9.1356699575718; Fri, 28 Dec 2012 04:59:35 -0800 (PST) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.194.18.65 with HTTP; Fri, 28 Dec 2012 04:59:14 -0800 (PST) In-Reply-To: <6.2.5.6.2.20121228031506.0b79b690@resistor.net> References: <50CA50AA.1070206@ogud.com> <50DC67E7.3010806@ogud.com> <6.2.5.6.2.20121228031506.0b79b690@resistor.net> From: Dick Franks Date: Fri, 28 Dec 2012 12:59:14 +0000 X-Google-Sender-Auth: W56_bl_SIdrgE76xf4Od2Czxy2c Message-ID: To: SM Content-Type: text/plain; charset=UTF-8 Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC2671bis issue that requires more discussion X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 12:59:37 -0000 On 28 December 2012 11:26, SM wrote: > > The issue was actually raised during the Last Call. I stand corrected. However, the draft was passed to IESG with the request to close the registry still in it. Unless IESG is minded to raise a specific objection, the argument is over. > ... It's easier to leave the registry open > instead of using "no WG discussion" as an argument to close the registry. The argument is "WG content to leave text as it is". A WG full of Trappist monks can be in rough consensus. An awful lot of paper engineering effort is being expended to justify keeping open a registry which serves no purpose other than to divide code space between its non-users. Failure to take the opportunity to unload this excess baggage will leave an unnecessary obstacle in the path of future developments which may propose to reuse the space in ways better suited to their own purpose. Dick -- From internet-drafts@ietf.org Mon Dec 31 06:54:31 2012 Return-Path: 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 5E76421F8540; Mon, 31 Dec 2012 06:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, 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 IyHPQUh9v4iw; Mon, 31 Dec 2012 06:54:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC09721F883A; Mon, 31 Dec 2012 06:54:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121231145430.7144.9509.idtracker@ietfa.amsl.com> Date: Mon, 31 Dec 2012 06:54:30 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-10.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 14:54:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Extension Mechanisms for DNS (EDNS(0)) Author(s) : Joao Damas Michael Graff Paul Vixie Filename : draft-ietf-dnsext-rfc2671bis-edns0-10.txt Pages : 16 Date : 2012-12-31 Abstract: The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward compatible mechanisms for allowing the protocol to grow. This document updates the EDNS(0) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2671bis-edns0 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-rfc2671bis-edns0-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ed.lewis@neustar.biz Mon Dec 31 07:18:46 2012 Return-Path: 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 C5A1421F8872 for ; Mon, 31 Dec 2012 07:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.585 X-Spam-Level: X-Spam-Status: No, score=-99.585 tagged_above=-999 required=5 tests=[AWL=-0.983, BAYES_50=0.001, 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 VI0XwltvSv9k for ; Mon, 31 Dec 2012 07:18:46 -0800 (PST) Received: from eastrmfepo203.cox.net (eastrmfepo203.cox.net [68.230.241.218]) by ietfa.amsl.com (Postfix) with ESMTP id 2F36021F885E for ; Mon, 31 Dec 2012 07:18:45 -0800 (PST) Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo203.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121231151845.GTSG29905.eastrmfepo203.cox.net@eastrmimpo210> for ; Mon, 31 Dec 2012 10:18:45 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo210 with cox id iFJk1k00T3cuADQ01FJkyA; Mon, 31 Dec 2012 10:18:45 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020202.50E1ACD5.007D,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=R/2B6KtX c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=hGBaWAWWAAAA:8 a=-K7kHbPOKKsA:10 a=iTfQMBlZIDBPs3Jvhl8A:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=I-_wS540UDb2Sqo0mjcA:9 a=_W_S_7VecoQA:10 a=EbhN0ZHnQtW-2MOG: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=_81AE52F0-0FBC-476F-B159-861DC50D703D" From: Edward Lewis In-Reply-To: <50DCCA35.1040401@nlnetlabs.nl> Date: Mon, 31 Dec 2012 10:18:53 -0500 Message-Id: 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> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <20121220104539.GA929@miek.nl> <472E7A64-749B-4F0E-84B7-D0CA2CE1D613@dotat.at> <50D41289.80903@nlnetlabs.nl> <50D48680.7080806@nlnetlabs.nl> <4257FFD6-2049-41B2-B13F-7606D129DE54@neustar.biz> <50DCCA35.1040401@nlnetlabs.nl> To: dnsextmailing list X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: [dnsext] Wrap up of RFC 5155 issue X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 15:18:46 -0000 --Apple-Mail=_81AE52F0-0FBC-476F-B159-861DC50D703D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Looking over the discussion here and trying to figure out what should be = done...and not wanting to let this hang too long. If I had my choice, I'd try to simplify the protocol by signing the = empty non-terminals, putting more restrictions on the chain, and so on. = I'd do this because as an operator, this would make the protocol easier = to run, cheaper, simpler, and still get the objectives we want. But in the spirit of an errata, I'll submit the words given to me from = Roy (paragraphs shuffled as mentioned). That's the process thing to do. = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_81AE52F0-0FBC-476F-B159-861DC50D703D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Edward = Lewis             
NeuStar       = ;          =    You can leave a voice message at = +1-571-434-5468

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

= --Apple-Mail=_81AE52F0-0FBC-476F-B159-861DC50D703D--