From internet-drafts@ietf.org Tue May 1 11:39: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 D2A7321E8042; Tue, 1 May 2012 11:39:41 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5rN-gZBApDK; Tue, 1 May 2012 11:39:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2448521E801F; Tue, 1 May 2012 11:39:41 -0700 (PDT) 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.02 Message-ID: <20120501183941.609.53263.idtracker@ietfa.amsl.com> Date: Tue, 01 May 2012 11:39:41 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-06.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: Tue, 01 May 2012 18:39:42 -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 I= ETF. Title : Signaling Cryptographic Algorithm Understanding in DNSSEC Author(s) : Steve Crocker Scott Rose Filename : draft-ietf-dnsext-dnssec-algo-signal-06.txt Pages : 8 Date : 2012-05-01 The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms and hash algorithms they support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-06= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-06.= txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/ From scottr.nist@gmail.com Tue May 1 11:50:06 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 D2FAE21E82CB for ; Tue, 1 May 2012 11:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BX5tIppohg6f for ; Tue, 1 May 2012 11:50:05 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 2F61B21E822A for ; Tue, 1 May 2012 11:50:05 -0700 (PDT) Received: from WSGHUB2.xchange.nist.gov (129.6.16.197) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 1 May 2012 14:49:47 -0400 Received: from smtp.nist.gov (129.6.16.227) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Tue, 1 May 2012 14:49:40 -0400 Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q41Io1Gf012077 for ; Tue, 1 May 2012 14:50:03 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1084) From: Scott Rose In-Reply-To: <20120501183941.609.53263.idtracker@ietfa.amsl.com> Date: Tue, 1 May 2012 14:50:01 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7228DD40-A3A4-496D-B1B2-DC1358A4107E@gmail.com> References: <20120501183941.609.53263.idtracker@ietfa.amsl.com> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1084) Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-06.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: Tue, 01 May 2012 18:50:06 -0000 This version reflects the comments received from the -05 version from = the WG - thanks for all the comments and we welcome new reviews. Scott On May 1, 2012, at 2:39 PM, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the DNS Extensions Working = Group of the IETF. >=20 > Title : Signaling Cryptographic Algorithm = Understanding in DNSSEC > Author(s) : Steve Crocker > Scott Rose > Filename : draft-ietf-dnsext-dnssec-algo-signal-06.txt > Pages : 8 > Date : 2012-05-01 >=20 > The DNS Security Extensions (DNSSEC) were developed to provide = origin > authentication and integrity protection for DNS data by using = digital > signatures. These digital signatures can be generated using > different algorithms. This draft sets out to specify a way for > validating end-system resolvers to signal to a server which > cryptographic algorithms and hash algorithms they support. >=20 >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-0= 6.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-06= .txt >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/ >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From ajs@anvilwalrusden.com Wed May 2 07:36:04 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 67BDE21F854A; Wed, 2 May 2012 07:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MLClgmh3Ckm; Wed, 2 May 2012 07:36:03 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7AE21F8549; Wed, 2 May 2012 07:36:03 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1D5101ECB41F; Wed, 2 May 2012 14:36:02 +0000 (UTC) Date: Wed, 2 May 2012 10:36:00 -0400 From: Andrew Sullivan To: iesg-secretary@ietf.org, rdroms.ietf@gmail.com Message-ID: <20120502143555.GJ81729@crankycanuck.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="PuGuTyElPB9bOcsM" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsext@ietf.org Subject: [dnsext] Publication request: draft-ietf-dnsext-dnssec-bis-updates 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, 02 May 2012 14:36:04 -0000 --PuGuTyElPB9bOcsM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear Ralph, This is a request for publication of draft-ietf-dnsext-dnssec-bis-updates-18 as a Proposed Standard. The standard write-up is attached. Upon sending this message, I will update the document status in the datatracker. Best regards, A -- Andrew Sullivan ajs@crankycanuck.ca --PuGuTyElPB9bOcsM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="proto_201205-01.txt" PROTO write up for draft-ietf-dnsext-dnssec-bis-updates-18 2012-05-01 Template version 2012-02-24 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The request is for Proposed Standard. The documents it is updating are all at the Proposed Standard level, and this document reflects experience with and clarifications of those. The type is indicated in the header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary DNSSECbis was published in RFC 4033, RFC 4034, and RFC 4035. Since the publication, some people filed errata against those documents, some additional developments added to DNSSECbis, and some implementation experience illustrated ambiguities or issues with the original texts. This draft collects those issues in a single place, updating the DNSSECbis specification and clarifying it where need be. Working Group Summary This draft is the product of the DNS Extensions Working Group. Many of the clarifications came easily. The more contentious parts of the document have been discussed at length. For the most controversial of the clarifications, extensive discussion is included in appendices so that implementers and deployers may make informed decisions. Document Quality Most, if not all, of the document is reflected in the bulk of DNSSECbis validators and signers deployed on the Internet. The document is the result of several years of experience and discussion, collected with an eye to improving implementations. One of the most contentious parts resulted in multiple rounds of discussion and a special design team meeting. The document as it stands has been refined over a long period of time, and is of high quality. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Andrew Sullivan is the Document Shepherd, and Ralph Droms is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd performed multiple complete reviews, and is satisfied the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The WG has a requirement of at least five reviews prior to publication, and this document easily met that. In addition, some of the reviews were from long-standing critics of earlier versions. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Section 5.6 represents a clear change to the protocol. This change is amply documented in practice, but it is nevertheless a change to the protocol. The Shepherd would have preferred something that did not actually change the protocol, but the document editors and a small number of reviewers said they preferred this formulation. The change happened during WGLC. Few people responded to a special request to comment on this issue, so it is not clear how strong the agreement is with this change in the protocol. It is indisputable, however, that some deployed instances work according to the new text, and interoperability is likely maximized by making the change in section 5.6. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. There is an IPR filing against RFC 5155, which this draft updates, but it does not seem to impinge on this draft. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has been through many iterations, a large amount of review, and several rounds of discussion about particular issues. There is one section, 5.9, that continues to be a sore point with one WG participant (the participant is also a notable contributor to an important implementation). Repeated requests during WGLC for expressions of support of that participant's position yielded no results. Section 5.9 was changed after WGLC because a participant (different than the one who objects to section 5.9 overall) said that it did not apply to stub resolvers. On further reflection, the authors reverted the change, because they thought it might be incorrect. Section 5.9 remains the area of most controversy. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are none. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. It will not change the formal status of any, but it does update several. They are all listed. The way that documents are treated together (informally) as the DNSSEC core is also updated, and that is also called out in the document. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no actions for IANA. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.: N/A --PuGuTyElPB9bOcsM-- From d3e3e3@gmail.com Wed May 2 12:49: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 2F86D21E8015 for ; Wed, 2 May 2012 12:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoeU6fiwsfHe for ; Wed, 2 May 2012 12:49:46 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7649A21F84F8 for ; Wed, 2 May 2012 12:49:46 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1287388ghb.31 for ; Wed, 02 May 2012 12:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ueOEF4LRkjL4KVA2FrCvwjBNuML3M5yobGn4O1ZggbA=; b=xw/YxAW6rdMGrH8gtHgfaJaGCtUN6CA7VZU/0c1TK3lToi5tadj9USqR6Mtj5sBw3Y bVAFYZJY1f0Tpv8cHJhkvmAGbS9myTcEr4Yk+Vkv1ckJWJjPLCkwXKqwM8UFd9Fv7ZiQ tPQasejpLOtXIGOlR11gADFNoe6Wl34Zy3PvbzPm3ul8Pc3xiW39I43ryAayArgFh9Of 10J/xJ/BTY8mIwCXUL5+QvyX0Ld/Dxja128FYpYQJStOD4lCBdjqLV9qyXbNqLbEz3zK msSiL3/l579hpCWpA+i14SHtT1NsGsoj61lDtj+bj9VZc20LI5R7UzOEDDpO1wXQroB0 EISw== Received: by 10.42.176.6 with SMTP id bc6mr22349192icb.49.1335988185833; Wed, 02 May 2012 12:49:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Wed, 2 May 2012 12:49:25 -0700 (PDT) In-Reply-To: <201204231837.UAA01660@TR-Sys.de> References: <201204231837.UAA01660@TR-Sys.de> From: Donald Eastlake Date: Wed, 2 May 2012 15:49:25 -0400 Message-ID: To: =?ISO-8859-1?Q?Alfred_H=CEnes?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] rfc6195bis registration template clarification 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, 02 May 2012 19:49:47 -0000 I'm OK with the below suggested change to the appellation template. Thanks, Donald =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 =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Mon, Apr 23, 2012 at 2:37 PM, Alfred H=CEnes wrote: > I tried to figure out whether the rfc1995bis-ixfr draft needs > to undergo the RRtype Expert Review per RFC 6195[bis]. > > It looks like that review only pertains to Data and Meta-RRtypes, > (and the draft -- targeting Standards Track -- needs IETF review), > but the registration policy table for RRtypes (entry for range > 128-255) could be misunderstood to indicate otherwise. > > When looking at the registration template in RFC 6195[bis], > I missed a structured opportunity for the applicant to indicate > whether the application is for a Data RR or Meta-RR, which would > be significant for IANA to select a proper numerical range in the > assignment process. > > So I suggest to amend clause B. of the template in Appendix A of > the rfc6195bis I-D as follows: > > OLD: > > | =A0B. Submission Type: > | =A0 =A0 [ ] New RRTYPE > | =A0 =A0 [ ] Modification to existing RRTYPE > > NEW: > > | =A0B. Submission Type: > | =A0 =A0 [ ] New RRTYPE > | =A0 =A0 [ ] Modification to existing RRTYPE > | > | =A0 =A0 Kind of RRTYPE: > | =A0 =A0 [ ] Data RR > | =A0 =A0 [ ] Meta-RR > > As an alternative, a new numbered item might be inserted; that > would cause the need to renumber the exicsting items, which perhaps > is less desirable for backwards compatibility with RFC 6195. > A third alternative would be using item numbers "B.1." and "B.2.". > > Best regards, > =A0Alfred. > From internet-drafts@ietf.org Wed May 2 15:16: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 6A5C511E80B1; Wed, 2 May 2012 15:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deSEffzzdAaA; Wed, 2 May 2012 15:16:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CAC11E809B; Wed, 2 May 2012 15:16:44 -0700 (PDT) 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.02 Message-ID: <20120502221644.14178.79965.idtracker@ietfa.amsl.com> Date: Wed, 02 May 2012 15:16:44 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-01.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, 02 May 2012 22:16:45 -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 I= ETF. Title : Domain Name System (DNS) IANA Considerations Author(s) : Donald E. Eastlake Filename : draft-ietf-dnsext-rfc6195bis-01.txt Pages : 19 Date : 2012-05-02 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. It obsoletes RFC 6195. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc6195bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc6195bis-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis/ From ogud@ogud.com Thu May 3 11:37: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 84B6F21F84EB for ; Thu, 3 May 2012 11:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAiDohX+2372 for ; Thu, 3 May 2012 11:37:03 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id CA84D21F84DE for ; Thu, 3 May 2012 11:37:02 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q43IaxAq005971; Thu, 3 May 2012 14:36:59 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4FA2D047.1@ogud.com> Date: Thu, 03 May 2012 14:36:55 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Donald Eastlake References: <201204231837.UAA01660@TR-Sys.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= , dnsext@ietf.org Subject: Re: [dnsext] rfc6195bis registration template clarification 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, 03 May 2012 18:37:03 -0000 I'm not, meta types are for DNS software consumption so adding meta types involves processing. Olafur On 02/05/2012 15:49, Donald Eastlake wrote: > I'm OK with the below suggested change to the appellation template. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > On Mon, Apr 23, 2012 at 2:37 PM, Alfred HÎnes wrote: >> I tried to figure out whether the rfc1995bis-ixfr draft needs >> to undergo the RRtype Expert Review per RFC 6195[bis]. >> >> It looks like that review only pertains to Data and Meta-RRtypes, >> (and the draft -- targeting Standards Track -- needs IETF review), >> but the registration policy table for RRtypes (entry for range >> 128-255) could be misunderstood to indicate otherwise. >> >> When looking at the registration template in RFC 6195[bis], >> I missed a structured opportunity for the applicant to indicate >> whether the application is for a Data RR or Meta-RR, which would >> be significant for IANA to select a proper numerical range in the >> assignment process. >> >> So I suggest to amend clause B. of the template in Appendix A of >> the rfc6195bis I-D as follows: >> >> OLD: >> >> | B. Submission Type: >> | [ ] New RRTYPE >> | [ ] Modification to existing RRTYPE >> >> NEW: >> >> | B. Submission Type: >> | [ ] New RRTYPE >> | [ ] Modification to existing RRTYPE >> | >> | Kind of RRTYPE: >> | [ ] Data RR >> | [ ] Meta-RR >> >> As an alternative, a new numbered item might be inserted; that >> would cause the need to renumber the exicsting items, which perhaps >> is less desirable for backwards compatibility with RFC 6195. >> A third alternative would be using item numbers "B.1." and "B.2.". >> >> Best regards, >> Alfred. >> > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > > From d3e3e3@gmail.com Thu May 3 11:42: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 51ABA21F855D for ; Thu, 3 May 2012 11:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.716 X-Spam-Level: X-Spam-Status: No, score=-103.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxr-E-nsuVwj for ; Thu, 3 May 2012 11:42:47 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9577021F8551 for ; Thu, 3 May 2012 11:42:47 -0700 (PDT) Received: by yenq7 with SMTP id q7so2489198yen.31 for ; Thu, 03 May 2012 11:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=GeBbjeEpXH93xUkt6PEJVBGnBQxXDls9vZkShFmGYfM=; b=SRlSJ+vJehd1L9oEZiBafYlgR7n6NahlxSjg7kFRGSQTkujE85M+A1p+VZk4H01KPS KP57ABldnxWcX8+BlT1qFbo74Yd76lzoK+PtE9ZkrDjcCUm6ee9uuHCpW96rQAdIdqKJ ir2wOGuj5mhQpDJ6ve1hD+aIv0aN6ykQypjjlHYt5vmBfkNnLESvR0pBZ2IaQ9n8o7tF Y759O6/N7XvNMsJeG1I1f/nzczf7/ugerOXIkzKp+GbbCG0/eyXCt9munD5djbJPSc6s 5p4fIl7Vef/W+YAUF+EPl2CwtqOSq2BQ+jOfc1/C0Lc38E89Te3TLV2cYRtS90+oHcf1 DV3w== Received: by 10.50.159.164 with SMTP id xd4mr1401188igb.13.1336070567016; Thu, 03 May 2012 11:42:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Thu, 3 May 2012 11:42:26 -0700 (PDT) In-Reply-To: <4FA2D047.1@ogud.com> References: <201204231837.UAA01660@TR-Sys.de> <4FA2D047.1@ogud.com> From: Donald Eastlake Date: Thu, 3 May 2012 14:42:26 -0400 Message-ID: To: Olafur Gudmundsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= , dnsext@ietf.org Subject: Re: [dnsext] rfc6195bis registration template clarification 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, 03 May 2012 18:42:48 -0000 Hi, On Thu, May 3, 2012 at 2:36 PM, Olafur Gudmundsson wrote: > I'm not, meta types are for DNS software consumption so adding meta types > involves processing. RFC 6195 and its previous versions have always allowed ignorable meta RR types to be allocated with expert approval. The only change is to add some check boxes to the template. Thanks, Donald =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 =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > =A0 =A0 =A0 =A0Olafur > > > > On 02/05/2012 15:49, Donald Eastlake wrote: >> >> I'm OK with the below suggested change to the appellation template. >> >> Thanks, >> Donald >> =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 >> =A0Donald E. Eastlake 3rd =A0 +1-508-333-2270 (cell) >> =A0155 Beaver Street, Milford, MA 01757 USA >> =A0d3e3e3@gmail.com >> >> On Mon, Apr 23, 2012 at 2:37 PM, Alfred H=CEnes =A0wrote: >>> >>> I tried to figure out whether the rfc1995bis-ixfr draft needs >>> to undergo the RRtype Expert Review per RFC 6195[bis]. >>> >>> It looks like that review only pertains to Data and Meta-RRtypes, >>> (and the draft -- targeting Standards Track -- needs IETF review), >>> but the registration policy table for RRtypes (entry for range >>> 128-255) could be misunderstood to indicate otherwise. >>> >>> When looking at the registration template in RFC 6195[bis], >>> I missed a structured opportunity for the applicant to indicate >>> whether the application is for a Data RR or Meta-RR, which would >>> be significant for IANA to select a proper numerical range in the >>> assignment process. >>> >>> So I suggest to amend clause B. of the template in Appendix A of >>> the rfc6195bis I-D as follows: >>> >>> OLD: >>> >>> | =A0B. Submission Type: >>> | =A0 =A0 [ ] New RRTYPE >>> | =A0 =A0 [ ] Modification to existing RRTYPE >>> >>> NEW: >>> >>> | =A0B. Submission Type: >>> | =A0 =A0 [ ] New RRTYPE >>> | =A0 =A0 [ ] Modification to existing RRTYPE >>> | >>> | =A0 =A0 Kind of RRTYPE: >>> | =A0 =A0 [ ] Data RR >>> | =A0 =A0 [ ] Meta-RR >>> >>> As an alternative, a new numbered item might be inserted; that >>> would cause the need to renumber the exicsting items, which perhaps >>> is less desirable for backwards compatibility with RFC 6195. >>> A third alternative would be using item numbers "B.1." and "B.2.". >>> >>> Best regards, >>> =A0Alfred. >>> >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >> >> >> > From A.Hoenes@TR-Sys.de Fri May 4 09:01: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 9541021F846F for ; Fri, 4 May 2012 09:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.239 X-Spam-Level: X-Spam-Status: No, score=-98.239 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITM65fKhfvLV for ; Fri, 4 May 2012 09:01:16 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9914621F8452 for ; Fri, 4 May 2012 09:01:15 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA189557187; Fri, 4 May 2012 17:59:47 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA07247; Fri, 4 May 2012 17:59:46 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201205041559.RAA07247@TR-Sys.de> To: d3e3e3@gmail.com Date: Fri, 4 May 2012 17:59:45 +0200 (MESZ) In-Reply-To: from Donald Eastlake at May "3, " 2012 "02:42:26" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-01 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, 04 May 2012 16:01:17 -0000 Donald, I really do appreciate all the efforts you have undertaken on the rfc6195bis draft, in particular the pain to improve the clarity and readability of the tables, which now all look pretty nice and clear. I have once more taken a full proofreading pass over the draft and think we're almost done with it now, so the Chairs might as well announce WGLC now. In that case, the few remarks below should be regarded as early WGLC comments. (1) Small gap in assignment rules Now recently also dealing with the newest rfc3597bis draft, I found a single new topic that preferably should be clarified in the rfc6195bis document before publication: RFC 3597 (and again, rfc3597bis) define the 'synthetic' names to be used in the presentation format as the mnemonics for unknown CLASSes and RRTYPEs. For completeness and to protect against accidents, I suggest that very tiny clauses be added to the draft to indicate that these names must not be assigned by IANA: (1.1) The 4th paragraph of Section 3.1 says: | RRTYPEs have mnemonics that must be completely disjoint from the | mnemonics used for CLASSes and that must match the following regular | expression: | | [A-Z][A-Z0-9\-]*[A-Z0-9] I propose to insert after this snippet the new clause: | Additionally, the 'synthetic' CLASS and RRTYPE names specified in | Section 5 of [RFC3597] cannot be assigned as new RRTYPE mnemonics. Note that the 'synthetic' names also conform to the RE shown, so the present text does not preclude abuse. Using this (arguably unpleasant) indirect specification, room is left for potential future directions of rfc3597bis/ter/... :-) RFC 3597 already is listed as a Normative Reference, so no change in References is needed. (1.2) Similarly, the 4th paragraph of Section 3.2 says: | CLASSes have mnemonics that must be completely disjoint from the | mnemonics used for RRTYPEs and that must match the following regular | expression: | | [A-Z][A-Z0-9\-]*[A-Z0-9] ... and I propose to insert after this snippet the new clause: | Additionally, the 'synthetic' CLASS and RRTYPE names specified in | Section 5 of [RFC3597] cannot be assigned as new CLASS mnemonics. (2) Section 3.1.1 -- visual grouping of rules As mentioned recently on the list, it turned out to be a little hard to locate the processing rules for new RRTYPEs that cannot be treated by the customized Expert Review process described in the draft. I think this could be made better without changing the text, by simply re-grouping the first 2 paragraphs of Section 3.1.1; the first sentence of the current 2nd para logically belongs to the context of the 1st para, as it deals with the Expert Review only, and the 2nd sentence in the 2nd para describes the procedure to be followed when the subsequently listed preconditions for the Expert Review process are not met. So I suggest to pack the 1st sentence to the 1st para and leave the conditional rules alone in the 2nd para. OLD: | Parameter values specified in Section 3.1 above, as assigned based on DNS RRTYPE Allocation Policy, are allocated by Expert Review if they meet the two requirements listed below. There will be a pool of a small number of Experts appointed by the IESG. Each application will be judged by an Expert selected by IANA. In any case where the selected Expert is unavailable or states they have a conflict of | interest, IANA may select another Expert from the pool. | | Some guidelines for the Experts are given in Section 3.1.2. RRTYPEs that do not meet the requirements below may nonetheless be allocated by a Standards Action as modified by [RFC4020]. NEW: | Parameter values specified in Section 3.1 above as assigned based on DNS RRTYPE Allocation Policy, are allocated by Expert Review if they meet the two requirements listed below. There will be a pool of a small number of Experts appointed by the IESG. Each application will be judged by an Expert selected by IANA. In any case where the selected Expert is unavailable or states they have a conflict of | interest, IANA may select another Expert from the pool. Some | guidelines for the Experts are given in Section 3.1.2. | | RRTYPEs that do not meet the requirements below may nonetheless be | allocated by a Standards Action as modified by [RFC4020]. Note that the present comma in the first line seems to be spurious, unnaturally separating "... specified ... above as assigned ..." (3) Remaining nits (3.1) Section 3.1, table heading The heading for the 2nd table column is slightly misaligned; s/Assignment Policy/ Assignment Policy/ (3.2) Section 3.1.4, leading paragraph Please fix the typo: s/as show below/as shown below/ (3.3) Section 3.2, precision in text for 2 table entries In the table in Section 3.2, some descriptions have been clarified/ improved by replacing "assigned" by "available for assignment", but two entries have been missed. I suggest that this be aligned using the improved wording already introduced in other entries. Below, I have shortened the present text at the end to avoid overflow into an additional line.) OLD: 32,768 - 57,343 | 0x8000 - 0xDFFF Assigned for data CLASSes only; Specification | Required for new assignments 57,344 - 65,279 | 0xE000 - 0xFEFF Assigned for QCLASSes and meta-CLASSes only; | Specification Required for new assignments NEW: 32,768 - 57,343 | 0x8000 - 0xDFFF Available for assignment to data CLASSes only; | Specification Required 57,344 - 65,279 | 0xE000 - 0xFEFF Available for assignment to QCLASSes and meta- | CLASSes only; Specification Required Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Fri May 4 11:48: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 75BE421F8555 for ; Fri, 4 May 2012 11:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.259 X-Spam-Level: X-Spam-Status: No, score=-98.259 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Lp9yVgF4Y1H for ; Fri, 4 May 2012 11:48:14 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECFA21F8557 for ; Fri, 4 May 2012 11:48:13 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA190197213; Fri, 4 May 2012 20:46:53 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA07933; Fri, 4 May 2012 20:46:51 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201205041846.UAA07933@TR-Sys.de> To: dnsext@ietf.org Date: Fri, 4 May 2012 20:46:51 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-06 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, 04 May 2012 18:48:14 -0000 With the exception of the minor oversight of repeated occurrences of a single textual flaw pointed out in my WGLC comments, I am satisfied with the revised draft version (-06). Applying the change from "cryptographic and hash algorithms" (or similar) to "digital signature and hash algorithms" twice more (in the Abstract and in Section 8) should not need another draft iteration now -- that can easily be fixed later. So IMHO, the draft now should be ready for publication request to the IESG. Best regards, Alfred. From steve@shinkuro.com Sat May 5 02:06: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 C7F5D21F8564 for ; Sat, 5 May 2012 02:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bac9lu6ft2p4 for ; Sat, 5 May 2012 02:06:34 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 456F321F8567 for ; Sat, 5 May 2012 02:06:34 -0700 (PDT) Received: from [87.213.55.67] (account steve@shinkuro.com HELO [10.196.209.12]) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPSA id 20507275; Sat, 05 May 2012 09:07:26 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Steve Crocker In-Reply-To: <201205041846.UAA07933@TR-Sys.de> Date: Sat, 5 May 2012 11:06:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201205041846.UAA07933@TR-Sys.de> To: =?iso-8859-1?Q?Alfred_H=CEnes?= X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-06 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: Sat, 05 May 2012 09:06:34 -0000 Alfred, Thanks! Steve On May 4, 2012, at 8:46 PM, Alfred H=CEnes wrote: > With the exception of the minor oversight of repeated occurrences > of a single textual flaw pointed out in my WGLC comments, I am > satisfied with the revised draft version (-06). >=20 > Applying the change from "cryptographic and hash algorithms" > (or similar) to "digital signature and hash algorithms" twice more > (in the Abstract and in Section 8) should not need another draft > iteration now -- that can easily be fixed later. >=20 > So IMHO, the draft now should be ready for publication request > to the IESG. >=20 > Best regards, > Alfred. >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From ajs@anvilwalrusden.com Mon May 7 10:53: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 C1E1021F8639 for ; Mon, 7 May 2012 10:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7spU5-Cr0fC for ; Mon, 7 May 2012 10:53:21 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C5E5621F8638 for ; Mon, 7 May 2012 10:53:21 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 188EF1ECB41D for ; Mon, 7 May 2012 17:53:21 +0000 (UTC) Date: Mon, 7 May 2012 13:53:18 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120507175312.GL8963@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] [reed@reedmedia.net: comments on draft-weiler-dnsext-dnssec-bis-updates 18] 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, 07 May 2012 17:53:24 -0000 Forwarded as suggested. I think the draft name is misspelled. A ----- Forwarded message from "Jeremy C. Reed" ----- Date: Mon, 7 May 2012 11:21:20 -0500 (CDT) From: "Jeremy C. Reed" To: ajs@anvilwalrusden.com Subject: comments on draft-weiler-dnsext-dnssec-bis-updates 18 The following are my comments on draft-weiler-dnsext-dnssec-bis-updates-18. You may forward my comments or reply on list as desired. 4.3. Check for CNAME Section 5 of [RFC4035] says little about validating responses based on (or that should be based on) CNAMEs. * The wording above is confusing or misleading. RFC 4035 Section 5 says nothing about CNAME specifically. 5.3. Private Algorithms ... In the remaining cases, the security status of the zone depends on whether or not the resolver supports any of the private algorithms in use (provided that these DS records use supported hash functions, as discussed in Section 5.2). * This may be confusing since the draft's section 5.2 matches up with numbering of RFC 4035's Section 5.2 and the draft's 5.2 does not use the terminology "hash functions". 5.6. Setting the DO Bit on Replies * Mention is is Section 3. 5.7. Setting the AD Bit on Queries The use of the AD bit in the query was previously undefined. * It was defined for queries. See RFC 4035 4.6: ``A security-aware resolver MUST clear the AD bit when composing query messages to protect against buggy name servers that blindly copy header bits that they do not understand from the query message to the response message.'' 6.1. Finding Zone Cuts * What are the "special rules" and "special processing rules"? The wording is unclear if these are the rules defined in RFC 4035 3.1.4.1 or if they are new special rules. In other words, what is the minor correction or clarification here? Appendix B. Discussion of Setting the CD Bit * Maybe mention "(server failure)" in first mention of RCODE=2. * Also be consistent with referring to RFC numbers, maybe always use brackets around them every time. ----- End forwarded message ----- -- Andrew Sullivan ajs@anvilwalrusden.com From matthijs@nlnetlabs.nl Wed May 9 03:53: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 29DB921F85B6 for ; Wed, 9 May 2012 03:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhVnInav3B61 for ; Wed, 9 May 2012 03:53:47 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA12C21F85B5 for ; Wed, 9 May 2012 03:53:46 -0700 (PDT) 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.4/8.14.4) with ESMTP id q49Ari19018020 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 9 May 2012 12:53:45 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1336560826; bh=FAyLDWSVn4THHjbJqb0ahOtc9YqYb6wCkcizGZFDBeo=; h=Date:From:To:Subject:References:In-Reply-To; b=C+RkD+Z8cfT314rnqWyzbRn2tV3/qmxVVvjLVO7ByIP4BboEuChvhzoQvP+FJuelp 5foS2rDe1/df7qa8VSJndXAlKaHUBMgvyPQ+mVBbVfacogSWdCxLqY/wvKlfL8A2gB gs5vBxSxkMwadLMnwwUFO3Z6YXdhpqXFG1h3cxkY= Message-ID: <4FAA4CB8.4010505@nlnetlabs.nl> Date: Wed, 09 May 2012 12:53:44 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <201205041846.UAA07933@TR-Sys.de> In-Reply-To: <201205041846.UAA07933@TR-Sys.de> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 09 May 2012 12:53:45 +0200 (CEST) Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-06 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, 09 May 2012 10:53:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I agree with Alfred. I have the following nit comments that can also be easily fixed later (see below). Best regards, Matthijs Nits: Section 1 (Introduction): v "These algorithm codes tells..." -> "These algorithm codes tell..." v v "Likewise, Delegation Signer (DS) RR's and NSEC3 RR's use..." -> "Likewise, Delegation Signer (DS) RRs and NSEC3 RRs use..." vv "deployment of code that implements a newly deployed digital signature algorithm, DS hash and NSEC3 hash algorithm used..." -> ^ ^ "deployment of code that implements newly deployed digital signature algorithms, DS hash and NSEC3 hash algorithms used..." vvvvvvvvvvvvvv "A zone administrator may be able to determine..." -> "A zone administrator is able to determine..." or "A zone administrator may determine..." Section 2: vv "The ENDS0 specification..." -> "The EDNS0 specification..." v "take up 22-34 octets..." -> "take up 22-32 octets..." On 05/04/2012 08:46 PM, Alfred � wrote: > With the exception of the minor oversight of repeated occurrences > of a single textual flaw pointed out in my WGLC comments, I am > satisfied with the revised draft version (-06). > > Applying the change from "cryptographic and hash algorithms" (or > similar) to "digital signature and hash algorithms" twice more (in > the Abstract and in Section 8) should not need another draft > iteration now -- that can easily be fixed later. > > So IMHO, the draft now should be ready for publication request to > the IESG. > > Best regards, Alfred. > > _______________________________________________ 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 Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPqky4AAoJEA8yVCPsQCW529AH+wf5BgbpwwHS7F462xKj4rXI Y2rgGcdA5GUY9VL5WrQaENZajC8m7v6Z2dFcfQIVOx55MlBtjfB5vrEwCmE6F5J2 zdTaoSFhmsqp8Ub7VEpuMldByj/zTIc5OjxMZSIkmZX0+A5qYqO4UswUPONYt05d /szjzMA/zDN9GFj9DtghmBLTUSN4Yy6U8VrLK8lExS000AUp59tImzB7wVYq1Rfs b4vjJ2GvoHEou6nMymx1bmVfnn5RDoBJWWQO18PVhy/GtBi7lkexuLvFWLBTxIK9 e8QgbB/TJRS6hKlahqS0qbH8QRnFI53IaSCFzK5Xx9/E4cMjkUF3pSoL+t1XhLQ= =ybs3 -----END PGP SIGNATURE----- From wwwrun@rfc-editor.org Wed May 9 14:47:19 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 F2CE211E80D0 for ; Wed, 9 May 2012 14:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2C3tdNguTRU for ; Wed, 9 May 2012 14:47:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 891F511E80CF for ; Wed, 9 May 2012 14:47:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0ED1862180; Wed, 9 May 2012 14:45:00 -0700 (PDT) To: rdroms.ietf@gmail.com, brian@innovationslab.net, ogud@ogud.com, ajs@anvilwalrusden.com From: RFC Errata System Message-Id: <20120509214500.0ED1862180@rfc-editor.org> Date: Wed, 9 May 2012 14:45:00 -0700 (PDT) Cc: dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] [Technical Errata Reported] RFC3363 (3220) 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, 09 May 2012 21:47:19 -0000 The following errata report has been submitted for RFC3363, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3363&eid=3220 -------------------------------------- Type: Technical Reported by: Mark Andrews Section: 4 Original Text ------------- 4. DNAME in IPv6 Reverse Tree The issues for DNAME in the reverse mapping tree appears to be closely tied to the need to use fragmented A6 in the main tree: if one is necessary, so is the other, and if one isn't necessary, the other isn't either. Therefore, in moving RFC 2874 to experimental, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated. Corrected Text -------------- 4. DNAME in IPv6 Reverse Tree [Deleted due to faulty premise.] Notes ----- The opening premise of this section is demonstrably wrong, and so the conclusion based on that premise is wrong. The use of DNAME in the reverse tree is and always has been independent of A6. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3363 (draft-ietf-dnsext-ipv6-addresses-02) -------------------------------------- Title : Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) Publication Date : August 2002 Author(s) : R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain Category : INFORMATIONAL Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From cet1@hermes.cam.ac.uk Wed May 9 15:15: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 D77E821F8440 for ; Wed, 9 May 2012 15:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAiOL0RAosXG for ; Wed, 9 May 2012 15:15:28 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id F360921F843F for ; Wed, 9 May 2012 15:15:27 -0700 (PDT) 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-2.csi.cam.ac.uk ([131.111.8.54]:40246) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:cet1) id 1SSFAI-0007Zf-rL (Exim 4.72) (return-path ); Wed, 09 May 2012 23:15:22 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1SSFAI-0003OW-Gu (Exim 4.67) (return-path ); Wed, 09 May 2012 23:15:22 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.4); 09 May 2012 23:15:22 +0100 Date: 09 May 2012 23:15:22 +0100 From: Chris Thompson To: RFC Errata System Message-ID: In-Reply-To: <20120509214500.0ED1862180@rfc-editor.org> References: <20120509214500.0ED1862180@rfc-editor.org> X-Mailer: Prayer v1.3.4 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: brian@innovationslab.net, rdroms.ietf@gmail.com, ogud@ogud.com, dnsext@ietf.org Subject: Re: [dnsext] [Technical Errata Reported] RFC3363 (3220) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 22:15:29 -0000 On May 9 2012, RFC Errata System wrote: >The following errata report has been submitted for RFC3363, >"Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=3363&eid=3220 > >-------------------------------------- >Type: Technical >Reported by: Mark Andrews > >Section: 4 > >Original Text >------------- >4. DNAME in IPv6 Reverse Tree > > The issues for DNAME in the reverse mapping tree appears to be > closely tied to the need to use fragmented A6 in the main tree: if > one is necessary, so is the other, and if one isn't necessary, the > other isn't either. Therefore, in moving RFC 2874 to experimental, > the intent of this document is that use of DNAME RRs in the reverse > tree be deprecated. > > >Corrected Text >-------------- >4. DNAME in IPv6 Reverse Tree > >[Deleted due to faulty premise.] > >Notes >----- >The opening premise of this section is demonstrably wrong, and so the conclusion based on that premise is wrong. The use of DNAME in the reverse tree is and always has been independent of A6. > >Instructions: >------------- >This errata is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC3363 (draft-ietf-dnsext-ipv6-addresses-02) >-------------------------------------- >Title : Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) >Publication Date : August 2002 >Author(s) : R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain >Category : INFORMATIONAL >Source : DNS Extensions >Area : Internet >Stream : IETF >Verifying Party : IESG >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext I don't really know whether this is technically an erratum, but it was a quite unnecessary and unjustified side-swipe at DNAME. As it happens, our primary use of DNAME is in the IPv4 reverse tree rather than the IPv6 one (the wording in RFC 3363 is slithery in at least half- implying that ought to be deprecated as well), because its primary use (or that of CNAME, for that matter) is consolidation, and at this time IPv4 space is much more fragmented. -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From brian@innovationslab.net Thu May 10 05:50:40 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 7376121F86A0 for ; Thu, 10 May 2012 05:50:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywGKVlQnlXT1 for ; Thu, 10 May 2012 05:50:39 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id D596821F869A for ; Thu, 10 May 2012 05:50:39 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id BB3AC88183; Thu, 10 May 2012 05:50:39 -0700 (PDT) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1B346140039; Thu, 10 May 2012 05:50:39 -0700 (PDT) Message-ID: <4FABB9A0.6050307@innovationslab.net> Date: Thu, 10 May 2012 08:50:40 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: cet1@cam.ac.uk References: <20120509214500.0ED1862180@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 10 May 2012 06:27:53 -0700 Cc: "rfc-editor@rfc-editor.org >> RFC Errata System" , rdroms.ietf@gmail.com, ogud@ogud.com, dnsext@ietf.org Subject: Re: [dnsext] [Technical Errata Reported] RFC3363 (3220) 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, 10 May 2012 12:50:40 -0000 Chris, This errata report came out of the processing of draft-ietf-dnsext-rfc2672bis-dname. That draft contains text in section 4 that states: The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME. The opening premise of this section is demonstrably wrong, and so the conclusion based on that premise is wrong. The RFC Editor asked if there should be an errata report filed to clean up RFC 3363. Regards, Brian On 5/9/12 6:15 PM, Chris Thompson wrote: > On May 9 2012, RFC Errata System wrote: > >> The following errata report has been submitted for RFC3363, >> "Representing Internet Protocol version 6 (IPv6) Addresses in the >> Domain Name System (DNS)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3363&eid=3220 >> >> -------------------------------------- >> Type: Technical >> Reported by: Mark Andrews >> >> Section: 4 >> >> Original Text >> ------------- >> 4. DNAME in IPv6 Reverse Tree >> >> The issues for DNAME in the reverse mapping tree appears to be >> closely tied to the need to use fragmented A6 in the main tree: if >> one is necessary, so is the other, and if one isn't necessary, the >> other isn't either. Therefore, in moving RFC 2874 to experimental, >> the intent of this document is that use of DNAME RRs in the reverse >> tree be deprecated. >> >> >> Corrected Text >> -------------- >> 4. DNAME in IPv6 Reverse Tree >> >> [Deleted due to faulty premise.] >> >> Notes >> ----- >> The opening premise of this section is demonstrably wrong, and so the >> conclusion based on that premise is wrong. The use of DNAME in the >> reverse tree is and always has been independent of A6. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> -------------------------------------- >> RFC3363 (draft-ietf-dnsext-ipv6-addresses-02) >> -------------------------------------- >> Title : Representing Internet Protocol version 6 (IPv6) Addresses in >> the Domain Name System (DNS) >> Publication Date : August 2002 >> Author(s) : R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain >> Category : INFORMATIONAL >> Source : DNS Extensions >> Area : Internet >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > > I don't really know whether this is technically an erratum, but it was a > quite unnecessary and unjustified side-swipe at DNAME. > > As it happens, our primary use of DNAME is in the IPv4 reverse tree rather > than the IPv6 one (the wording in RFC 3363 is slithery in at least half- > implying that ought to be deprecated as well), because its primary use > (or that of CNAME, for that matter) is consolidation, and at this time > IPv4 space is much more fragmented. > From iesg-secretary@ietf.org Thu May 17 14:01:23 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 2C96021F87A5; Thu, 17 May 2012 14:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt-7YQC2JxXJ; Thu, 17 May 2012 14:01:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8626721F8792; Thu, 17 May 2012 14:01:22 -0700 (PDT) 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.02 Message-ID: <20120517210122.19283.4263.idtracker@ietfa.amsl.com> Date: Thu, 17 May 2012 14:01:22 -0700 Cc: dnsext@ietf.org Subject: [dnsext] Last Call: (Clarifications and Implementation Notes for DNSSECbis) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 21:01:23 -0000 The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Clarifications and Implementation Notes for DNSSECbis' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-05-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata. This document updates the core DNSSECbis documents (RFC4033, RFC4034, and RFC4035) as well as the NSEC3 specification (RFC5155). It also defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-bis-updates/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-bis-updates/ballot/ No IPR declarations have been submitted directly on this I-D. From weiler@watson.org Fri May 18 04:56: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 0A34D21F869D for ; Fri, 18 May 2012 04:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMHrrAOhDw3f for ; Fri, 18 May 2012 04:56:55 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5628121F8686 for ; Fri, 18 May 2012 04:56:54 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q4IBursE085591; Fri, 18 May 2012 07:56:53 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q4IBuq7a085588; Fri, 18 May 2012 07:56:53 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 18 May 2012 07:56:52 -0400 (EDT) From: Samuel Weiler To: "Jeremy C. Reed" In-Reply-To: <20120507175312.GL8963@mail.yitter.info> Message-ID: References: <20120507175312.GL8963@mail.yitter.info> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 18 May 2012 07:56:53 -0400 (EDT) Cc: dnsext@ietf.org Subject: Re: [dnsext] [reed@reedmedia.net: comments on draft-weiler-dnsext-dnssec-bis-updates 18] 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, 18 May 2012 11:56:56 -0000 Thank you for these comments. I've proposed some textual changes to address these. Assuming there's not objection, these will be pushed out after the IETF LC ends. > 4.3. Check for CNAME > > Section 5 of [RFC4035] says little about validating responses based > on (or that should be based on) CNAMEs. > > * The wording above is confusing or misleading. RFC 4035 Section 5 says > nothing about CNAME specifically. Good catch. I propose changing to "...says nothing explicit about validating responses based on ..." > 5.3. Private Algorithms > > ... > > In the remaining cases, the security status of the zone depends on > whether or not the resolver supports any of the private algorithms in > use (provided that these DS records use supported hash functions, as > discussed in Section 5.2). > > * This may be confusing since the draft's section 5.2 matches up with > numbering of RFC 4035's Section 5.2 and the draft's 5.2 does not use the > terminology "hash functions". I propose: "(provided that these DS records use supported message digest algorithms, as discussed in Section 5.2 of this document)". > 5.6. Setting the DO Bit on Replies > > * Mention is is Section 3. Done. > 5.7. Setting the AD Bit on Queries > > The use of the AD bit in the query was previously undefined. > > * It was defined for queries. See RFC 4035 4.6: ``A security-aware > resolver MUST clear the AD bit when composing query messages to protect > against buggy name servers that blindly copy header bits that they do > not understand from the query message to the response message.'' What to do with it was defined, but there was no "use" for it. Even so, this is a little unclear. I propose: The semantics of the AD bit in the query were previously undefined. Section 4.6 of RFC4035 instructed resolvers to always clear the AD bit when composing queries. This document defines setting the AD bit in a query... > 6.1. Finding Zone Cuts > > * What are the "special rules" and "special processing rules"? The > wording is unclear if these are the rules defined in RFC 4035 3.1.4.1 or > if they are new special rules. In other words, what is the minor > correction or clarification here? There isn't one. This is just restating something that should be obvious. I don't even remember what inspired including this section -- it dates from the pre-WG draft, which started over seven(!) years ago. It might be better to just take this out. For the moment, I propose trimming the section to: Appendix C.8 of RFC4035 discusses sending DS queries to the servers for a parent zone but doesn't say how to find those servers. Specific instructions can be found in Section 4.2 of RFC4035. > Appendix B. Discussion of Setting the CD Bit > > * Maybe mention "(server failure)" in first mention of RCODE=2. Done. > * Also be consistent with referring to RFC numbers, maybe always use > brackets around them every time. I changed the 4035 reference at the top of Appendix B. I'll try to look for others later. -- Sam From marka@isc.org Sun May 20 16:00:25 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 A1D6621F85AF; Sun, 20 May 2012 16:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJiqViHhWn7n; Sun, 20 May 2012 16:00:25 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id E8A4221F8597; Sun, 20 May 2012 16:00:24 -0700 (PDT) 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 id C7453C95AA; Sun, 20 May 2012 23:00:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:f9c1:59cf:bb40:d253]) (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 67889216C36; Sun, 20 May 2012 23:00:12 +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 1E51A20C6C42; Mon, 21 May 2012 09:00:08 +1000 (EST) To: ietf@ietf.org From: Mark Andrews References: <20120517210122.19283.4263.idtracker@ietfa.amsl.com> In-reply-to: Your message of "Thu, 17 May 2012 14:01:22 MST." <20120517210122.19283.4263.idtracker@ietfa.amsl.com> Date: Mon, 21 May 2012 09:00:07 +1000 Message-Id: <20120520230008.1E51A20C6C42@drugs.dv.isc.org> Cc: dnsext@ietf.org, IETF-Announce Subject: Re: [dnsext] Last Call: (Clarifications and Implementation Notes for DNSSECbis) to Proposed Standard 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: Sun, 20 May 2012 23:00:25 -0000 I am repeating what I have said earlier during WGLS that Section 5.9., Always set the CD bit on Queries, contains bad advice on how to set the CD bit. The setting of CD make little difference if all the machines involved are being correctly managed. In that case all responses will successfully validate. However if there is a off path attacker or one or more of the authorititive sources is returning stale records the setting of CD is critical to ensuring that the ultimate client can get the necessary records to ensure that the responses it gets validate. When there is a non-validating stub resolver all queries from that client come in with CD=0 and a validating recursive server try multiple authoritative servers until it gets a answer which validates as secure or insecure, in other words it rejects answers from attackers or from authoritative servers that return stale data. Now take a validating validating stub resolver, if all queries from that client come in the CD=1, them the recursive server returns the answer from upstream immediately without filtering out bad responses. If there is a off path attacker or if there is a stale authoritative server then there is no way to ensure that the stub client will ever get a answer that will validate. It can continue to re-query forever but there is no requirement for the recursive server to try a different authoritative source or to wait for a valid response from a authoritive source. A similar problem arises when a recursive server is talking through a second recursive server. The server is no longer talking to the authoritative servers directly and can't recover from getting answers that do not validate. Now sending CD=0 has its own set of problems caused by stale trust anchors and clocks being out of sync so I am not suggesting that we always send CD=0 queries either when incoming queries are sent with CD=0. Stub resolvers and recursive servers talking through other recursive servers need to be prepared to ask queries with both CD=0 and CD=1. CD=1 when talking to authoritative servers, CD=0 when talking to recursive servers falling back to CD=1 on SERVFAIL to handle stale trust anchors and out of sync clocks unless the incoming query was received with CD=1 in which case you MUST make CD=1 upstream queries. Now if the recursive server is not validating, validating down stream clients are vulnerable to all the failure modes caused by sending CD=1 queries. Fixing this will require protocol extensions to pass trust anchors, and maybe current time, along with the query and having on demand validation performed using those values in the recursive server for this client. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sm@elandsys.com Tue May 22 10:21: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 2064F21F8648; Tue, 22 May 2012 10:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kyvew0gWwZwr; Tue, 22 May 2012 10:20:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9807121F85DF; Tue, 22 May 2012 10:20:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.13]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4MHKfiB009175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 May 2012 10:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1337707254; i=@elandsys.com; bh=Qy9ZysTWWnHpJq6cOkxlM9R5qxg+qzsUDxNMEvMTSFY=; h=Date:To:From:Subject:Cc; b=oqhT2d2Rpfg+1nPEZRP7K0RvNlWF1rOX2yKuCT0oBN2mw/3PjATzR6wikdeCeXGSe n7G9PClL6OdvAhqUnLMBRsb3PRWYHfz5e+XFhbwwhgDPn2RYatT25QIbz1bd6WCLdT 3UlP7KfBMo2yqbJqk7YzF2twQfQMbg2ktxwhe8kk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1337707254; i=@elandsys.com; bh=Qy9ZysTWWnHpJq6cOkxlM9R5qxg+qzsUDxNMEvMTSFY=; h=Date:To:From:Subject:Cc; b=aQhoNtPHD+ccuNBWu0ZLkh7I7LEV4v9Dzg0nVIGuPV6GFmUR1xq57Y49S6tTJDnKk H+vaXjgH1Cl8L0qmpxJaUURw9G1W9m27Ax87JXR5wRoCsWlMf7/AbeiKPM26ecs08o VWNP3I9fl5UOMO5ZhuExtikNuyTGyPpfcKyr8xpw= Message-Id: <6.2.5.6.2.20120522092115.0900a4a0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 22 May 2012 10:12:27 -0700 To: apps-discuss@ietf.org, draft-ietf-dnsext-dnssec-bis-updates.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Tue, 22 May 2012 10:24:19 -0700 Cc: dnsext@ietf.org, iesg@ietf.org Subject: [dnsext] APPSDIR review of draft-ietf-dnsext-dnssec-bis-updates-18 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, 22 May 2012 17:21:00 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on AppsDir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). The comments in this review do not bear more weight than comments submitted by an individual during a Last Call. It is suggested that the author asks the document shepherd for guidance about any changes suggested in a review. Document: draft-ietf-dnsext-dnssec-bis-updates-18 Title: Clarifications and Implementation Notes for DNSSECbis Reviewer: S. Moonesamy Review Date: May 22, 2012 IETF Last Call Date: May 17, 2012 Summary: This document is not ready for publication as a Proposed Standard. The proposal is a collection of technical clarifications to the DNSSECbis document set. DNSSEC is useful for application-related specifications which perform service location. The proposal does not directly affect any application-related specification. The proposal seems targeted at implementers who are fully conversant with the ins and outs of DNSSEC. Although the proposal is well-written, it lacks clarity as to what is being changed in the "DNSSECbis document set". It may end up being more confusing. There was an announcement that the DNSEXT WG would be shut down. The rush to publish these clarifications raises questions about whether the DNSSECbis documents will ever be advanced in the near future from Proposed Standard to Internet Standard. I erred on the side of caution in making the publication recommendation especially as the Security Considerations Section mentions that the validation algorithm clarifications in Section 4 are critical for preserving the security properties DNSSEC offers. Minor issues: In the Abstract Section: "This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata." "DNSSECbis" seems more like an internal IETF term to identify the document set. RFC 4033, for example, does not have any mention of "DNSSECbis". I suggest using "DNSSEC protocol document set" and amending the title accordingly. In the Introduction Section: "This document lists some additions, clarifications and corrections to the core DNSSECbis specification". See above comment. In Section 2.1: "Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3- SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512) signal that a zone MAY be using NSEC3, rather than NSEC. The zone MAY be using either and validators supporting these algorithms MUST support both NSEC3 and NSEC responses." It is not clear from the above text which parts of RFC 5155 is being modified. In Section 3.1: "Section 4.7 of RFC4035 permits security-aware resolvers to implement a BAD cache. Because of scaling concerns not discussed in this document, that guidance has changed: security-aware resolvers SHOULD implement a BAD cache as described in RFC4035." From Section 4.7 of RFC 4035: "To prevent such unnecessary DNS traffic, security-aware resolvers MAY cache data with invalid signatures, with some restrictions." If I understood the text from this draft, the "MAY" is being changed into a recommendation. In which cases would it better not to follow the recommendation? In Section 4.1: "In particular, the algorithm as presented would incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove the non-existence of RRs in the child zone." Where is ancestor zone defined? "Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non- existence of any RRs below that zone cut, which include all RRs at that (original) owner name other than DS RRs, and all RRs below that owner name regardless of type." It is not clear what is being clarified. Nits: In the Introduction Section: The IETF is now using two maturity levels. "Draft Standard" has been changed to "Internet Standard" In Section 6.3: This section discusses about errors in the examples in RFC 4035. As a stylistic comment, it is clearer to the reader if he/she could see the actual examples with the corrections made. Regards, S. Moonesamy From rbarnes@bbn.com Fri May 25 15:04:15 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 DC6AF21F8822 for ; Fri, 25 May 2012 15:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-pVtuQXADlM for ; Fri, 25 May 2012 15:04:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3536221F8820 for ; Fri, 25 May 2012 15:04:15 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:56794) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SY2bo-000601-7x for dnsext@ietf.org; Fri, 25 May 2012 18:03:44 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 May 2012 18:04:14 -0400 References: To: dnsext@ietf.org Message-Id: <6A06CD40-37F9-482A-8DED-53EA9ED3E3FE@bbn.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [dnsext] Fwd: Gen-ART review of draft-ietf-dnsext-dnssec-bis-updates-18 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, 25 May 2012 22:04:16 -0000 Paul suggested I forward this to the WG. --Richard Begin forwarded message: > From: "Richard L. Barnes" > Subject: Gen-ART review of draft-ietf-dnsext-dnssec-bis-updates-18 > Date: May 25, 2012 5:02:28 PM EDT > To: IESG , ietf@ietf.org > Cc: draft-ietf-dnsext-dnssec-bis-updates@tools.ietf.org >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-dnsext-dnssec-bis-updates-18 > Reviewer: Richard Barnes > Review Date: May-25-2012 > IETF LC End Date: Not known > IESG Telechat date: Jan-05-2012 >=20 > Summary: Almost ready, couple of questions >=20 > MAJOR: >=20 > 4.1. > It's not clear what the threat model is that this section is designed = to address. If the zone operator is malicious, then it can simulate the = necessary zone cut and still prove the non-existence of records in the = child zone. =20 >=20 > 5.10. > I find the recommendation of the "Accept Any Success" policy = troubling. It deals very poorly with compromise (and other roll-over = scenarios): Suppose there are two trust anchors, one for example.com and = one for child.example.com. If the private key corresponding to the TA = for child.example.com is compromised, but the validator continues to = trust it, this negates the benefit provided by the parent (example.com) = facilitating a rollover. Suggest an alternative policy, "Highest = Signer": Out of the set of keys configured as TAs, the validator only = uses a key as a TA (for purposes of validation) if there does not exist = a DNSSEC path from it to any other TA. This policy seems like more work = to enforce (because you have to do more backward chaining), but ISTM = that the validator should have the necessary DNSSEC records anyway, so = it's just a matter a couple of quick checks. >=20 >=20 >=20 From d3e3e3@gmail.com Mon May 28 11:03:35 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 A869F21F8698 for ; Mon, 28 May 2012 11:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.139 X-Spam-Level: X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAjtw3xWFJC3 for ; Mon, 28 May 2012 11:03:34 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B264921F8697 for ; Mon, 28 May 2012 11:03:34 -0700 (PDT) Received: by yhq56 with SMTP id 56so2101311yhq.31 for ; Mon, 28 May 2012 11:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=P9+FW1R3p+apbHNJDWdF165xOqVwP++/uCy/Y+lsXVc=; b=gGmNQbp986m57fnW1BMwdTA7aKD7tin4/DZP1ueMft4NTGuYQfqI5qwoTqSY9rOcjZ ZauY/lOUzHzzql4Pv8L9SO8gaIUIRVUPL0RuDIhEVnfN1ozQIPsVfcW+Chj1R3pa6S4O pqH8f7/COF0BuBkWTPZQGWHZK+brAqGLvRn8xB0EcFWWZwjDfg4rRFirU9hC+hH2YkqL mp8VjxiDWe4D/J38yXx6sITT8DqgMvG5Rs8vANXBDAqWvofHnmGHugLJFnPH6tbBCQLf UU2VuF6Cd3U8DyKDPT3rCCzTtNr3GygUu89befjuoyTl0Q0OgbumrxchfFOWuXhgHG8r iv4w== Received: by 10.42.89.72 with SMTP id f8mr4820015icm.33.1338228213974; Mon, 28 May 2012 11:03:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Mon, 28 May 2012 11:03:13 -0700 (PDT) In-Reply-To: <201205041559.RAA07247@TR-Sys.de> References: <201205041559.RAA07247@TR-Sys.de> From: Donald Eastlake Date: Mon, 28 May 2012 14:03:13 -0400 Message-ID: To: =?ISO-8859-1?Q?Alfred_H=CEnes?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-01 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, 28 May 2012 18:03:35 -0000 Hi Alfred, There have been no objections to your suggested changes so I will go ahead, make them, and post revised version. Thanks, Donald =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 =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Fri, May 4, 2012 at 11:59 AM, Alfred H=CEnes wrote: > Donald, > > I really do appreciate all the efforts you have undertaken on the > rfc6195bis draft, in particular the pain to improve the clarity and > readability of the tables, which now all look pretty nice and clear. > > I have once more taken a full proofreading pass over the draft and > think we're almost done with it now, so the Chairs might as well > announce WGLC now. > In that case, the few remarks below should be regarded as early WGLC > comments. > > > (1) =A0Small gap in assignment rules > > Now recently also dealing with the newest rfc3597bis draft, > I found a single new topic that preferably should be clarified > in the rfc6195bis document before publication: > > RFC 3597 (and again, rfc3597bis) define the 'synthetic' names > to be used in the presentation format as the mnemonics for > unknown CLASSes and RRTYPEs. > For completeness and to protect against accidents, I suggest that > very tiny clauses be added to the draft to indicate that these > names must not be assigned by IANA: > > (1.1) > > The 4th paragraph of Section 3.1 says: > > | =A0RRTYPEs have mnemonics that must be completely disjoint from the > | =A0mnemonics used for CLASSes and that must match the following regular > | =A0expression: > | > | =A0 =A0 =A0 =A0[A-Z][A-Z0-9\-]*[A-Z0-9] > > I propose to insert after this snippet the new clause: > > | =A0Additionally, the 'synthetic' CLASS and RRTYPE names specified in > | =A0Section 5 of [RFC3597] cannot be assigned as new RRTYPE mnemonics. > > Note that the 'synthetic' names also conform to the RE shown, so the > present text does not preclude abuse. > > Using this (arguably unpleasant) indirect specification, room is > left for potential future directions of rfc3597bis/ter/... =A0:-) > > RFC 3597 already is listed as a Normative Reference, so no change > in References is needed. > > (1.2) > > Similarly, the 4th paragraph of Section 3.2 says: > > | =A0CLASSes have mnemonics that must be completely disjoint from the > | =A0mnemonics used for RRTYPEs and that must match the following regular > | =A0expression: > | > | =A0 =A0 =A0 =A0[A-Z][A-Z0-9\-]*[A-Z0-9] > > ... and I propose to insert after this snippet the new clause: > > | =A0Additionally, the 'synthetic' CLASS and RRTYPE names specified in > | =A0Section 5 of [RFC3597] cannot be assigned as new CLASS mnemonics. > > > (2) =A0Section 3.1.1 -- visual grouping of rules > > As mentioned recently on the list, it turned out to be a little hard > to locate the processing rules for new RRTYPEs that cannot be treated > by the customized Expert Review process described in the draft. > > I think this could be made better without changing the text, by > simply re-grouping the first 2 paragraphs of Section 3.1.1; the first > sentence of the current 2nd para logically belongs to the context > of the 1st para, as it deals with the Expert Review only, and the > 2nd sentence in the 2nd para describes the procedure to be followed > when the subsequently listed preconditions for the Expert Review > process are not met. =A0So I suggest to pack the 1st sentence to the > 1st para and leave the conditional rules alone in the 2nd para. > > OLD: > > | =A0Parameter values specified in Section 3.1 above, as assigned based o= n > =A0 DNS RRTYPE Allocation Policy, are allocated by Expert Review if they > =A0 meet the two requirements listed below. There will be a pool of a > =A0 small number of Experts appointed by the IESG. Each application will > =A0 be judged by an Expert selected by IANA. In any case where the > =A0 selected Expert is unavailable or states they have a conflict of > | =A0interest, IANA may select another Expert from the pool. > | > | =A0Some guidelines for the Experts are given in Section 3.1.2. RRTYPEs > =A0 that do not meet the requirements below may nonetheless be allocated > =A0 by a Standards Action as modified by [RFC4020]. > > NEW: > > | =A0Parameter values specified in Section 3.1 above as assigned based on > =A0 DNS RRTYPE Allocation Policy, are allocated by Expert Review if they > =A0 meet the two requirements listed below. There will be a pool of a > =A0 small number of Experts appointed by the IESG. Each application will > =A0 be judged by an Expert selected by IANA. In any case where the > =A0 selected Expert is unavailable or states they have a conflict of > | =A0interest, IANA may select another Expert from the pool. =A0Some > | =A0guidelines for the Experts are given in Section 3.1.2. > | > | =A0RRTYPEs that do not meet the requirements below may nonetheless be > | =A0allocated by a Standards Action as modified by [RFC4020]. > > Note that the present comma in the first line seems to be spurious, > unnaturally separating =A0 "... specified ... above as assigned ..." > > > (3) =A0Remaining nits > > (3.1) =A0Section 3.1, table heading > > The heading for the 2nd table column is slightly misaligned; > =A0 s/Assignment Policy/ =A0Assignment Policy/ > > (3.2) =A0Section 3.1.4, leading paragraph > > Please fix the typo: =A0s/as show below/as shown below/ > > (3.3) =A0Section 3.2, precision in text for 2 table entries > > In the table in Section 3.2, some descriptions have been clarified/ > improved by replacing "assigned" by "available for assignment", > but two entries have been missed. =A0I suggest that this be aligned > using the improved wording already introduced in other entries. > Below, I have shortened the present text at the end to avoid > overflow into an additional line.) > > OLD: > > =A0 32,768 - 57,343 > | =A00x8000 - 0xDFFF =A0 Assigned for data CLASSes only; Specification > | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Required for new assignments > > =A0 57,344 - 65,279 > | =A00xE000 - 0xFEFF =A0 Assigned for QCLASSes and meta-CLASSes only; > | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Specification Required for new a= ssignments > > NEW: > > =A0 32,768 - 57,343 > | =A00x8000 - 0xDFFF =A0 Available for assignment to data CLASSes only; > | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Specification Required > > =A0 57,344 - 65,279 > | =A00xE000 - 0xFEFF =A0 Available for assignment to QCLASSes and meta- > | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CLASSes only; Specification Requ= ired > > > Kind regards, > =A0Alfred. > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes =A0 | =A0Alfred Hoenes =A0 Dipl.-Math., Dipl.-Phys= . =A0| > | Gerlinger Strasse 12 =A0 | =A0Phone: (+49)7156/9635-0, Fax: -18 =A0 =A0= =A0 =A0 | > | D-71254 =A0Ditzingen =A0 =A0 | =A0E-Mail: =A0ah@TR-Sys.de =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > +------------------------+--------------------------------------------+ > From marc.lampo@eurid.eu Wed May 30 04:31: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 7E80621F8687 for ; Wed, 30 May 2012 04:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGZVS12-sUIX for ; Wed, 30 May 2012 04:31:13 -0700 (PDT) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id D5B4A21F8659 for ; Wed, 30 May 2012 04:31:12 -0700 (PDT) X-ASG-Debug-ID: 1338377464-0369496fa65d500001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id C7gYbhJCSUBdctUj for ; Wed, 30 May 2012 13:31:04 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 0C171E408B for ; Wed, 30 May 2012 13:31:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dahbaG3SKFQW for ; Wed, 30 May 2012 13:31:03 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id EF658E4050 for ; Wed, 30 May 2012 13:31:03 +0200 (CEST) From: "Marc Lampo" To: Date: Wed, 30 May 2012 13:31:03 +0200 (CEST) X-ASG-Orig-Subj: rfc4035 & 5155 : order of RR's ? Message-ID: <004d01cd3e57$b230ec80$1692c580$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0+V7HIfS/+l479Tg+CrtMiiebs7Q== Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.1.121] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1338377464 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: [dnsext] rfc4035 & 5155 : order of RR's ? 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, 30 May 2012 11:31:13 -0000 Hello, A stupid question, perhaps, but ... Both RFC4035 and RFC5155 talk in more or less global terms on adding DNSSEC RR's to the reply (answer/authority/addition sections). As an example of "global" term, a quote from RFC5155, section 7.2.3 : "The server MUST include the NSEC3 RR that matches QNAME." In RFC4035, section 3.1, the text states : "... must include additional RRSIG, NSEC, ... RRs, ..." (this is a paragraph of serving a DNSSEC'd zone, so I interpret "must include" as : must add them to the response) Seems to me neither RFC states anything about "order" : like first the RRset, followed by the RRSIG(s) over that RRset. Or does it ? Yet, in both RFC's the examples maintain that logical order. I now stumble over an authoritative NS that does not implement the order - but that does returns the correct type and number of RRs in its answer - and Bind (9.7) seems to have a problem with it. Hence my question : Are the RFC's somehow prescribing some "order" in RRset's and the accompanying DNSSEC RRs ? Thanks, Marc Lampo Security Officer       EURid From Francis.Dupont@fdupont.fr Wed May 30 05:27: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 4B0E221F86E2 for ; Wed, 30 May 2012 05:27:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR9l6DmzNRE9 for ; Wed, 30 May 2012 05:27:36 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFFB21F86DE for ; Wed, 30 May 2012 05:27:36 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q4UCQvSn038306; Wed, 30 May 2012 14:26:57 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201205301226.q4UCQvSn038306@givry.fdupont.fr> From: Francis Dupont To: "Marc Lampo" In-reply-to: Your message of Wed, 30 May 2012 13:31:03 +0200. <004d01cd3e57$b230ec80$1692c580$@lampo@eurid.eu> Date: Wed, 30 May 2012 14:26:57 +0200 Sender: Francis.Dupont@fdupont.fr Cc: dnsext@ietf.org Subject: Re: [dnsext] rfc4035 & 5155 : order of RR's ? 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, 30 May 2012 12:27:37 -0000 There is an order between sections but no order inside a section. BTW DNSSEC RRs can go in a different section than the RRsets they protect. Regards Francis.Dupont@fdupont.fr