From george.barwood@blueyonder.co.uk Sun May 1 23:47:39 2011 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 63FF3E066E for ; Sun, 1 May 2011 23:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.137 X-Spam-Level: * X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_40=-0.185, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up9Tfsb6wdVJ for ; Sun, 1 May 2011 23:47:39 -0700 (PDT) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEF0E062A for ; Sun, 1 May 2011 23:47:38 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.3]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110502064735.NTUW14839.mtaout01-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net> for ; Mon, 2 May 2011 07:47:35 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1QGmut-00076q-6V for dnsext@ietf.org; Mon, 02 May 2011 07:47:35 +0100 Message-ID: <86139E4E3CF04A8EBC8F6D4117B03650@local> From: "George Barwood" To: Date: Mon, 2 May 2011 07:47:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=Lnba09HMIW0A:10 a=3NElcqgl2aoA:10 a=8nJEP1OIZ-IA:10 a=HNQkhj64atTcn45OGhoA:9 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: [dnsext] Authority and additional section questions 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, 02 May 2011 06:47:39 -0000 Rm9yIHNvbWUgdGltZSBJIGhhdmUgaGFkIHNvbWUgcXVlc3Rpb25zIGFib3V0IHdoYXQgUlJzZXRz IGFyZSBzZW50IGluIHRoZSBhdXRob3JpdHkgYW5kIGFkZGl0aW9uYWwgc2VjdGlvbnMuDQoNClRo ZXJlIGFyZSA0IHR5cGVzIG9mIHF1ZXN0aW9uOg0KDQpXaGF0IG11c3QgYmUgc2VudCBhbmQgd2h5 Pw0KV2hhdCBzaG91bGQgYmUgc2VudCBhbmQgd2h5Pw0KDQpFeGFtcGxlIHF1ZXN0aW9uczoNCg0K SW4gYSBwb3NpdGl2ZSByZWN1cnNpdmUgcmVzcG9uc2UsIHdoeSBpcyB0aGUgTlMgUlJzZXQgc2Vu dD8NCg0KU2hvdWxkIHNpZ25hdHVyZXMgZm9yIEEvQUFBQSBSUnNldHMgaW4gdGhlIGFkZGl0aW9u YWwgc2VjdGlvbiBiZSBzZW50IGlmIGF2YWlsYWJsZSwgYW5kIHdoeT8NCg0KSSdtIHRoaW5raW5n IG9mICB3cml0aW5nIGEgZG9jdW1lbnQgKHBvc3NpYmx5IGEgZHJhZnQpIHRoYXQgYXR0ZW1wdHMg dG8gYWRkcmVzcyB0aGVzZSBxdWVzdGlvbnMgaW4gYSBmYWlybHkNCmNvbXByZWhlbnNpdmUgd2F5 LCBidXQgYmVmb3JlIEkgc3RhcnQgSSB3b25kZXJlZCBpZiB0aGVyZSBhcmUgYW55IGV4aXN0aW5n IGRvY3VtZW50cyAoSUVURiBvciBvdGhlcndpc2UpDQp0aGF0IEknbSB1bmF3YXJlIG9mIHRoYXQg YWRkcmVzc2VzIHRoZXNlIHF1ZXN0aW9ucyAoIGVzcGVjaWFsbHkgdGhlICJ3aHkiIHBhcnRzICku IEknbSBhd2FyZSBvZiB0aGUgbWFpbg0KRE5TIFJGQ3MsIDEwMzQsMTAzNSwyMTgxLDQwMzMtMzUu DQoNClRoYW5rcywNCkdlb3JnZQ0KDQoNCg== From Internet-Drafts@ietf.org Fri May 6 11:30:35 2011 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 1740AE07DA; Fri, 6 May 2011 11:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq8NnJV6PG98; Fri, 6 May 2011 11:30:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD53E07CB; Fri, 6 May 2011 11:30:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110506183005.26272.78242.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2011 11:30:05 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D ACTION:draft-ietf-dnsext-rfc2672bis-dname-22.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: Fri, 06 May 2011 18:30:35 -0000 --NextPart 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. Title : Update to DNAME Redirection in the DNS Author(s) : S. Rose, et al Filename : draft-ietf-dnsext-rfc2672bis-dname-22.txt Pages : 18 Date : 2011-05-02 The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-22.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2672bis-dname-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-06112233.I-D@ietf.org> --NextPart-- From vixie@isc.org Mon May 9 08:50:55 2011 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 753ADE0703 for ; Mon, 9 May 2011 08:50:55 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33oXL+40PJRW for ; Mon, 9 May 2011 08:50:54 -0700 (PDT) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAF9E070B for ; Mon, 9 May 2011 08:50:49 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 7D138A1019 for ; Mon, 9 May 2011 15:50:46 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 09 May 2011 15:50:46 +0000 Message-ID: <46322.1304956246@nsa.vix.com> Subject: [dnsext] compression in UPDATE 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, 09 May 2011 15:50:55 -0000 this is a possible RFC 2136 errata. 2136 does not mention compression at all, which is an oversight, it ought to have said "compression shall not be used". in the absence of such a statement i believe that implementors of UPDATE responders have decompressed any of the RR types they understand, which is fine under the robustness principle but may create the misleading expectation that all types are understood and that compression is supported. therefore my question: does any UPDATE initiator actually use compression? From brian.wellington@nominum.com Mon May 9 11:33:55 2011 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 EE601E08AA for ; Mon, 9 May 2011 11:33:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Egmmdu+0Ki3y for ; Mon, 9 May 2011 11:33:55 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id BAC56E0791 for ; Mon, 9 May 2011 11:33:53 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTcgzkTVEq34ZtaHXLBDq1njHSiU56tDu@postini.com; Mon, 09 May 2011 11:33:54 PDT Received: from wave.ddns.nominum.com (wave.ddns.nominum.com [64.89.225.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 07A1F1B8659; Mon, 9 May 2011 11:33:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Wellington In-Reply-To: <46322.1304956246@nsa.vix.com> Date: Mon, 9 May 2011 11:33:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4CBE2660-72FF-40CE-89C2-C5D1EF9469C3@nominum.com> References: <46322.1304956246@nsa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] compression in UPDATE 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, 09 May 2011 18:33:56 -0000 On May 9, 2011, at 8:50 AM, Paul Vixie wrote: > this is a possible RFC 2136 errata. 2136 does not mention compression = at > all, which is an oversight, it ought to have said "compression shall = not > be used". in the absence of such a statement i believe that = implementors > of UPDATE responders have decompressed any of the RR types they = understand, > which is fine under the robustness principle but may create the = misleading > expectation that all types are understood and that compression is = supported. >=20 > therefore my question: does any UPDATE initiator actually use = compression? It's possible I'm misunderstanding the question, but wouldn't = compression be expected? None of the implementations I'm familiar with = conditionalize name compression based on opcode, so any types which can = be compressed in QUERY responses could also be compressed in UPDATE = requests. nsupdate appears to be compressing both owner names and names in rdata, = for example. Brian= From fanf2@hermes.cam.ac.uk Mon May 9 11:50:39 2011 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 EF816E06C4 for ; Mon, 9 May 2011 11:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[AWL=1.874, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzVyp4RqNX8I for ; Mon, 9 May 2011 11:50:39 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id E73FEE06BE for ; Mon, 9 May 2011 11:50:37 -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]:36256) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1QJVDZ-0000Tk-Di (Exim 4.72) (return-path ); Mon, 09 May 2011 19:30:05 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QJVDY-00008I-Md (Exim 4.67) (return-path ); Mon, 09 May 2011 19:30:05 +0100 Date: Mon, 9 May 2011 19:30:04 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Vixie In-Reply-To: <46322.1304956246@nsa.vix.com> Message-ID: References: <46322.1304956246@nsa.vix.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] compression in UPDATE 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, 09 May 2011 18:50:42 -0000 Paul Vixie wrote: > > therefore my question: does any UPDATE initiator actually use compression? BIND's nsupdate tool compresses owner names and names in the RDATA of RFC 1035 RR types. This is consistent with RFC 3597, which makes sense. I don't think RFC 2136 needs to forbid compression; it just needs to say that records (owner names and RDATA) are compared after they have been decompressed and the RDLENGTH adjusted to match. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5 or 6 later. Rough or very rough. Occasional rain. Moderate or good, occasionally poor. From vixie@isc.org Mon May 9 12:04:19 2011 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 2E916E079A for ; Mon, 9 May 2011 12:04:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az-Ac0PfnBBJ for ; Mon, 9 May 2011 12:04:18 -0700 (PDT) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id 069DEE073D for ; Mon, 9 May 2011 12:04:12 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E27A7A1019 for ; Mon, 9 May 2011 18:57:36 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Mon, 09 May 2011 11:33:52 MST." <4CBE2660-72FF-40CE-89C2-C5D1EF9469C3@nominum.com> References: <46322.1304956246@nsa.vix.com> <4CBE2660-72FF-40CE-89C2-C5D1EF9469C3@nominum.com> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 09 May 2011 18:57:36 +0000 Message-ID: <63636.1304967456@nsa.vix.com> Subject: Re: [dnsext] compression in UPDATE 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, 09 May 2011 19:04:19 -0000 > From: Brian Wellington > Date: Mon, 9 May 2011 11:33:52 -0700 > > nsupdate appears to be compressing both owner names and names in > rdata, for example. so i see. ouch. in fact the bind8 version of this goes well beyond RFC 3597's constraints on "known types". i suggest that we draw a new line in the sand and require that compression be understood for all types that any now-current implementation is known to compress for. From vixie@isc.org Mon May 9 13:26:48 2011 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 82AE4E073C for ; Mon, 9 May 2011 13:26:48 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1VYp7YcpDPS for ; Mon, 9 May 2011 13:26:32 -0700 (PDT) Received: from nsa.vix.com (nsa.vix.com [149.20.48.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9F767E06DB for ; Mon, 9 May 2011 13:26:32 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id DBFAEA1043 for ; Mon, 9 May 2011 20:26:28 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Mon, 09 May 2011 16:03:59 -0400." References: <46322.1304956246@nsa.vix.com> <4CBE2660-72FF-40CE-89C2-C5D1EF9469C3@nominum.com> <63636.1304967456@nsa.vix.com> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 09 May 2011 20:26:28 +0000 Message-ID: <46926.1304972788@nsa.vix.com> Subject: Re: [dnsext] compression in UPDATE 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, 09 May 2011 20:26:48 -0000 > Date: Mon, 9 May 2011 16:03:59 -0400 > From: Edward Lewis > > >so i see. ouch. in fact the bind8 version of this goes well beyond > >RFC 3597's constraints on "known types". i suggest that we draw a new > >line in the sand and require that compression be understood for all > >types that any now-current implementation is known to compress for. > > I'd go the other way. There's little harm in never compressing an outgoing > message (the loss is that extra octets are moved). There's more harm in > compressing a type the receiver doesn't know, especially because the > receiver wouldn't know that there was compression in use. (Compression > isn't transitive, message to message, that is.) i agree, and that was my first inclination also, but i hate breaking the installed base just for the sake of purity. nsupdate is a huge contributor to the world's supply of UPDATE messages and i am loathe to declare it broken. From Ed.Lewis@neustar.biz Mon May 9 13:58:26 2011 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 C0435E0967 for ; Mon, 9 May 2011 13:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.483 X-Spam-Level: X-Spam-Status: No, score=-106.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zRkamf+Loio for ; Mon, 9 May 2011 13:58:26 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF80E0960 for ; Mon, 9 May 2011 13:58:24 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p49K4C7a074501; Mon, 9 May 2011 16:04:13 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.215] by Work-Laptop-2.local (PGP Universal service); Mon, 09 May 2011 16:04:13 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 09 May 2011 16:04:13 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <63636.1304967456@nsa.vix.com> References: <46322.1304956246@nsa.vix.com> <4CBE2660-72FF-40CE-89C2-C5D1EF9469C3@nominum.com> <63636.1304967456@nsa.vix.com> Date: Mon, 9 May 2011 16:03:59 -0400 To: Paul Vixie From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] compression in UPDATE 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, 09 May 2011 20:58:26 -0000 At 18:57 +0000 5/9/11, Paul Vixie wrote: >so i see. ouch. in fact the bind8 version of this goes well beyond >RFC 3597's constraints on "known types". i suggest that we draw a new >line in the sand and require that compression be understood for all >types that any now-current implementation is known to compress for. I'd go the other way. There's little harm in never compressing an outgoing message (the loss is that extra octets are moved). There's more harm in compressing a type the receiver doesn't know, especially because the receiver wouldn't know that there was compression in use. (Compression isn't transitive, message to message, that is.) Having been involved in a few "clarification" documents I'm not all that eager to see any more lines in the sand redrawn. ;) It's never pain-free. Recently I privately offered to write a document to cover over all the dead types and got no statements of support. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From brian.wellington@nominum.com Mon May 9 14:16:50 2011 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 E8B0CE072E for ; Mon, 9 May 2011 14:16:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Au9yatrRmlr for ; Mon, 9 May 2011 14:16:50 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7E070E07F3 for ; Mon, 9 May 2011 14:16:37 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTchZtI4GSL3RXW0y4Gbkozkvy8UjkUmc@postini.com; Mon, 09 May 2011 14:16:37 PDT Received: from wave.ddns.nominum.com (wave.ddns.nominum.com [64.89.225.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 64F281B868F; Mon, 9 May 2011 13:41:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Wellington In-Reply-To: <46926.1304972788@nsa.vix.com> Date: Mon, 9 May 2011 13:41:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46322.1304956246@nsa.vix.com> <4CBE2660-72FF-40CE-89C2-C5D1EF9469C3@nominum.com> <63636.1304967456@nsa.vix.com> <46926.1304972788@nsa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] compression in UPDATE 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, 09 May 2011 21:16:51 -0000 On May 9, 2011, at 1:26 PM, Paul Vixie wrote: >> Date: Mon, 9 May 2011 16:03:59 -0400 >> From: Edward Lewis >>=20 >>> so i see. ouch. in fact the bind8 version of this goes well beyond >>> RFC 3597's constraints on "known types". i suggest that we draw a = new >>> line in the sand and require that compression be understood for all >>> types that any now-current implementation is known to compress for. >>=20 >> I'd go the other way. There's little harm in never compressing an = outgoing >> message (the loss is that extra octets are moved). There's more harm = in >> compressing a type the receiver doesn't know, especially because the >> receiver wouldn't know that there was compression in use. = (Compression >> isn't transitive, message to message, that is.) >=20 > i agree, and that was my first inclination also, but i hate breaking = the > installed base just for the sake of purity. nsupdate is a huge = contributor > to the world's supply of UPDATE messages and i am loathe to declare it > broken. A few more points: RFC 1035 (in section 4.1.4. Message compression) doesn't say anything = about opcode. UPDATE was defined later, so obviously wouldn't be = mentioned there, but there's also no specific mention of QUERY, IQUERY, = or STATUS; the text says "In order to reduce the size of messages". RFC 1996 (NOTIFY) also doesn't mention compression; is anyone suggesting = that compression be outlawed there as well? RFC 3597 (unknown RR types) doesn't mention anything about opcode QUERY; = I'd interpret it as defining the list of types expected to be known = regardless of OPCODE. If bind8's nsupdate is compressing types not = listed by RFC3597, that sounds like a potential problem, but compressing = any type listed in RFC 3597 seems safe enough. Brian From d3e3e3@gmail.com Mon May 9 14:56:02 2011 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 DAD39E06CF for ; Mon, 9 May 2011 14:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.783 X-Spam-Level: X-Spam-Status: No, score=-103.783 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwTk1-KcBrdi for ; Mon, 9 May 2011 14:56:02 -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 3EFB1E06BE for ; Mon, 9 May 2011 14:56:01 -0700 (PDT) Received: by ywi6 with SMTP id 6so2469131ywi.31 for ; Mon, 09 May 2011 14:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=dpA+HTlbWJdey/A3H72hJSNE4OYkwvjJy/OkvX8rK78=; b=DHlt+RupVqJvrhgVKYPMCy1GRRnGC9zEtEL2hvMNH1dk1IhedkvumLMGotAD6pvUnG O+zir5I3FSTKnu24sCQU/CIq/DHhd9G56uU3I20v8VzChiqB8iicBxrai95XTTguguB9 /i8OihUGMKMGi0pj4TJLIXif6c0GbfVV+3hl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=a+EHVawWUZ600Wl8dIBJK+sE3rN/i+vTIBJNhVuSap8wx8la4bA8c3wrmZogDC7/3i MbSHSWlG5kJk4WiXJX2/ZntkNvfQa/4f82JZOfGigwWB46EuNfRUA50KwjrEMvm7zcle pdDeuec9+B0fAZmMHZGoZ7foYgtr+3mlufsN4= Received: by 10.151.21.5 with SMTP id y5mr5847229ybi.304.1304978161204; Mon, 09 May 2011 14:56:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.42.16 with HTTP; Mon, 9 May 2011 14:55:41 -0700 (PDT) In-Reply-To: <20110509215148.F0F45E072C@ietfa.amsl.com> References: <20110509215148.F0F45E072C@ietfa.amsl.com> From: Donald Eastlake Date: Tue, 10 May 2011 06:55:41 +0900 Message-ID: To: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [dnsext] Fwd: New Version Notification for draft-eastlake-dnsext-xnamercode-04 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, 09 May 2011 21:56:03 -0000 I have updated dates, version number, author info, and boilerplate. And I've unambiguously removed "unambiguously"... 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 ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Tue, May 10, 2011 at 6:51 AM Subject: New Version Notification for draft-eastlake-dnsext-xnamercode-04 To: d3e3e3@gmail.com A new version of I-D, draft-eastlake-dnsext-xnamercode-04.txt has been successfully submitted by Donald Eastlake 3rd and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-eastlake-dnsext-xnamercode Revision: =A0 =A0 =A0 =A004 Title: =A0 =A0 =A0 =A0 =A0 xNAME RCODE and Status Bits Clarification Creation_date: =A0 2011-05-09 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 9 Abstract: The Domain Name System (DNS) has long provided means, such as CNAME (Canonical Name), where a query can be redirected to a different name. A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits. This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles. The IETF Secretariat. From marka@isc.org Mon May 9 15:16:50 2011 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 6CABFE06CF for ; Mon, 9 May 2011 15:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.95 X-Spam-Level: X-Spam-Status: No, score=-8.95 tagged_above=-999 required=5 tests=[AWL=1.649, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh7SmY40i9lP for ; Mon, 9 May 2011 15:16:49 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id BD4E0E067B for ; Mon, 9 May 2011 15:16:49 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id E3D17C94EB; Mon, 9 May 2011 22:16:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 6F238216C31; Mon, 9 May 2011 22:16:35 +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 207A4E99B7F; Tue, 10 May 2011 08:16:56 +1000 (EST) To: Brian Wellington From: Mark Andrews References: <46322.1304956246@nsa.vix.com> <4CBE2660-72FF-40CE-89C2-C5D1EF9469C3@nominum.com> <63636.1304967456@nsa.vix.com> <46926.1304972788@nsa.vix.com> In-reply-to: Your message of "Mon, 09 May 2011 13:41:03 MST." Date: Tue, 10 May 2011 08:16:56 +1000 Message-Id: <20110509221656.207A4E99B7F@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] compression in UPDATE 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, 09 May 2011 22:16:50 -0000 In message , Brian Wellington writes: > > On May 9, 2011, at 1:26 PM, Paul Vixie wrote: > > >> Date: Mon, 9 May 2011 16:03:59 -0400 > >> From: Edward Lewis > >> > >>> so i see. ouch. in fact the bind8 version of this goes well beyond > >>> RFC 3597's constraints on "known types". i suggest that we draw a new > >>> line in the sand and require that compression be understood for all > >>> types that any now-current implementation is known to compress for. > >> > >> I'd go the other way. There's little harm in never compressing an outgoin > g > >> message (the loss is that extra octets are moved). There's more harm in > >> compressing a type the receiver doesn't know, especially because the > >> receiver wouldn't know that there was compression in use. (Compression > >> isn't transitive, message to message, that is.) > > > > i agree, and that was my first inclination also, but i hate breaking the > > installed base just for the sake of purity. nsupdate is a huge contributor > > to the world's supply of UPDATE messages and i am loathe to declare it > > broken. > > A few more points: > > RFC 1035 (in section 4.1.4. Message compression) doesn't say anything about o > pcode. UPDATE was defined later, so obviously wouldn't be mentioned there, b > ut there's also no specific mention of QUERY, IQUERY, or STATUS; the text say > s "In order to reduce the size of messages". > > RFC 1996 (NOTIFY) also doesn't mention compression; is anyone suggesting that > compression be outlawed there as well? > > RFC 3597 (unknown RR types) doesn't mention anything about opcode QUERY; I'd > interpret it as defining the list of types expected to be known regardless of > OPCODE. If bind8's nsupdate is compressing types not listed by RFC3597, tha > t sounds like a potential problem, but compressing any type listed in RFC 359 > 7 seems safe enough. > > Brian BIND 8's nsupdate knows about the following types. { "a", T_A }, /* no rdata compression possible */ { "ns", T_NS }, /* listed in RFC 3597 */ { "cname", T_CNAME }, /* listed in RFC 3597 */ { "soa", T_SOA }, /* listed in RFC 3597 */ { "mb", T_MB }, /* listed in RFC 3597 */ { "mg", T_MG }, /* listed in RFC 3597 */ { "mr", T_MR }, /* listed in RFC 3597 */ { "null", T_NULL }, /* no rdata compression possible */ { "wks", T_WKS }, /* no rdata compression possible */ { "ptr", T_PTR }, /* listed in RFC 3597 */ { "hinfo", T_HINFO }, /* no rdata compression possible */ { "minfo", T_MINFO }, /* listed in RFC 3597 */ { "mx", T_MX }, /* listed in RFC 3597 */ { "txt", T_TXT }, /* no rdata compression possible */ { "rp", T_RP }, /* listed in RFC 3597 */ { "afsdb", T_AFSDB }, /* listed in RFC 3597 */ { "x25", T_X25 }, /* no rdata compression possible */ { "isdn", T_ISDN }, /* no rdata compression possible */ { "rt", T_RT }, /* listed in RFC 3597 */ { "nsap", T_NSAP }, /* no rdata compression possible */ { "nsap_ptr", T_NSAP_PTR }, /* SHOULD HAVE BEEN LISTED IN RFC 3597 */ { "sig", T_SIG }, /* listed in RFC 3597 */ { "key", T_KEY }, /* no rdata compression possible */ { "px", T_PX }, /* listed in RFC 3597 */ { "loc", T_LOC }, /* no rdata compression possible */ { "nxt", T_NXT }, /* listed in RFC 3597 */ { "eid", T_EID }, { "nimloc", T_NIMLOC }, { "srv", T_SRV }, /* listed in RFC 3597 */ { "atma", T_ATMA }, { "naptr", T_NAPTR }, /* listed in RFC 3597 */ { "kx", ns_t_kx }, /* listed in RFC 3597 */ { "cert", ns_t_cert }, /* no rdata compression possible */ { "aaaa", ns_t_aaaa }, /* no rdata compression possible */ { "dname", ns_t_dname }, /* listed in RFC 3597 */ This all being said, case sensitive, compression should be used so that UPDATE can meet the case preservation requirements of RFC103[45]. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ogud@ogud.com Tue May 10 08:28:26 2011 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 759A8E0828 for ; Tue, 10 May 2011 08:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.448 X-Spam-Level: X-Spam-Status: No, score=-104.448 tagged_above=-999 required=5 tests=[AWL=2.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58bsGE16xmxa for ; Tue, 10 May 2011 08:28:25 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 27265E0749 for ; Tue, 10 May 2011 08:28:24 -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 p4AEPmPb081507 for ; Tue, 10 May 2011 10:25:48 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4DC94AE6.5000903@ogud.com> Date: Tue, 10 May 2011 10:25:42 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dnsext] WGLC ENDS0-bis 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, 10 May 2011 15:28:26 -0000 Dear Colleagues This message starts a Working Group Last Call for "Extension Mechanisms for DNS (EDNS0)" located at http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-05 As the document is replacing a Standards Track document this document is on Standards Track. This WGLC will conclude on midnight May 25'th 2011 EDT. This document obsoletes RFC2671. The big changes from RFC2671 are: - explicit usage of RFC2119 terms and labeling EDNS0 support as MUST; - discussion on payload sizes and selection; - closing of the extended label types registry and classifying bit-labels as Historic; - cleanup of IANA actions (that did not take place when RFC2671 was issued). Other than these there are no changes from RFC2671. Please send statements that you have reviewed this document and if it raised any issues. Remember we need 5 a minimum of 5 reviewers to say they reviewed the document. Olafur & Andrew From brian.peter.dickson@gmail.com Tue May 10 08:57:58 2011 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 54B22E0715 for ; Tue, 10 May 2011 08:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.364 X-Spam-Level: X-Spam-Status: No, score=-3.364 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee3qpzAkmCmm for ; Tue, 10 May 2011 08:57:57 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB4D9E06D5 for ; Tue, 10 May 2011 08:57:56 -0700 (PDT) Received: by fxm15 with SMTP id 15so5195668fxm.31 for ; Tue, 10 May 2011 08:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3W7lFhL6GwK6d51BMOFrjTHc90IUgdH/jlsnJQQM1PQ=; b=hMCKAVoOy7/3lESH84+NEkEw81+SwZd7SzBkgjmMqLTCrpPPoDaGVAtI/GwOYJdzoY tKQMQnXOnCZltUm6hLLKBYq3xKSK1+4Fqz4N8ZbUhHP7Zl1b9Tc8BnjELPtYVixAV+AY 2W4nZVmDQfHvPCdtZYtZ20Svt4JkEvVDrtqtc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VUAK2QdMcGg6QN5BCJwpvtx/g00S4r5jD4bHjhcbOAe3BK3suF/5KcxIBEOKNSdsZV pj5tX1OrnzeIO9FFSgNysGiDnRbVPmGFYqwJBYBgwG+vyzGLWI508SQ2T71oz1LmReez n31uk7BymwKE/t54+lVzUzZCKnLlRLkLiKRnM= MIME-Version: 1.0 Received: by 10.223.51.4 with SMTP id b4mr2294484fag.93.1305043075499; Tue, 10 May 2011 08:57:55 -0700 (PDT) Received: by 10.223.120.133 with HTTP; Tue, 10 May 2011 08:57:55 -0700 (PDT) In-Reply-To: <4DC94AE6.5000903@ogud.com> References: <4DC94AE6.5000903@ogud.com> Date: Tue, 10 May 2011 11:57:55 -0400 Message-ID: From: Brian Dickson To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=001517476950ee89ba04a2ee04c7 Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC ENDS0-bis 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, 10 May 2011 15:57:58 -0000 --001517476950ee89ba04a2ee04c7 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed the document, and support its publication. Brian Dickson On Tue, May 10, 2011 at 10:25 AM, Olafur Gudmundsson wrote: > > > Dear Colleagues > > > This message starts a Working Group Last Call for > "Extension Mechanisms for DNS (EDNS0)" located at > http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-05 > As the document is replacing a Standards Track document this document is on > Standards Track. > > This WGLC will conclude on midnight May 25'th 2011 EDT. > > This document obsoletes RFC2671. The big changes from RFC2671 are: > - explicit usage of RFC2119 terms and labeling EDNS0 support as MUST; > - discussion on payload sizes and selection; > - closing of the extended label types registry and classifying > bit-labels as Historic; > - cleanup of IANA actions (that did not take place when RFC2671 > was issued). > > Other than these there are no changes from RFC2671. > > Please send statements that you have reviewed this document and if it > raised any issues. Remember we need 5 a minimum of 5 reviewers to say they > reviewed the document. > > Olafur & Andrew > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --001517476950ee89ba04a2ee04c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have reviewed the document, and support its publication.

Brian Dic= kson

On Tue, May 10, 2011 at 10:25 AM, Ol= afur Gudmundsson <ogu= d@ogud.com> wrote:


Dear Colleagues


This message starts a Working Group Last Call for
"Extension Mechanisms for DNS (EDNS0)" located at
http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis= -edns0-05
As the document is replacing a Standards Track document this document is on= Standards Track.

This WGLC will conclude on midnight May 25'th 2011 EDT.

This document obsoletes RFC2671. =A0The big changes from RFC2671 are:
=A0- explicit usage of RFC2119 terms and labeling EDNS0 support as MUST; =A0- discussion on payload sizes and selection;
=A0- closing of the extended label types registry and classifying =A0 =A0 = =A0 =A0
=A0 =A0 =A0 bit-labels as Historic;
=A0- cleanup of IANA actions (that did not take place when RFC2671
=A0 =A0 =A0was issued).

Other than these there are no changes from RFC2671.

Please send statements that you have reviewed this document and if it raise= d any issues. Remember we need 5 a minimum of 5 reviewers to say they revie= wed the document.

=A0 =A0Olafur & Andrew
_______________________________________________
dnsext mailing list
dnsext@ietf.org = https://www.ietf.org/mailman/listinfo/dnsext

--001517476950ee89ba04a2ee04c7-- From cet1@hermes.cam.ac.uk Tue May 10 10:02:45 2011 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 4F54CE076D for ; Tue, 10 May 2011 10:02:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpQud+wjhySQ for ; Tue, 10 May 2011 10:02:44 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 36B00E06DC for ; Tue, 10 May 2011 10:02:42 -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]:37234) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:cet1) id 1QJqKX-0007ft-Wd (Exim 4.72) for dnsext@ietf.org (return-path ); Tue, 10 May 2011 18:02:41 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1QJqKX-0004jN-3M (Exim 4.67) for dnsext@ietf.org (return-path ); Tue, 10 May 2011 18:02:41 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.3); 10 May 2011 18:02:40 +0100 Date: 10 May 2011 18:02:40 +0100 From: Chris Thompson To: dnsext@ietf.org Message-ID: In-Reply-To: <4DC94AE6.5000903@ogud.com> References: <4DC94AE6.5000903@ogud.com> X-Mailer: Prayer v1.3.3 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Subject: Re: [dnsext] WGLC ENDS0-bis 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: Tue, 10 May 2011 17:02:45 -0000 On May 10 2011, Olafur Gudmundsson wrote: >This message starts a Working Group Last Call for >"Extension Mechanisms for DNS (EDNS0)" located at >http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-05 >As the document is replacing a Standards Track document this document is >on Standards Track. Niggle: in section 6.1 The OPT RR MAY be placed anywhere within the additional data section. Only one OPT RR MAY be included within any DNS message. If a message ^^^^^^^ with more than one OPT RR is received, a FORMERR (RCODE=1) MUST be returned. Surely "request" is meant in that last sentence rather than "message"? A reply containing multiple OPTs is malformed, certainly, but that's not not to say it should itself recursively generate a reply! -- 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 fanf2@hermes.cam.ac.uk Tue May 10 11:09:29 2011 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 AB9A1E0744 for ; Tue, 10 May 2011 11:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[AWL=1.704, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+JCXO0mhwsI for ; Tue, 10 May 2011 11:09:28 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 34951E0693 for ; Tue, 10 May 2011 11:09: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]:52728) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1QJrN6-00063q-Y0 (Exim 4.72) (return-path ); Tue, 10 May 2011 19:09:24 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QJrN6-0003ut-H3 (Exim 4.67) (return-path ); Tue, 10 May 2011 19:09:24 +0100 Date: Tue, 10 May 2011 19:09:24 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Chris Thompson In-Reply-To: Message-ID: References: <4DC94AE6.5000903@ogud.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC ENDS0-bis 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, 10 May 2011 18:09:29 -0000 A few nits: Section 1. "The maximum allowable size of a DNS Message is limited to 512 bytes." Insert "transmitted over UDP without EDNS0". "Many of DNS's protocol limits are too small for uses which are commom or desired to become common." Is there more than just the UDP packet size? Should it say "This limit is too small for uses which are commom or desired to become common, and the cost of using TCP instead of UDP for most requests is too high." The last two sentences of paragraph 3 repeat paragraph 2. Otherwise it looks OK to me. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5 or 6 later. Rough or very rough. Occasional rain. Moderate or good, occasionally poor. From Ed.Lewis@neustar.biz Tue May 10 12:14:40 2011 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 43096E07C9 for ; Tue, 10 May 2011 12:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3itVdKRDlF1 for ; Tue, 10 May 2011 12:14:39 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 00439E06B9 for ; Tue, 10 May 2011 12:14:38 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p4AJEXdD083868; Tue, 10 May 2011 15:14:33 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.215] by Work-Laptop-2.local (PGP Universal service); Tue, 10 May 2011 15:14:35 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 10 May 2011 15:14:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DC94AE6.5000903@ogud.com> References: <4DC94AE6.5000903@ogud.com> Date: Tue, 10 May 2011 15:14:29 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] WGLC ENDS0-bis 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, 10 May 2011 19:14:40 -0000 At 10:25 -0400 5/10/11, Olafur Gudmundsson wrote: >http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-05 Count me disgruntled. I have a few comments on this document. We need EDNS0 to be cleaned up. We need this document. The document is not a mess nor a total failure (hey, that's the good news) but there are a few items that need to be addressed before it is ready to go. First items from the document: Item 1 #3. EDNS Support Requirement # # EDNS support is practically mandatory in a modern world. DNSSEC # requires EDNS support, and many other features are made possible only # by EDNS support to request or advertise them. Many organizations are # requiring DNSSEC. Without common interoperability, DNSSEC cannot be # as easily deployed. Horse and cart placement. Don't hinge EDNS0 on DNSSEC. ENUM/DDDS needs it too, as well as IPv6's AAAA record answers. Other future needs will likely come along. I think that this section, if it is to highlight that DNSSEC needs it, should reference the existing documents that state why EDNS0 is needed. BTW, I think that the requirement to use EDNS0 is more clearly stated for ENUM than DNSSEC. Item 2 # 6.8. Middleware Boxes This section is a problem. Middleware boxes aren't well defined (yes, there is the parenthetical list of examples), lacking references to documents that provide definitions here. Going beyond that I don't know what this document is trying to impart. Are these requirements on non-DNS processes that are acting as stateful proxies for DNS messages in dealing with EDNS0 records? Item 3 # 7. Transport Considerations # #... # Responders who do not implement these protocol extensions MUST # respond with FORMERR messages without any OPT record. This requirement cannot appear here (as written). No document can set a requirement on existing and deployed software and expect compliance. Perhaps this can be substituted: "A DNS message server electing not to support this definition of EDNS0 MUST respond with a return code (RCODE) of FORMERR when detecting an OPT RR in the additional section of a query message." Essentially, an implementation can say they are compliant with the document in saying "we don't play" EDNS0. (But I don't think that is what the authors intended.) Item 4 RFC 2119 language There are a few instances of lower case "must" in the document. I ran across that looking for something else. In general, make sure all RFC 2119 language stands out. (I realize that some "must"s appear before 2119 is invoked - I'm not counting those.) Item 5 #6.4. Fallback #... # If an implementation detects that some servers for the zone support # EDNS(0) while others would force the use of TCP to fetch all data, # preference SHOULD be given to those support EDNS(0). I am no longer convinced that it is wise to state preferences like this. It is backfiring in IPv6 transition (preferring IPv6 over IPv4 for DNS traffic, for one). I would urge this to become a consideration - an implementer ought to weigh that TCP requires more set up time. In retrospect, I think this is just a bad idea to include. Let implementors deal with this without a specification hanging over them. (TCP is not proving to be *that* bad. It works good for other protocols.) Item 6 Tone of voice/perspective I find that when text gets personal, the feeling changes. In this document, the word "you" appears twice in one paragraph: Item 7 #6.7. Payload Size Selection # # Due to transaction overhead, it is unwise to advertise an # architectural limit as a maximum UDP payload size. Just because your # stack can reassemble 64KB datagrams, don't assume that you want to # spend more than about 4KB of state memory per ongoing transaction. "Just because your $X can" do something makes it sound like a challenge is being made. In total, the section here is needed, but I think it comes across poorly. As someone eyeing this as something I would have to conform to, seeing "SHOULD...such as" makes it hard to write the formal requirement and test case. In the old days we got away with "to simplify implementations" (RFC 1034, remember), why can't we do that here. "To simplify implementations" start with 4K, then drop to something small enough for Ethernet (1280) before dropping EDNS0 altogether. I think this would go a long way to avoiding the "path MTU" discussions that go around. Missing material Item 8 I think the point that EDNS0 is a hop-by-hop marshaller of parameters, and not an end-to-end signalling mechanism is not clear enough. I don't think the architectural placement of EDNS0 is clear described. This should be in the introductory material. Item 9 Section 6.3 needs more material. It should say how a cache (server) would make use of EDNS0, besides saying that OPT RR's are not cached (or DNSSEC signed!). This goes hand in hand with Item 8. Perhaps "more material" is stronger than it should be. Considering a cache may or may not mean the same thing as a caching server, the discussion would be different. A caching server needs some instructions on how to deal with a client of it using one set of EDNS0 parameters and a server to it with different EDNS0 preferences. What might a proposed EDNS0 option need to specify about the behavior at a caching server? Item 10 What is the implication of an EDNS0 buffer size of less than 512 bytes? What if the size is smaller than what a header requires? (E.g., bufsize=4 in dig-speak?) Can the server respond with FORMERR if that is bigger than the buffer advertised? We ran across these questions when trying to do some testing, and found the specification to be missing on that. Stating that sizes below 512 can be treated as 512 would be sufficient, but some lower limit ought to be mentioned. In closing, thanks for... Stating that implementations are expected to skip/ignore the options they do not implement and that if the requestor needs confirmation an option was used, the option has to define the "ack." (Bottom of page 6.) This is a needed "feature" which I think wasn't in the original RFC. (It it wasn't there, oops, and uh, then there's no thanks to give. ;)) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From bortzmeyer@nic.fr Wed May 11 01:02:01 2011 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 B9CE1E0782 for ; Wed, 11 May 2011 01:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KSAAeTZFwDJ for ; Wed, 11 May 2011 01:02:01 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id DE8D7E06C1 for ; Wed, 11 May 2011 01:02:00 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 8BA741C0091 for ; Wed, 11 May 2011 10:01:59 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 87C751C001D for ; Wed, 11 May 2011 10:01:59 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 863A056812B for ; Wed, 11 May 2011 10:01:59 +0200 (CEST) Date: Wed, 11 May 2011 10:01:59 +0200 From: Stephane Bortzmeyer To: dnsext@ietf.org Message-ID: <20110511080159.GA13132@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 6.0.1 X-Kernel: Linux 2.6.32-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [dnsext] DNSSEC, robustness, and several DS records 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, 11 May 2011 08:02:01 -0000 A recent incident lead me to re-study the question of "what a validating resolver must/should do when there are several DS and some are invalid in some way?" AFAIK (I would be glad to be corrected here), the best common practice is to be lax ("DNSSEC is hard enough, accept any DS"), following RFC 4035, section 2.4 and 5.3.1. But it seems there is an "exception". RFC 4509, section 3, says that DS hashed with SHA-1 must be ignored when there is a DS for the same key hashed with SHA-2. This is to avoid downgrade attacks. In the incident I was talking about, there were two DS for the same KSK key, one hashed with SHA-1 and one with SHA-256 and the second one was invalid, because of a bug (wrong Algorithm field). As a result, both BIND and Unbound, following RFC 4509, returned a SERVFAIL, while there was another and perfectly valid DS record. I question this rule: SHA-1 (as it is used for DNSSEC) is not broken and the risk of downgrade attacks is ridiculous when you compare, both to the other attacks on DNSSEC, and to the risk of creating an error. Isn't it a case of excess security, which will turn people away from DNSSEC (too much risk of breakage)? From thierry.moreau@connotech.com Wed May 11 06:39:21 2011 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 D405AE06AF for ; Wed, 11 May 2011 06:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F63gSUUZd3jB for ; Wed, 11 May 2011 06:39:21 -0700 (PDT) Received: from bretelle.intaglionic.org (unknown [76.10.176.241]) by ietfa.amsl.com (Postfix) with ESMTP id 588BBE069E for ; Wed, 11 May 2011 06:39:21 -0700 (PDT) Received: from [192.168.1.200] (unknown [192.168.1.200]) by bretelle.intaglionic.org (Postfix) with ESMTPA id 708DE30290; Wed, 11 May 2011 14:47:59 -0400 (EDT) Message-ID: <4DCA9302.5010102@connotech.com> Date: Wed, 11 May 2011 09:45:38 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <20110511080159.GA13132@nic.fr> In-Reply-To: <20110511080159.GA13132@nic.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 11 May 2011 13:39:21 -0000 Stephane Bortzmeyer wrote: > A recent incident lead me to re-study the question of "what a > validating resolver must/should do when there are several DS and some > are invalid in some way?" AFAIK (I would be glad to be corrected > here), the best common practice is to be lax ("DNSSEC is hard enough, > accept any DS"), following RFC 4035, section 2.4 and 5.3.1. > > But it seems there is an "exception". RFC 4509, section 3, says that > DS hashed with SHA-1 must be ignored when there is a DS for the same > key hashed with SHA-2. This is to avoid downgrade attacks. > > In the incident I was talking about, there were two DS for the same > KSK key, one hashed with SHA-1 and one with SHA-256 and the second one > was invalid, because of a bug (wrong Algorithm field). As a result, > both BIND and Unbound, following RFC 4509, returned a SERVFAIL, while > there was another and perfectly valid DS record. > > I question this rule: SHA-1 (as it is used for DNSSEC) is not broken > and the risk of downgrade attacks is ridiculous when you compare, both > to the other attacks on DNSSEC, and to the risk of creating an > error. Isn't it a case of excess security, which will turn people away > from DNSSEC (too much risk of breakage)? Yes, it is such a case. -- - Thierry Moreau From Ed.Lewis@neustar.biz Wed May 11 06:57:46 2011 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 0E90AE0685 for ; Wed, 11 May 2011 06:57:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmEwZi9Aqlpw for ; Wed, 11 May 2011 06:57:45 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 48D19E0725 for ; Wed, 11 May 2011 06:57:38 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p4BDvZKI090889; Wed, 11 May 2011 09:57:35 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.215] by Work-Laptop-2.local (PGP Universal service); Wed, 11 May 2011 09:57:36 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 11 May 2011 09:57:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110511080159.GA13132@nic.fr> References: <20110511080159.GA13132@nic.fr> Date: Wed, 11 May 2011 09:57:32 -0400 To: Stephane Bortzmeyer From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 11 May 2011 13:57:46 -0000 At 10:01 +0200 5/11/11, Stephane Bortzmeyer wrote: >But it seems there is an "exception". RFC 4509, section 3, says that >DS hashed with SHA-1 must be ignored when there is a DS for the same >key hashed with SHA-2. This is to avoid downgrade attacks. ... >I question this rule: SHA-1 (as it is used for DNSSEC) is not broken >and the risk of downgrade attacks is ridiculous when you compare, both >to the other attacks on DNSSEC, and to the risk of creating an >error. Isn't it a case of excess security, which will turn people away >from DNSSEC (too much risk of breakage)? I gave this rule some thought too in the past couple of days, for the same reason. I was never a fan of the rule but paid it no mind. Now I think it is yet another example of a kink in the pipes that might eventually come back to haunt us. The overriding policy is still "local policy rules." It is fine for the document to say to implementers and deployers that if there is a choice between SHA-1 and SHA-2, prefer the latter because it is generally better. "Generally" means that it is possible an operator could mess up the SHA-2 record (not the hash, the record). Looking at other examples of this kind of preference, IPv6 over Ipv4, we see that sometimes promoting a new technology over an old can backfire in the transition phase. More and more I think it is a mistake to bias a standard to one approach over another, instead, just inform the interested parties in the trade-offs. If the underlying code is neutral, then we can adjust operations around changes in conventional wisdom. Once we cement in a particular choice we are stuck. Another set of principles I'd repeat - DNSSEC is a first line of defense, not a last line, meaning it's in the infrastructure and not the application. DNSSEC has to be liberal because the impacts of a false positive are large and hidden under layers of code and GUIs. DNSSEC is to protect the cache and it is up to the cache operator to decide how to protect itself. And the crypto-problem we are tackling is a subset of the general problem, a lot of the attacks (like downgrades) are just not all that realistic in the confines of DNS. DNS isn't immune, but the opportunities for a successful attack are limited. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From wjhns1@hardakers.net Wed May 11 07:14:03 2011 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 6C903E069E for ; Wed, 11 May 2011 07:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDzgMne+6+02 for ; Wed, 11 May 2011 07:14:02 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id B4217E0685 for ; Wed, 11 May 2011 07:14:02 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id D56AD273; Wed, 11 May 2011 07:13:30 -0700 (PDT) From: Wes Hardaker To: Stephane Bortzmeyer References: <20110511080159.GA13132@nic.fr> Date: Wed, 11 May 2011 07:13:30 -0700 In-Reply-To: <20110511080159.GA13132@nic.fr> (Stephane Bortzmeyer's message of "Wed, 11 May 2011 10:01:59 +0200") Message-ID: User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsext@ietf.org Subject: Re: [dnsext] dnsextDNSSEC, robustness, and several DS records 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, 11 May 2011 14:14:03 -0000 >>>>> On Wed, 11 May 2011 10:01:59 +0200, Stephane Bortzmeyer said: SB> But it seems there is an "exception". RFC 4509, section 3, says that SB> DS hashed with SHA-1 must be ignored when there is a DS for the same SB> key hashed with SHA-2. This is to avoid downgrade attacks. Well, the reasons the WG decided to go that route at the time was there is no way to ensure better security if you want better security and your client is capable of it. That last part of the sentence is the key (ha ha) to understanding the real problem. There is no signaling bit, from the publisher, to say that you want people to only use the SHA256 record. Thus, the RFC specifies this policy as the default: "Validator implementations SHOULD ignore DS RRs containing SHA-1 digests if DS RRs with SHA-256 digests are present in the DS RRset." Because there is no signaling bit, we end up in three cases: 1) The zone publisher doesn't care which record is used. Currently this isn't possible. * A SHA1 record exists * A SHA256 record exists Right now, the above SHOULD indicates you should only use the SHA256 if you understand the SHA256. 2) The zone publisher *wants* everyone to upgrade, but cares about the clients that don't understand a SHA256 DS yet. * A SHA1 record exists * A SHA256 record exists This is the case the WG deemed more important than case 1. Thus, the document STRONGLY ENCOURAGES people to only use the SHA256 record if they can understand it. 3) The zone publisher *requires* everyone to upgrade, but cares about the clients that don't understand a SHA256 DS yet. * A SHA256 record exists That's really the only bit that zone publishers can control: publish the SHA1 record or not? If there was a way to publish the SHA1 record *and* a bit that said "use anything you understand" this would be easier. But there isn't a way to do that. So we need to pick, in the document, between which is more important: #1 or #2. We picked #2. -- Wes Hardaker Cobham Analytic Solutions From jabley@hopcount.ca Wed May 11 07:19:02 2011 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 2FAE7E0726 for ; Wed, 11 May 2011 07:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5X2ra5GhS8PV for ; Wed, 11 May 2011 07:19:01 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by ietfa.amsl.com (Postfix) with ESMTP id C492CE06F6 for ; Wed, 11 May 2011 07:19:00 -0700 (PDT) Received: from [2001:4900:1042:100:5a55:caff:feec:96bf] (helo=krill.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QKAFd-000M8z-EE; Wed, 11 May 2011 14:18:58 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <4DC94AE6.5000903@ogud.com> Date: Wed, 11 May 2011 10:18:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DC94AE6.5000903@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 2001:4900:1042:100:5a55:caff:feec:96bf X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC ENDS0-bis 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, 11 May 2011 14:19:02 -0000 On 2011-05-10, at 10:25, Olafur Gudmundsson wrote: > Please send statements that you have reviewed this document and if it = raised any issues. Remember we need 5 a minimum of 5 reviewers to say = they reviewed the document. Summary Lots of nits below, some (to me, at least) somewhat substantial. I would = like to see some edits before the document is sent up the tree, since I = think there is some low-level ambiguity in the text and if the goal is = clarification then these seem worthy of fixing. I'm happy to work with the authors on specific text where there is = consensus to edit if that seems helpful. Abstract "based on 10 years of deployment experience" seems like an empty phrase = in the absence of citations of any study of EDNS0 penetration. I would = delete it. Section 1 ("Introduction") "The maximum allowable size of a DNS Message is limited to 512 bytes". = This is not true in general (it's true for DNS messages sent using UDP = transport without EDNS0). "uses which are commom [typo, sic] or desired to become common" is = grammatically inelegant and unsupported. Desired by whom? Perhaps better = to cite specific examples and avoid expressing unsubstantiated desire. "RFC 1035 does not define any way for implementations to advertise their = capabilities". Since the DNS protocol is variously implemented for = different purposes (resolver, authority-only server, update client, etc) = it might be better to re-cast this as "[RFC 1035] does not provide any = mechanism for capabilities negotiation between DNS clients and servers". "[RFC2671]" seems to be bare ASCII rather than a reference (this is more = obvious in the HTML rendering of the document). "This document Obsoletes Extended Labels". Obsoletes, or deprecates? Section 2 ("Terminology") Various terms are capitalised as if they are defined phrases, but do not = appear in Section 2 ("Terminology"). Examples include "Message Format", = "DNS Message", "DNS Message Header", "Traditional DNS Messages", = "Extended Label Types", "Option Codes", "(Un)extended agents", = "(Un)extended DNS". As noted elsewhere, "Middleware Boxes" could do with = a definition. Section 3 ("EDNS Support Requirement") "practically mandatory in a modern world" is subjective and ambiguous. = The section would benefit from the normative language being spelt out in = its own paragraph, and the justification/preamble being re-cast to avoid = subjective phrases and instead call out specific examples (e.g. from = DNSSEC and ENUM) for which EDNS is necessary or useful. Section 4.3 ("UDP Message Size") "Today"? "many organizations"? "special tricks"? Given that DNSSEC requires an EDNS0 pseudo-header in a request in order = to react to DO=3D1, is it a suitable example to justify the existence of = EDNS0 at all? An unextended DNS message can't be used for secure answers = anyway. I'm not explaining myself very well, but it seems like there's = some avoidable chicken/egg juxtaposition here. Section 5 ("Extended Label Types") "obsoleted" or "deprecated"? What is the required action of DNS = Requestors and Responders who receive messages that contain extended = label types? The direction to the IANA seems out of place in this section (perhaps = replace with an xref to Section 9). Section 6.1 ("OPT Record Definition") Several aspects of the OPT RR are defined in later sub-sections of = section 6, so 6.1's title seems not entirely appropriate. Section 6.5 ("Requestor's Payload Size") The second paragraph has me scratching my head, since it implies that a = requestor has knowledge about the cleanliness of the UDP/IP path to a = server without describing how it acquires that knowledge. Some guidance = about how requestors might probe each path in order to establish a = sensible payload size seems appropriate. I appreciate there is some more detailed guidance in 6.7; perhaps that = could be extended and an xref placed in 6.5, or perhaps this section = could become a subsection of 6.7. Section 6.6 ("Responder's Payload Size") There is algorithmic guidance given in this section to allow an = implementor to choose a suitable payload size, but it seems vague (e.g. = "meaningless QUERY"). More specific guidance seems like it would be = helpful. I appreciate there is some more detailed guidance in 6.7; perhaps that = could be extended and an xref placed in 6.6, or perhaps this section = could become a subsection of 6.7. Section 6.7 ("Payload Size Selection") See above. Section 6.8 ("Middleware Boxes") See above regarding definition of "Middleware Boxes". (Incidentally, = "Middleware" as a noun seems better to me, once defined, than = "Middleware Boxes".) Is the prohibition on limiting UDP-transport DNS messages to 512 bytes = by middleware necessary in the case where middleware performing deep = packet inspection knowns unequivocally that it is dealing with an = unextended DNS message? "MUST understand the OPT record" -- do you mean to say that such devices = must support EDNS0? There's a difference between understanding and = processing. Section 6.11 ("OPT Options Code Allocation Procedure") Shouldn't this direction be moved to the IANA Considerations section, = since it describes an attribute of a registry? Section 9 ("IANA Considerations") "EDNS Extended Label Type", "EDNS Option Codes", "EDNS Version Numbers", = and "Domain System Response Code" are not the names of the registries = created by RFC 2671, at least not as seen at = (unless I'm reading it wrong). Since = this section contains direction for the IANA, it seems appropriate to = make sure the registries referred to are unambiguously-named. Worth = checking, anyway. "IANA is advised to re-parent these sub-registries to this document", "We request that this registry be closed" -- I don't know that "closed" or "re-parent" are sufficiently unambiguous = when it comes to describing an action on a registry. Does "closed" mean = that the registry should no longer accept additions, or that it should = be deleted such that nobody can find it any more? Does "re-parent" imply = that the requirements for changes to the registry (e.g. "RFC Required", = "IESG Approval") are inherited, and that the existing contents of the = registry should be preserved? No doubt any ambiguity would be cleaned up during IANA review of the = document, but it doesn't hurt to get it right first time. "This document assigns EDNS Extended RCODE 16 to 'BADVERS'" -- it seems = like a good idea to specify precisely which registry the document is = requesting be updated, here. In general a quick review of RFC 5226 might help clean up this section. Joe= From paul.hoffman@vpnc.org Wed May 11 07:27:56 2011 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 5A019E0728 for ; Wed, 11 May 2011 07:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+ugJBS8bd3X for ; Wed, 11 May 2011 07:27:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 611F6E0685 for ; Wed, 11 May 2011 07:27:52 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4BERoOU013212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 May 2011 07:27:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110511080159.GA13132@nic.fr> Date: Wed, 11 May 2011 07:27:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <63381BB3-7552-4721-B334-CFE292AA9465@vpnc.org> References: <20110511080159.GA13132@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 11 May 2011 14:27:56 -0000 On May 11, 2011, at 1:01 AM, Stephane Bortzmeyer wrote: > A recent incident lead me to re-study the question of "what a > validating resolver must/should do when there are several DS and some > are invalid in some way?" AFAIK (I would be glad to be corrected > here), the best common practice is to be lax ("DNSSEC is hard enough, > accept any DS"), following RFC 4035, section 2.4 and 5.3.1. >=20 > But it seems there is an "exception". RFC 4509, section 3, says that > DS hashed with SHA-1 must be ignored when there is a DS for the same > key hashed with SHA-2. This is to avoid downgrade attacks. >=20 > In the incident I was talking about, there were two DS for the same > KSK key, one hashed with SHA-1 and one with SHA-256 and the second one > was invalid, because of a bug (wrong Algorithm field). As a result, > both BIND and Unbound, following RFC 4509, returned a SERVFAIL, while > there was another and perfectly valid DS record. Note that the text in RFC 4509 has a SHOULD, not a MUST. The fact that = the BIND and Unbound people treat it as a MUST seems like a bug. > I question this rule: SHA-1 (as it is used for DNSSEC) is not broken Correct. > and the risk of downgrade attacks is ridiculous when you compare, both > to the other attacks on DNSSEC, and to the risk of creating an > error. Correct.=20 > Isn't it a case of excess security, which will turn people away > from DNSSEC (too much risk of breakage)? No, because it adds no security, so it cannot be "excess security". It = feels more like a case of a spec with a SHOULD that does not include = guidance on when to consider an exception. If people here want to revise = RFC 4509 to reflect security practices that balance risk from known = attacks against cost to attackers, I would propose changing: Validator implementations SHOULD ignore DS RRs containing SHA-1 digests if DS RRs with SHA-256 digests are present in the DS RRset. to: If there is a known preimage attack on SHA-1 that reduces its effective strength to less than 128 bits, validator implementations SHOULD ignore DS RRs containing SHA-1 digests if DS RRs with SHA-256 digests are present in the DS RRset. --Paul Hoffman From alex@alex.org.uk Wed May 11 07:28:23 2011 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 3686CE0771 for ; Wed, 11 May 2011 07:28:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnBZ5mJj5aGs for ; Wed, 11 May 2011 07:28:22 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by ietfa.amsl.com (Postfix) with ESMTP id 8816BE0758 for ; Wed, 11 May 2011 07:28:22 -0700 (PDT) Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 80BC5C560D8; Wed, 11 May 2011 15:28:20 +0100 (BST) Date: Wed, 11 May 2011 15:28:19 +0100 From: Alex Bligh To: Joe Abley , Olafur Gudmundsson Message-ID: In-Reply-To: References: <4DC94AE6.5000903@ogud.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC ENDS0-bis X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 14:28:23 -0000 --On 11 May 2011 10:18:52 -0400 Joe Abley wrote: > Section 6.8 ("Middleware Boxes") > > See above regarding definition of "Middleware Boxes". (Incidentally, > "Middleware" as a noun seems better to me, once defined, than "Middleware > Boxes".) Do we really mean "Middleware boxes" (which presumably means boxes that run Middleware) or do we mean "Middleboxes" (boxes that sit between client and server doing unspeakable things to packets, the software on which is certainly not middleware). I think we mean "Middleboxes". There is a taxonomy of Middleboxes/Middleboxen in http://tools.ietf.org/html/rfc3234 which might (or might not) help any definitional issue. -- Alex Bligh From brian.peter.dickson@gmail.com Wed May 11 07:28:36 2011 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 EB5CBE07B6 for ; Wed, 11 May 2011 07:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1y8hZgxbwkj for ; Wed, 11 May 2011 07:28:36 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A4AB6E0703 for ; Wed, 11 May 2011 07:28:35 -0700 (PDT) Received: by fxm15 with SMTP id 15so494197fxm.31 for ; Wed, 11 May 2011 07:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0Q/4eTeVQ0UnbVORur8TAQVRw3QuzKaLKYB9d8qBI7A=; b=LqXn39d+nWB6O+Ui/cOn99OAE+/oPPoVwgq/WM3c3GEH3VTQilV5pKa+FVNKZi4r0D 4sCI21WD9mPCiZhVCsuhd6Zv95aRMfYvl2evC5yS9PZHU0tzM1V2XFtBbNm0Z8jRnq1K U1WDUlOeAQPVRfTwWVhLm/weXScpvW2/787CQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wbQfgIwDxUwoO9R+e8t6nUQFCTN/KfsN01Ja5nRWn9NLQ0sKahl2JxiVjnNid+GHVI hcCGwib+DIEat0/zkZFbocdk8DyFGgfZV+MOHk+fvpNBBS2A4u//HH41/5lmBGeyxzDR TzSAta2hmd1A4B78DXK7LeP5LZ1i/G1pixCd0= MIME-Version: 1.0 Received: by 10.223.29.132 with SMTP id q4mr728569fac.17.1305124113058; Wed, 11 May 2011 07:28:33 -0700 (PDT) Received: by 10.223.120.133 with HTTP; Wed, 11 May 2011 07:28:33 -0700 (PDT) In-Reply-To: <20110511080159.GA13132@nic.fr> References: <20110511080159.GA13132@nic.fr> Date: Wed, 11 May 2011 10:28:33 -0400 Message-ID: From: Brian Dickson To: Stephane Bortzmeyer Content-Type: multipart/alternative; boundary=001517478f04258f3d04a300e3c6 Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 11 May 2011 14:28:37 -0000 --001517478f04258f3d04a300e3c6 Content-Type: text/plain; charset=ISO-8859-1 Here's my take on it: The attack for which the order matters (SHA-256 vs SHA-1) is a forged DNSKEY, if I understand things correctly. The DS records are signed as a single RRSET, so it is in theory impossible to downgrade by blocking one of the DS records, unless you can forge an RRSIG, in which case you're dead in the water anyway. And, the "forged DNSKEY" attack can only succeed if the DS for SHA-1 is used. By "forged", we mean a hash-colliding DNSKEY whose private keys we know. Hash-colliding is hash-specific, so only one DS can be spoofed at a time. If DS records using SHA-256 and SHA-1 are both present and valid, using SHA-256 makes the attack fail. If only SHA-1 is present, the attack will succeed. (Again, this is mostly hypothetical, as I understand it, i.e. that a forged SHA-1 has not been demonstrated, as far as I know, which may not be very far. ;-)) I would interpret the rule of (SHA-256 over SHA-1) as using the following method: (1) Take all your DS records, in whatever order they were returned or in whatever order your local policy says to prefer them. (2) If SHA-1 occurs before SHA-256 in the list, move SHA-1 or SHA-256 so that their relative position in the list is swapped, i.e. that SHA-256 occurs before SHA-1. (3) Go down the list, and attempt to validate the DNSKEY. Stop when you succeed. If you fail all (fall through the end of the list), mark the zone as (whatever is correct for this condition - bogus?) While it is potentially susceptible to attack, it is still technically secure. Given that the data is likely to be present on all authoritative servers for the zone, SERVFAIL is definitely not a good answer, IMHO. And, if both SHA-256 and SHA-1 are present *and valid*, the downgrade is prevented. Brian On Wed, May 11, 2011 at 4:01 AM, Stephane Bortzmeyer wrote: > A recent incident lead me to re-study the question of "what a > validating resolver must/should do when there are several DS and some > are invalid in some way?" AFAIK (I would be glad to be corrected > here), the best common practice is to be lax ("DNSSEC is hard enough, > accept any DS"), following RFC 4035, section 2.4 and 5.3.1. > > But it seems there is an "exception". RFC 4509, section 3, says that > DS hashed with SHA-1 must be ignored when there is a DS for the same > key hashed with SHA-2. This is to avoid downgrade attacks. > > In the incident I was talking about, there were two DS for the same > KSK key, one hashed with SHA-1 and one with SHA-256 and the second one > was invalid, because of a bug (wrong Algorithm field). As a result, > both BIND and Unbound, following RFC 4509, returned a SERVFAIL, while > there was another and perfectly valid DS record. > > I question this rule: SHA-1 (as it is used for DNSSEC) is not broken > and the risk of downgrade attacks is ridiculous when you compare, both > to the other attacks on DNSSEC, and to the risk of creating an > error. Isn't it a case of excess security, which will turn people away > from DNSSEC (too much risk of breakage)? > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --001517478f04258f3d04a300e3c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here's my take on it:

The attack for which the order matters (SH= A-256 vs SHA-1) is a forged DNSKEY, if I understand things correctly.
Th= e DS records are signed as a single RRSET, so it is in theory impossible to= downgrade by blocking one of the DS records, unless you can forge an RRSIG= , in which case you're dead in the water anyway.

And, the "forged DNSKEY" attack can only succeed if the DS fo= r SHA-1 is used. By "forged", we mean a hash-colliding DNSKEY who= se private keys we know. Hash-colliding is hash-specific, so only one DS ca= n be spoofed at a time.

If DS records using SHA-256 and SHA-1 are both present and valid, using= SHA-256 makes the attack fail.

If only SHA-1 is present, the attack= will succeed.

(Again, this is mostly hypothetical, as I understand = it, i.e. that a forged SHA-1 has not been demonstrated, as far as I know, w= hich may not be very far. ;-))

I would interpret the rule of (SHA-256 over SHA-1) as using the followi= ng method:
(1) Take all your DS records, in whatever order they were ret= urned or in whatever order your local policy says to prefer them.
(2) If= SHA-1 occurs before SHA-256 in the list, move SHA-1 or SHA-256 so that the= ir relative position in the list is swapped, i.e. that SHA-256 occurs befor= e SHA-1.
(3) Go down the list, and attempt to validate the DNSKEY. Stop when you suc= ceed. If you fail all (fall through the end of the list), mark the zone as = (whatever is correct for this condition - bogus?)

While it is potent= ially susceptible to attack, it is still technically secure.

Given that the data is likely to be present on all authoritative server= s for the zone, SERVFAIL is definitely not a good answer, IMHO.

And,= if both SHA-256 and SHA-1 are present *and valid*, the downgrade is preven= ted.

Brian

On Wed, May 11, 2011 at 4:01 AM= , Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
A recent incident lead me to re-study the question of "what a
validating resolver must/should do when there are several DS and some
are invalid in some way?" AFAIK (I would be glad to be corrected
here), the best common practice is to be lax ("DNSSEC is hard enough,<= br> accept any DS"), following RFC 4035, section 2.4 and 5.3.1.

But it seems there is an "exception". RFC 4509, section 3, says t= hat
DS hashed with SHA-1 must be ignored when there is a DS for the same
key hashed with SHA-2. This is to avoid downgrade attacks.

In the incident I was talking about, there were two DS for the same
KSK key, one hashed with SHA-1 and one with SHA-256 and the second one
was invalid, because of a bug (wrong Algorithm field). As a result,
both BIND and Unbound, following RFC 4509, returned a SERVFAIL, while
there was another and perfectly valid DS record.

I question this rule: SHA-1 (as it is used for DNSSEC) is not broken
and the risk of downgrade attacks is ridiculous when you compare, both
to the other attacks on DNSSEC, and to the risk of creating an
error. Isn't it a case of excess security, which will turn people away<= br> from DNSSEC (too much risk of breakage)?
_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext

--001517478f04258f3d04a300e3c6-- From wouter@nlnetlabs.nl Wed May 11 07:28:59 2011 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 8864DE07DA for ; Wed, 11 May 2011 07:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWAFNx7DqTx9 for ; Wed, 11 May 2011 07:28:58 -0700 (PDT) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by ietfa.amsl.com (Postfix) with ESMTP id 5B80CE0728 for ; Wed, 11 May 2011 07:28:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id DE66D581B7 for ; Wed, 11 May 2011 16:28:52 +0200 (CEST) Received: from [192.168.254.2] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 67C6B58CF6 for ; Wed, 11 May 2011 16:28:44 +0200 (CEST) Message-ID: <4DCA9D12.9080402@nlnetlabs.nl> Date: Wed, 11 May 2011 16:28:34 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110414 SUSE/3.1.10 Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110511080159.GA13132@nic.fr> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at rotring X-Virus-Status: Clean Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 11 May 2011 14:28:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 05/11/2011 03:57 PM, Edward Lewis wrote: > At 10:01 +0200 5/11/11, Stephane Bortzmeyer wrote: >> But it seems there is an "exception". RFC 4509, section 3, says that >> DS hashed with SHA-1 must be ignored when there is a DS for the same >> key hashed with SHA-2. This is to avoid downgrade attacks. > > The overriding policy is still "local policy rules." It is fine for the The policy that unbound uses for DS hash algorithm is this: it picks its favorite (i.e. the strongest) algorithm from the set of available ones, and ignores the others. This works for algorithms other than SHA1 and SHA2, and gives RFC 4509 behaviour for SHA1 and SHA2. There would be algorithm protection if you checked all the available DS hash algorithms. But we did not implement this because RFC 4509 says otherwise. The favorite DS hash algorithm for unbound is the one with the highest DS algorithm number. This is an implementation trick. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNyp0SAAoJEJ9vHC1+BF+Ncv8P/2IkN1ovzAMtgqYDRRtXzT1L awaQxBtLByMguW/zlfU+AqaD+H6w2xGXtWQusv921XzjplsHt7iHQY4veR93lK0A g9VliN84QyRX3WFcLoIJ7Cu9hisZ6dPv/GICExDnu+MZWXusQB/9xs9Y9cOkt21U 4BKbulL+Heew938ivCs0euzhLwHcIO6sAXcl9IgQDyybBBtNO5lbEeG88D1bUYvw sDYuXbM6DkOwPovH+Jdix2w1I3lakmxUtFowvgjSazcpnLN1Zqn4gx8/UZmwOzG8 PCphylZwumbgmLvLG8wpWxRAisYq/7915mVj3yv4848Ke3y5PklPTUSDyzmp/P9B 2ljE+A2sSfVcrUAcgI0pj1gQHOpl1LibzSJdIvclg4VFrfZLOUIEog8DIGE0zucc U1m9UtPnZDlEwNFQu/UUQpEOP0a1/n7mESIj2Z5B8/ZNM39t6uICn8lKWmzcvybk RCQRcQ+CAhlrMBxXC2aZ0X6ibvJN40XHKXS+cmJwQ4HDNpi2saUckVwtlxxBy/cR YrGWXQUTu9vG+SAl4VXN2Qpr+uKV11VfG1XBjGqeelGBQtORWgI2K9lmaUpgl6cr dOSP9JIe6PoLzRQYO97AJpiZZPMcvIHHfRTo3L9QcGqiBGXaQtkXxBfHXFlp4tnW m8JLnHSXuLbdJr1QfB+x =8NI6 -----END PGP SIGNATURE----- From joao@bondis.org Wed May 11 07:35:45 2011 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 C2A7DE0789 for ; Wed, 11 May 2011 07:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY6OL7+wQCo8 for ; Wed, 11 May 2011 07:35:44 -0700 (PDT) Received: from smtp1.bondis.org (voyager.c-l-i.net [194.176.119.229]) by ietfa.amsl.com (Postfix) with ESMTP id 30940E0750 for ; Wed, 11 May 2011 07:35:43 -0700 (PDT) Received: from [192.168.2.36] (82.158.254.126.dyn.user.ono.com [82.158.254.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.bondis.org (Postfix) with ESMTPSA id B7F6D1AB301; Wed, 11 May 2011 14:35:41 +0000 (UTC) References: <4DC94AE6.5000903@ogud.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: =?iso-8859-1?Q?Jo=E3o_Damas?= Date: Wed, 11 May 2011 16:35:40 +0200 To: Joe Abley X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] WGLC ENDS0-bis 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, 11 May 2011 14:35:45 -0000 thanks all for the comments. I will be doing an extra pass on the doc = beginning on Monday so all comments are welcome, particularly those that = point to ambiguity or any mistakes that slipped through (style being a = more personal matter) Joao On 11 May 2011, at 16:18, Joe Abley wrote: >=20 > On 2011-05-10, at 10:25, Olafur Gudmundsson wrote: >=20 >> Please send statements that you have reviewed this document and if it = raised any issues. Remember we need 5 a minimum of 5 reviewers to say = they reviewed the document. >=20 > Summary >=20 > Lots of nits below, some (to me, at least) somewhat substantial. I = would like to see some edits before the document is sent up the tree, = since I think there is some low-level ambiguity in the text and if the = goal is clarification then these seem worthy of fixing. >=20 > I'm happy to work with the authors on specific text where there is = consensus to edit if that seems helpful. >=20 > Abstract >=20 > "based on 10 years of deployment experience" seems like an empty = phrase in the absence of citations of any study of EDNS0 penetration. I = would delete it. >=20 > Section 1 ("Introduction") >=20 > "The maximum allowable size of a DNS Message is limited to 512 bytes". = This is not true in general (it's true for DNS messages sent using UDP = transport without EDNS0). >=20 > "uses which are commom [typo, sic] or desired to become common" is = grammatically inelegant and unsupported. Desired by whom? Perhaps better = to cite specific examples and avoid expressing unsubstantiated desire. >=20 > "RFC 1035 does not define any way for implementations to advertise = their capabilities". Since the DNS protocol is variously implemented for = different purposes (resolver, authority-only server, update client, etc) = it might be better to re-cast this as "[RFC 1035] does not provide any = mechanism for capabilities negotiation between DNS clients and servers". >=20 > "[RFC2671]" seems to be bare ASCII rather than a reference (this is = more obvious in the HTML rendering of the document). >=20 > "This document Obsoletes Extended Labels". Obsoletes, or deprecates? >=20 > Section 2 ("Terminology") >=20 > Various terms are capitalised as if they are defined phrases, but do = not appear in Section 2 ("Terminology"). Examples include "Message = Format", "DNS Message", "DNS Message Header", "Traditional DNS = Messages", "Extended Label Types", "Option Codes", "(Un)extended = agents", "(Un)extended DNS". As noted elsewhere, "Middleware Boxes" = could do with a definition. >=20 > Section 3 ("EDNS Support Requirement") >=20 > "practically mandatory in a modern world" is subjective and ambiguous. = The section would benefit from the normative language being spelt out in = its own paragraph, and the justification/preamble being re-cast to avoid = subjective phrases and instead call out specific examples (e.g. from = DNSSEC and ENUM) for which EDNS is necessary or useful. >=20 > Section 4.3 ("UDP Message Size") >=20 > "Today"? "many organizations"? "special tricks"? >=20 > Given that DNSSEC requires an EDNS0 pseudo-header in a request in = order to react to DO=3D1, is it a suitable example to justify the = existence of EDNS0 at all? An unextended DNS message can't be used for = secure answers anyway. I'm not explaining myself very well, but it seems = like there's some avoidable chicken/egg juxtaposition here. >=20 > Section 5 ("Extended Label Types") >=20 > "obsoleted" or "deprecated"? What is the required action of DNS = Requestors and Responders who receive messages that contain extended = label types? >=20 > The direction to the IANA seems out of place in this section (perhaps = replace with an xref to Section 9). >=20 > Section 6.1 ("OPT Record Definition") >=20 > Several aspects of the OPT RR are defined in later sub-sections of = section 6, so 6.1's title seems not entirely appropriate. >=20 > Section 6.5 ("Requestor's Payload Size") >=20 > The second paragraph has me scratching my head, since it implies that = a requestor has knowledge about the cleanliness of the UDP/IP path to a = server without describing how it acquires that knowledge. Some guidance = about how requestors might probe each path in order to establish a = sensible payload size seems appropriate. >=20 > I appreciate there is some more detailed guidance in 6.7; perhaps that = could be extended and an xref placed in 6.5, or perhaps this section = could become a subsection of 6.7. >=20 > Section 6.6 ("Responder's Payload Size") >=20 > There is algorithmic guidance given in this section to allow an = implementor to choose a suitable payload size, but it seems vague (e.g. = "meaningless QUERY"). More specific guidance seems like it would be = helpful. >=20 > I appreciate there is some more detailed guidance in 6.7; perhaps that = could be extended and an xref placed in 6.6, or perhaps this section = could become a subsection of 6.7. >=20 > Section 6.7 ("Payload Size Selection") >=20 > See above. >=20 > Section 6.8 ("Middleware Boxes") >=20 > See above regarding definition of "Middleware Boxes". (Incidentally, = "Middleware" as a noun seems better to me, once defined, than = "Middleware Boxes".) >=20 > Is the prohibition on limiting UDP-transport DNS messages to 512 bytes = by middleware necessary in the case where middleware performing deep = packet inspection knowns unequivocally that it is dealing with an = unextended DNS message? >=20 > "MUST understand the OPT record" -- do you mean to say that such = devices must support EDNS0? There's a difference between understanding = and processing. >=20 > Section 6.11 ("OPT Options Code Allocation Procedure") >=20 > Shouldn't this direction be moved to the IANA Considerations section, = since it describes an attribute of a registry? >=20 > Section 9 ("IANA Considerations") >=20 > "EDNS Extended Label Type", "EDNS Option Codes", "EDNS Version = Numbers", and "Domain System Response Code" are not the names of the = registries created by RFC 2671, at least not as seen at = (unless I'm reading it wrong). Since = this section contains direction for the IANA, it seems appropriate to = make sure the registries referred to are unambiguously-named. Worth = checking, anyway. >=20 > "IANA is advised to re-parent these sub-registries to this document", > "We request that this registry be closed" -- >=20 > I don't know that "closed" or "re-parent" are sufficiently unambiguous = when it comes to describing an action on a registry. Does "closed" mean = that the registry should no longer accept additions, or that it should = be deleted such that nobody can find it any more? Does "re-parent" imply = that the requirements for changes to the registry (e.g. "RFC Required", = "IESG Approval") are inherited, and that the existing contents of the = registry should be preserved? >=20 > No doubt any ambiguity would be cleaned up during IANA review of the = document, but it doesn't hurt to get it right first time. >=20 > "This document assigns EDNS Extended RCODE 16 to 'BADVERS'" -- it = seems like a good idea to specify precisely which registry the document = is requesting be updated, here. >=20 > In general a quick review of RFC 5226 might help clean up this = section. >=20 >=20 > Joe > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From Ed.Lewis@neustar.biz Wed May 11 09:39:28 2011 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 AB391E07EC for ; Wed, 11 May 2011 09:39:28 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XAWUVS1ZWcE for ; Wed, 11 May 2011 09:39:28 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6B110E07D1 for ; Wed, 11 May 2011 09:39:27 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p4BGdPuT092284; Wed, 11 May 2011 12:39:26 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.215] by Work-Laptop-2.local (PGP Universal service); Wed, 11 May 2011 12:39:26 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 11 May 2011 12:39:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20110511080159.GA13132@nic.fr> Date: Wed, 11 May 2011 12:39:23 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] dnsextDNSSEC, robustness, and several DS records 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, 11 May 2011 16:39:28 -0000 At 7:13 -0700 5/11/11, Wes Hardaker wrote: >1) The zone publisher doesn't care which record is used... >2) The zone publisher *wants* everyone to upgrade... >3) The zone publisher *requires* everyone to upgrade... The zone publisher's wishes don't matter to DNSSEC. DNSSEC is there to protect caches, first and foremost and that is what the protocol is designed to do. The protocol does not convey the publishers wishes in any field. "Trying to teach a pig to sing will just annoy the pig." DNSSEC is the pig. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From george.barwood@blueyonder.co.uk Wed May 11 10:28:31 2011 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 5726BE073C for ; Wed, 11 May 2011 10:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFX8E-hJYMk8 for ; Wed, 11 May 2011 10:28:30 -0700 (PDT) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by ietfa.amsl.com (Postfix) with ESMTP id C6E70E06D5 for ; Wed, 11 May 2011 10:28:29 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.3]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110511172820.OFZT3152.mtaout03-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Wed, 11 May 2011 18:28:20 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1QKDCu-0002rk-AP; Wed, 11 May 2011 18:28:20 +0100 Message-ID: From: "George Barwood" To: "Paul Hoffman" , "Stephane Bortzmeyer" References: <20110511080159.GA13132@nic.fr> <63381BB3-7552-4721-B334-CFE292AA9465@vpnc.org> Date: Wed, 11 May 2011 18:28:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=iKl8fF4JqUIA:10 a=3NElcqgl2aoA:10 a=8nJEP1OIZ-IA:10 a=48vgC7mUAAAA:8 a=5-SuON1zi9r7fMb6-tAA:9 a=wPNLvfGTeEIA:10 a=HXXqCD0uysUA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 11 May 2011 17:28:31 -0000 PiAgIElmIHRoZXJlIGlzIGEga25vd24gcHJlaW1hZ2UgYXR0YWNrIG9uIFNIQS0xIHRoYXQgcmVk dWNlcyBpdHMNCj4gICBlZmZlY3RpdmUgc3RyZW5ndGggdG8gbGVzcyB0aGFuIDEyOCBiaXRzLA0K PiAgIHZhbGlkYXRvciBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGlnbm9yZSBEUyBSUnMgY29udGFp bmluZyBTSEEtMQ0KPiAgIGRpZ2VzdHMgaWYgRFMgUlJzIHdpdGggU0hBLTI1NiBkaWdlc3RzIGFy ZSBwcmVzZW50IGluIHRoZSBEUyBSUnNldC4NCg0KVGhlIHByb2JsZW0gaXMgdGhhdCB3ZSBkb24n dCBrbm93IGlmIHN1Y2ggYXR0YWNrcyBleGlzdCwgYW5kIG1vcmUgcHJhY3RpY2FsbHkNCml0J3Mg aGFyZCB0byB1cGRhdGUgc29mdHdhcmUuIFNvIGl0IHNlZW1zIGJldHRlciB0byBwbGFuIGZvciB0 aGUgd29yc3QuDQoNCkJlc2lkZXMsIGltcGxlbWVudGF0aW9ucyBtYXkgd2FudCB0byB1c2UgZHVh bCBhbGdvcml0aG1zLCBmb3IgZXhhbXBsZQ0KZWxsaXB0aWMgY3VydmUgcGx1cyBSU0Egd2l0aCBh IG1vZGVyYXRlIHNpemUga2V5LCBvbiB0aGUgYmFzaXMgdGhhdCBpdCdzDQp1bmxpa2VseSB0aGF0 IGFueW9uZSB3b3VsZCBiZSBhYmxlIHRvIGJyZWFrIGJvdGguDQoNCkkgcmVhbGx5IGRvdWJ0IGhh dmluZyByZXNvbHZlcnMgdHJ5aW5nIHRvIGZpeCB1cCBkYXRhIGVycm9ycyBpcyB0aGUgd2F5IGZv cndhcmQuDQoNCkkgdGhpbmsgdGhlIHJlYWwgZml4IGZvciBtaXNoYXBzIHVwbG9hZGluZyBEUyBy ZWNvcmRzIGlzIHRvIGhhdmUgYmV0dGVyDQppbi1wcm90b2NvbCBzdXBwb3J0LiBUaGUgcHJvcG9z ZWQgQ0RTIFJSdHlwZSBpcyBhaW1lZCBhdCB0aGlzIDoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL2Ruc2V4dC9jdXJyZW50L21zZzEwOTAwLmh0bWwNCg0KR2VvcmdlDQo= From paul.hoffman@vpnc.org Wed May 11 10:52:15 2011 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 4C336E0871 for ; Wed, 11 May 2011 10:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFZwrHIE3yXh for ; Wed, 11 May 2011 10:52:14 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 44608E0876 for ; Wed, 11 May 2011 10:52:14 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4BHqAAM023840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 May 2011 10:52:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman X-Priority: 3 In-Reply-To: Date: Wed, 11 May 2011 10:52:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <41FE5ADA-EDF1-45B2-8149-9CD0DA1E6929@vpnc.org> References: <20110511080159.GA13132@nic.fr> <63381BB3-7552-4721-B334-CFE292AA9465@vpnc.org> To: George Barwood X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 11 May 2011 17:52:15 -0000 On May 11, 2011, at 10:28 AM, George Barwood wrote: >> If there is a known preimage attack on SHA-1 that reduces its >> effective strength to less than 128 bits, >> validator implementations SHOULD ignore DS RRs containing SHA-1 >> digests if DS RRs with SHA-256 digests are present in the DS RRset. >=20 > The problem is that we don't know if such attacks exist, and more = practically > it's hard to update software. The first phrase is not true, and the second is not terribly relevant. - There have been no known preimage attacks on SHA-1. When there is, the = world will hear about it. And, before you say "but we might not hear = about it", please understand that you can say exactly the same thing = about RSA signatures themselves. Either you live with "the crypto = experts will tell us when some component is unsafe", or you just freeze = and don't do anything. - If there is a preimage attack on SHA-1, or a much better attack on = RSA, or...or...or..., then the software will have to be updated. It will = will be hard to do so in some cases, but not in others. > So it seems better to plan for the worst. That logic leads to banning SHA-1 outright immediately. And yet the WG = (correctly, IMNSHO) decided not to. > Besides, implementations may want to use dual algorithms, for example > elliptic curve plus RSA with a moderate size key, on the basis that = it's > unlikely that anyone would be able to break both. To date, the tools used to weaken hashes are not the same as those used = to weaken signature algorithms, so this sentence doesn't make sense in = the current world. > I really doubt having resolvers trying to fix up data errors is the = way forward. Fully agree. --Paul Hoffman From wjhns1@hardakers.net Wed May 11 11:49:20 2011 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 41E5FE06F5 for ; Wed, 11 May 2011 11:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMAuL4zEHhOE for ; Wed, 11 May 2011 11:49:19 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id BE0FEE0693 for ; Wed, 11 May 2011 11:49:19 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 83D64201; Wed, 11 May 2011 11:48:48 -0700 (PDT) From: Wes Hardaker To: Edward Lewis References: <20110511080159.GA13132@nic.fr> Date: Wed, 11 May 2011 11:48:48 -0700 In-Reply-To: (Edward Lewis's message of "Wed\, 11 May 2011 12\:39\:23 -0400") Message-ID: User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsext@ietf.org Subject: Re: [dnsext] dnsextDNSSEC, robustness, and several DS records 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, 11 May 2011 18:49:20 -0000 >>>>> On Wed, 11 May 2011 12:39:23 -0400, Edward Lewis said: >> 1) The zone publisher doesn't care which record is used... >> 2) The zone publisher *wants* everyone to upgrade... >> 3) The zone publisher *requires* everyone to upgrade... EL> The zone publisher's wishes don't matter to DNSSEC. DNSSEC is there EL> to protect caches, first and foremost and that is what the protocol is EL> designed to do. The protocol does not convey the publishers wishes in EL> any field. That's another way of stating the problem, yes. The protocol was written to accommodate *one* view point of a publisher. #2. DNSSEC is not a person, so it can't care. Sure. But it only supports #2 and #3. EL> "Trying to teach a pig to sing will just annoy the pig." DNSSEC is the pig. Never said otherwise. -- Wes Hardaker Cobham Analytic Solutions From Francis.Dupont@fdupont.fr Wed May 11 13:22:45 2011 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 18777E06F3 for ; Wed, 11 May 2011 13:22:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT4WFU99xWib for ; Wed, 11 May 2011 13:22:44 -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 4953EE0763 for ; Wed, 11 May 2011 13:22:19 -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 p4BKMHmp010275; Wed, 11 May 2011 22:22:17 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201105112022.p4BKMHmp010275@givry.fdupont.fr> From: Francis Dupont To: Paul Hoffman In-reply-to: Your message of Wed, 11 May 2011 07:27:50 PDT. <63381BB3-7552-4721-B334-CFE292AA9465@vpnc.org> Date: Wed, 11 May 2011 22:22:17 +0200 Sender: Francis.Dupont@fdupont.fr Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 11 May 2011 20:22:45 -0000 In your previous mail you wrote: Note that the text in RFC 4509 has a SHOULD, not a MUST. The fact that the BIND and Unbound people treat it as a MUST seems like a bug. => I don't understand how the SHOULD can be interpreted in order to avoid the "bug" (:-). Seriously you can disagree with RFC 4509 but not about the way it has to be implemented, i.e., your concern is not about what it should be... Regards Francis.Dupont@fdupont.fr From brian.peter.dickson@gmail.com Wed May 11 14:04:07 2011 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 77F3BE06AE for ; Wed, 11 May 2011 14:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EvDHcEccN13 for ; Wed, 11 May 2011 14:04:06 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A53FE0674 for ; Wed, 11 May 2011 14:04:06 -0700 (PDT) Received: by fxm15 with SMTP id 15so766344fxm.31 for ; Wed, 11 May 2011 14:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CoNWubqzWlCVc41znI3yLYrjQnLzWJOGAM6edZLkKUw=; b=tvBAX9TiXTVl3CfBEBsV8T+ImBTjEiV1mWjJZFq7BpSbgKqe7TZcH+eolkC6Z1AGgC Tn7+4Y75gyHcb8EF+hU0TuuTXmQvCdvZK01uUN9CbR9fhkwmYHND0+g7ExZnveTPaEci S0ws8lNoIXHCoY0qpcgaszYEnxkKtR+k+698A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vdo7oa2MSwqGHJSvcm0dKa0vPvhpmceZRrF9jXkVoM9OyR+YARk04tgDGl4fzHOvTq rEESnicUSFCvjLOEmyaq1EOKgrMwSBbwjz0kck4HB57V+fp1pQPM0LmM6tcHcd2+hVK8 VXTwWpTKYgNKXBMO5cUKk4YdM9EFW1i+bJk6c= MIME-Version: 1.0 Received: by 10.223.159.134 with SMTP id j6mr1950499fax.74.1305147845288; Wed, 11 May 2011 14:04:05 -0700 (PDT) Received: by 10.223.120.133 with HTTP; Wed, 11 May 2011 14:04:05 -0700 (PDT) In-Reply-To: <201105112022.p4BKMHmp010275@givry.fdupont.fr> References: <63381BB3-7552-4721-B334-CFE292AA9465@vpnc.org> <201105112022.p4BKMHmp010275@givry.fdupont.fr> Date: Wed, 11 May 2011 17:04:05 -0400 Message-ID: From: Brian Dickson To: Francis Dupont Content-Type: multipart/alternative; boundary=002354186d84b2a2b304a30669c3 Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 11 May 2011 21:04:07 -0000 --002354186d84b2a2b304a30669c3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 11, 2011 at 4:22 PM, Francis Dupont wrote: > In your previous mail you wrote: > > Note that the text in RFC 4509 has a SHOULD, not a MUST. The fact > that the BIND and Unbound people treat it as a MUST seems like a > bug. > > => I don't understand how the SHOULD can be interpreted in order to > avoid the "bug" (:-). Seriously you can disagree with RFC 4509 > but not about the way it has to be implemented, i.e., your concern > is not about what it should be... > > The issue is the missing (but probably implied) text, "and valid", in RFC 4509 (where SHA-256 DS record(s) are concerned). In the case where the SHA-256 DS record has been pre-validated, well, it's already a no-brainer. In the case where the SHA-256 DS record has not yet been validated, ignoring the SHA-1 before validating the SHA-256, is either suboptimal or erroneous. The invalidity of an individual RR in a DS RRSET (where the DS RRSET's RRSIG *MUST* already have been validated before considering the DS RRSET) can fall into two categories: - obvious operator error (wrong amount of data in the DS RDATA, or otherwise malformed DS RDATA); - "hash mismatch" against corresponding DNSKEY(s), which COULD be a downgrade attack. In the case of "suspected downgrade attack", the validity could be teased out, if there were any other DS RR's in the RRSET. The presence of any other DS RR algorithm which validates, would be enough to "prove" the error is operator error. The lack of any other DS RR algorithm (beyond SHA-1 and SHA-256), means a downgrade attack cannot be completely ruled out. (It's still paranoid to reject a valid SHA-1 when an invalid SHA-256 exists and no other DS RR's are present.) The SHOULD vs MUST boils down to: - if SHA-256 is invalid, and SHA-1 is then used, this is a "SHOULD" behavior. - if SHA-256 is invalid, and a present SHA-1 is never checked, this is a "MUST" behavior. What Paul is (I believe) indicating is that doing the latter isn't quite in keeping with the general spirit of the RFC, or in the "be liberal in what you accept" philosophy. Of course, if the SHA-1 is also invalid, then it is bogus. Brian --002354186d84b2a2b304a30669c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 11, 2011 at 4:22 PM, Francis= Dupont <= Francis.Dupont@fdupont.fr> wrote:
=A0In your previous mail you wrote:

=A0 Note that the text in RFC 4509 has a SHOULD, not a MUST. The fact
=A0 that the BIND and Unbound people treat it as a MUST seems like a
=A0 bug.

=3D> I don't understand how the SHOULD can be interpreted in o= rder to
avoid the "bug" (:-). Seriously you can disagree with RFC 4509 but not about the way it has to be implemented, i.e., your concern
is not about what it should be...


The issue is the missing (but probably implied) t= ext,=A0 "and valid", in RFC 4509 (where SHA-256 DS record(s) are = concerned).

In the case where the SHA-256 DS record has been pre-val= idated, well, it's already a no-brainer.
In the case where the SHA-256 DS record has not yet been validated, ignorin= g the SHA-1 before validating the SHA-256, is either suboptimal or erroneou= s.

The invalidity of an individual RR in a DS RRSET (where the DS RR= SET's RRSIG *MUST* already have been validated before considering the D= S RRSET) can fall into two categories:
- obvious operator error (wrong amount of data in the DS RDATA,= or otherwise malformed DS RDATA);
- "hash mismatch" against = corresponding DNSKEY(s), which COULD be a downgrade attack.

In the c= ase of "suspected downgrade attack", the validity could be teased= out, if there were any other DS RR's in the RRSET.
The presence of any other DS RR algorithm which validates, would be enough = to "prove" the error is operator error.
The lack of any other = DS RR algorithm (beyond SHA-1 and SHA-256), means a downgrade attack cannot= be completely ruled out.
(It's still paranoid to reject a valid SHA-1 when an invalid SHA-256 ex= ists and no other DS RR's are present.)

The SHOULD vs MUST boils= down to:
- if SHA-256 is invalid, and SHA-1 is then used, this is a &qu= ot;SHOULD" behavior.
- if SHA-256 is invalid, and a present SHA-1 is never checked, this is a &q= uot;MUST" behavior.

What Paul is (I believe) indicating is that= doing the latter isn't quite in keeping with the general spirit of the= RFC, or in the "be liberal in what you accept" philosophy.

Of course, if the SHA-1 is also invalid, then it is bogus.

Brian=
--002354186d84b2a2b304a30669c3-- From Francis.Dupont@fdupont.fr Wed May 11 15:50:31 2011 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 BBFD9E0870 for ; Wed, 11 May 2011 15:50:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0VT66auB7yf for ; Wed, 11 May 2011 15:50:31 -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 C7381E07F0 for ; Wed, 11 May 2011 15:50:30 -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 p4BMoQZk020211; Thu, 12 May 2011 00:50:26 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201105112250.p4BMoQZk020211@givry.fdupont.fr> From: Francis Dupont To: Brian Dickson In-reply-to: Your message of Wed, 11 May 2011 17:04:05 EDT. Date: Thu, 12 May 2011 00:50:26 +0200 Sender: Francis.Dupont@fdupont.fr Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 11 May 2011 22:50:31 -0000 In your previous mail you wrote: What Paul is (I believe) indicating is that doing the latter isn't quite in keeping with the general spirit of the RFC, or in the "be liberal in what you accept" philosophy. => The RFC says: Validator implementations SHOULD ignore DS RRs containing SHA-1 digests if DS RRs with SHA-256 digests are present in the DS RRset. so it doesn't say "valid" SHA-256 digests or something else. I am sorry but there is one possible interpretation of the text, of course we can agree the text is bad (:-). BTW I already signaled there is no guideline for other (than SHA-1 and SHA-256) digest algorithms so anyway a new document is needed... Regards Francis.Dupont@fdupont.fr PS: IMHO the idea of RFC 4509 is to replace SHA-1 by SHA-256 (and Paul shoud remark there is no well founded cryto reasons to do that) so to provide both SHA-1 and SHA-256 is something for the (now in the past) transitioning phase... From dougb@dougbarton.us Wed May 11 17:48:06 2011 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 39C15E084F for ; Wed, 11 May 2011 17:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4nYAM3aSCCe for ; Wed, 11 May 2011 17:48:05 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 57989E0711 for ; Wed, 11 May 2011 17:48:05 -0700 (PDT) Received: (qmail 10425 invoked by uid 399); 12 May 2011 00:48:00 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 12 May 2011 00:48:00 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DCB2E3F.4030701@dougbarton.us> Date: Wed, 11 May 2011 17:47:59 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Francis Dupont References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> In-Reply-To: <201105112250.p4BMoQZk020211@givry.fdupont.fr> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 00:48:06 -0000 On 05/11/2011 15:50, Francis Dupont wrote: > In your previous mail you wrote: > > What Paul is (I believe) indicating is that doing the latter isn't quite in > keeping with the general spirit of the RFC, or in the "be liberal in what > you accept" philosophy. > > => The RFC says: > > Validator implementations SHOULD ignore DS RRs containing SHA-1 > digests if DS RRs with SHA-256 digests are present in the DS RRset. > > so it doesn't say "valid" SHA-256 digests or something else. > I am sorry but there is one possible interpretation of the text, > of course we can agree the text is bad (:-). BTW I already signaled > there is no guideline for other (than SHA-1 and SHA-256) digest > algorithms so anyway a new document is needed... A) Insert obligatory rant about why "should" and "may" should never be used in standards documents. B) I don't think it takes even the smallest leap of imagination to say that if the SHA-256 DS is invalid, and the SHA-1 DS is valid, the SHA-1 should be used and the SHA-256 should be ignored. I think we could have a fine "angels-on-the-head-of-a-pin" debate about what "present" means in the RFC text, but I have a hard time believing that the intent of the text is that if you have something that works it should be ignored in favor of something that doesn't. One could imagine a theoretical downgrade attack where the attacker somehow got access to the parent and was able to invalidate the SHA-256 DS so that they could do their nefarious magic with the SHA-1 version, but if you could gain that kind of access to the parent wouldn't you have better ways to cause mischief? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From marka@isc.org Wed May 11 18:28:17 2011 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 EF7E4E06F3 for ; Wed, 11 May 2011 18:28:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp5ZkVbHDwzd for ; Wed, 11 May 2011 18:28:17 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 19A02E06B9 for ; Wed, 11 May 2011 18:28:17 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 09A055F998D; Thu, 12 May 2011 01:28:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 0E102216C40; Thu, 12 May 2011 01:28:00 +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 296D7EAE55F; Thu, 12 May 2011 11:28:32 +1000 (EST) To: Francis Dupont From: Mark Andrews References: <201105112022.p4BKMHmp010275@givry.fdupont.fr> In-reply-to: Your message of "Wed, 11 May 2011 22:22:17 +0200." <201105112022.p4BKMHmp010275@givry.fdupont.fr> Date: Thu, 12 May 2011 11:28:32 +1000 Message-Id: <20110512012832.296D7EAE55F@drugs.dv.isc.org> Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 01:28:18 -0000 In message <201105112022.p4BKMHmp010275@givry.fdupont.fr>, Francis Dupont writes: > In your previous mail you wrote: > > Note that the text in RFC 4509 has a SHOULD, not a MUST. The fact > that the BIND and Unbound people treat it as a MUST seems like a > bug. > > => I don't understand how the SHOULD can be interpreted in order to > avoid the "bug" (:-). Seriously you can disagree with RFC 4509 > but not about the way it has to be implemented, i.e., your concern > is not about what it should be... > > Regards > > Francis.Dupont@fdupont.fr > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext Agreed. You are either configured to follow the SHOULD or not and the default is to fail. Now not having a switch to turn it off means you don't have a work around once you discover that DS is wrong which requires contacting the administrators for the zone as they are the only ones that can tell you whether it is wrong or you are under attack. You can make a educated guess without contacting the zone administrators. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Wed May 11 18:57:50 2011 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 1ECCEE087F for ; Wed, 11 May 2011 18:57:50 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dPerW8BPImi for ; Wed, 11 May 2011 18:57:49 -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 016FDE0681 for ; Wed, 11 May 2011 18:57:47 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 87C74C9512; Thu, 12 May 2011 01:57:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 ED835216C1E; Thu, 12 May 2011 01:57:33 +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 209E0EAF182; Thu, 12 May 2011 11:58:06 +1000 (EST) To: Doug Barton From: Mark Andrews References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> <4DCB2E3F.4030701@dougbarton.us> In-reply-to: Your message of "Wed, 11 May 2011 17:47:59 MST." <4DCB2E3F.4030701@dougbarton.us> Date: Thu, 12 May 2011 11:58:06 +1000 Message-Id: <20110512015806.209E0EAF182@drugs.dv.isc.org> Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 01:57:50 -0000 In message <4DCB2E3F.4030701@dougbarton.us>, Doug Barton writes: > On 05/11/2011 15:50, Francis Dupont wrote: > > In your previous mail you wrote: > > > > What Paul is (I believe) indicating is that doing the latter isn't quite in > > keeping with the general spirit of the RFC, or in the "be liberal in what > > you accept" philosophy. > > > > => The RFC says: > > > > Validator implementations SHOULD ignore DS RRs containing SHA-1 > > digests if DS RRs with SHA-256 digests are present in the DS RRset. > > > > so it doesn't say "valid" SHA-256 digests or something else. > > I am sorry but there is one possible interpretation of the text, > > of course we can agree the text is bad (:-). BTW I already signaled > > there is no guideline for other (than SHA-1 and SHA-256) digest > > algorithms so anyway a new document is needed... > > A) Insert obligatory rant about why "should" and "may" should never be > used in standards documents. > B) I don't think it takes even the smallest leap of imagination to say > that if the SHA-256 DS is invalid, and the SHA-1 DS is valid, the SHA-1 > should be used and the SHA-256 should be ignored. > > I think we could have a fine "angels-on-the-head-of-a-pin" debate about > what "present" means in the RFC text, but I have a hard time believing > that the intent of the text is that if you have something that works it > should be ignored in favor of something that doesn't. Actually that was exactly the intent. It was don't trust SHA-1 at all if SHA-256 is present. > One could imagine a theoretical downgrade attack where the attacker > somehow got access to the parent and was able to invalidate the SHA-256 > DS so that they could do their nefarious magic with the SHA-1 version, > but if you could gain that kind of access to the parent wouldn't you > have better ways to cause mischief? The senario is that you have broken SHA-1 and can construct a working DNSKEY which matches what the parent is publishing but have not broken SHA-256. If you trust SHA-1 then the attack works. It you don't trust SHA-1 the attack fails. The rfc is assuming this will happen before the reverse and is telling implementors to code for it as if it was a current threat. > Doug > > -- > > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From stephan.lagerholm@secure64.com Wed May 11 19:00:53 2011 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 43E6AE08D6 for ; Wed, 11 May 2011 19:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mENWi1Ef9l5a for ; Wed, 11 May 2011 19:00:52 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3B73DE08D1 for ; Wed, 11 May 2011 19:00:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 044A8B83A3; Wed, 11 May 2011 19:52:46 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAZXjvc1ygEa; Wed, 11 May 2011 19:52:43 -0600 (MDT) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id BB55EB8396; Wed, 11 May 2011 19:52:43 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1305165163; bh=tyjMnVAN+Dp3eRgg92DBRhZGqBUu6yXZ5CCN4bCdaPw=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=t2G6gN9bQ3TNY1ge95 9mz3cpVBVeA3V194PqOMG9kvNWEWH3U/taGv3zMRPNVxGkPNtW/G8pRrM4M1GWlBDTq pBSjg5lZA81OoHDkVnN5H63h+aRztZCOkexTUO8oPRPIRqBKYkl0kgYAUmxwg63OqRY 9yTH+PvN2yEkLnlzfyU= x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 May 2011 19:45:34 -0600 Message-ID: In-Reply-To: <20110512012832.296D7EAE55F@drugs.dv.isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] DNSSEC, robustness, and several DS records Thread-Index: AcwQQdR1/aUG34dHTY+L+RsNnT0DmQAAszIg References: <201105112022.p4BKMHmp010275@givry.fdupont.fr> <20110512012832.296D7EAE55F@drugs.dv.isc.org> From: "Stephan Lagerholm" To: "Mark Andrews" , "Francis Dupont" Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 02:00:53 -0000 Regarding the RFC4509 discussion, I don't see why anybody would like to upload both a SHA-1 and SHA-2 DS to their parent. With AM, CAT, CH, CL, COM, CZ, DK, EDU, FI, FR, GR, LI, LU, MUSEUM, NET, NL, PM, RE, SE, TF, UK, WF and YT using only the SHA-2 algorithm for their DS in the root zone. Additionally, ARPA, BE, BIZ, CO, JP, MY, XN--0ZWM56D, XN--11B5BS3A9AJ6G, XN--80AKHBYKNJ4F, XN--9T4B11YI5A, XN--DEBA0AD, XN--G6W251D, XN--HGBK6AJ7F53BBA, XN--HLCJ6AYA9ESC7A, XN--JXALPDLP, XN--KGBECHTV, XN--ZCKZAH all requires a resolver to understand SHA-2 to be able to understand the DNSKEY in their zone anyway. I think it is fair to say that the DNSSEC functionality of a resolver without support for SHA-2 is highly limited. As such I don't believe that there are that many of them out there. (Am I wrong?) Do like .COM and Just don't upload the SHA-1 and you will never have this problem. We can perhaps have a different requirement wording in any future RFC that is introducing a new DS algorithm. But for SHA-1 vs. SHA-2 in reality this is not an issue. I'm noticing that FR currently only has a SHA-2 in the root zone. I guess they came to the same conclusion. /S ---------------------------------------------------------------------- Stephan Lagerholm Senior DNS Architect, M.Sc. ,CISSP Secure64 Software Corporation, www.secure64.com Cell: 469-834-3940 >-----Original Message----- >From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf Of >Mark Andrews >Sent: Wednesday, May 11, 2011 8:29 PM >To: Francis Dupont >Cc: Paul Hoffman; dnsext@ietf.org >Subject: Re: [dnsext] DNSSEC, robustness, and several DS records > > >In message <201105112022.p4BKMHmp010275@givry.fdupont.fr>, Francis Dupont >writes: >> In your previous mail you wrote: >> >> Note that the text in RFC 4509 has a SHOULD, not a MUST. The fact >> that the BIND and Unbound people treat it as a MUST seems like a >> bug. >> >> =3D> I don't understand how the SHOULD can be interpreted in order to >> avoid the "bug" (:-). Seriously you can disagree with RFC 4509 >> but not about the way it has to be implemented, i.e., your concern >> is not about what it should be... >> >> Regards >> >> Francis.Dupont@fdupont.fr >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > >Agreed. You are either configured to follow the SHOULD or not and >the default is to fail. Now not having a switch to turn it off >means you don't have a work around once you discover that DS is >wrong which requires contacting the administrators for the zone as >they are the only ones that can tell you whether it is wrong or you >are under attack. You can make a educated guess without contacting >the zone administrators. > >Mark >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext From dougb@dougbarton.us Wed May 11 19:21:28 2011 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 03730E0681 for ; Wed, 11 May 2011 19:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2i82B+QxasK for ; Wed, 11 May 2011 19:21:27 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 48A72E0662 for ; Wed, 11 May 2011 19:21:27 -0700 (PDT) Received: (qmail 25696 invoked by uid 399); 12 May 2011 02:21:23 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 12 May 2011 02:21:23 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DCB4421.5020306@dougbarton.us> Date: Wed, 11 May 2011 19:21:21 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Andrews References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> <4DCB2E3F.4030701@dougbarton.us> <20110512015806.209E0EAF182@drugs.dv.isc.org> In-Reply-To: <20110512015806.209E0EAF182@drugs.dv.isc.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 02:21:28 -0000 On 05/11/2011 18:58, Mark Andrews wrote: > In message<4DCB2E3F.4030701@dougbarton.us>, Doug Barton writes: >> On 05/11/2011 15:50, Francis Dupont wrote: >>> In your previous mail you wrote: >>> >>> What Paul is (I believe) indicating is that doing the latter isn't quite in >>> keeping with the general spirit of the RFC, or in the "be liberal in what >>> you accept" philosophy. >>> >>> => The RFC says: >>> >>> Validator implementations SHOULD ignore DS RRs containing SHA-1 >>> digests if DS RRs with SHA-256 digests are present in the DS RRset. >>> >>> so it doesn't say "valid" SHA-256 digests or something else. >>> I am sorry but there is one possible interpretation of the text, >>> of course we can agree the text is bad (:-). BTW I already signaled >>> there is no guideline for other (than SHA-1 and SHA-256) digest >>> algorithms so anyway a new document is needed... >> >> A) Insert obligatory rant about why "should" and "may" should never be >> used in standards documents. >> B) I don't think it takes even the smallest leap of imagination to say >> that if the SHA-256 DS is invalid, and the SHA-1 DS is valid, the SHA-1 >> should be used and the SHA-256 should be ignored. >> >> I think we could have a fine "angels-on-the-head-of-a-pin" debate about >> what "present" means in the RFC text, but I have a hard time believing >> that the intent of the text is that if you have something that works it >> should be ignored in favor of something that doesn't. > > Actually that was exactly the intent. It was don't trust SHA-1 at all > if SHA-256 is present. Ok, so I guess we *do* need to have a debate about what "present" means. :) To me, "it doesn't work" would indicate "!present," but I suppose reasonable minds could differ. >> One could imagine a theoretical downgrade attack where the attacker >> somehow got access to the parent and was able to invalidate the SHA-256 >> DS so that they could do their nefarious magic with the SHA-1 version, >> but if you could gain that kind of access to the parent wouldn't you >> have better ways to cause mischief? > > The senario is that you have broken SHA-1 and can construct a working > DNSKEY which matches what the parent is publishing but have not > broken SHA-256. If you trust SHA-1 then the attack works. It you > don't trust SHA-1 the attack fails. The rfc is assuming this will > happen before the reverse and is telling implementors to code for > it as if it was a current threat. I get that, but I think we differ on the issue of "present." If there is a _working_ SHA-256 DS I agree with you completely. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From matt@mattmccutchen.net Wed May 11 21:24:07 2011 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 1E150E065D for ; Wed, 11 May 2011 21:24:07 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rekNAVuivMZW for ; Wed, 11 May 2011 21:24:06 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 535F6E06E3 for ; Wed, 11 May 2011 21:24:06 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id F375263406E; Wed, 11 May 2011 21:24:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=EK/A/51+fswncw70AdHTnaZKCefJgoA9l6tmjEnsWH0 ZwNhCRGIkAMluX6zAuXjqaxh7XfJhShl5escLjLJ7qgRs9/ATTuW2ggcCprXiKrE sz+2Y6Te+lSuEjJGzhcq3cTM58iMoSnkn1DTHAJsjNQ5cJ+9O1XCnWPhiHW3GOA4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=wvXyWuGOzFerjpnbDnHQO8T0oBI=; b=Yv5FfdNeZL jiBx1maviYAG8A7D9fXjzpiWWXI+AuFg468Ry2BAik0KkOvEQH0QbVEDxTkllMja iuv0z5HhaxwsRz+hVn+NEH1JgibfdPBluDnuasIrGMyFXNiYwdHbxQJ9t44zeAxW Mbyjqeju9RNp9vK3u/P6OuNtzkd/dIId8= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPSA id ABC9563406C; Wed, 11 May 2011 21:24:05 -0700 (PDT) From: Matt McCutchen To: Doug Barton In-Reply-To: <4DCB4421.5020306@dougbarton.us> References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> <4DCB2E3F.4030701@dougbarton.us> <20110512015806.209E0EAF182@drugs.dv.isc.org> <4DCB4421.5020306@dougbarton.us> Content-Type: text/plain; charset="UTF-8" Date: Thu, 12 May 2011 00:24:04 -0400 Message-ID: <1305174244.2793.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 04:24:07 -0000 On Wed, 2011-05-11 at 19:21 -0700, Doug Barton wrote: > On 05/11/2011 18:58, Mark Andrews wrote: > > The senario is that you have broken SHA-1 and can construct a working > > DNSKEY which matches what the parent is publishing but have not > > broken SHA-256. If you trust SHA-1 then the attack works. It you > > don't trust SHA-1 the attack fails. The rfc is assuming this will > > happen before the reverse and is telling implementors to code for > > it as if it was a current threat. > > I get that, but I think we differ on the issue of "present." If there is > a _working_ SHA-256 DS I agree with you completely. If there is a working SHA-256 DS there is no issue. The question is what the resolver should do if it gets a DNSKEY that matches a SHA-1 DS but doesn't match any SHA-256 DS. It has no way to distinguish a mistake in the SHA-256 DS data in the original zone from a downgrade attack. -- Matt From marc.lampo@eurid.eu Wed May 11 23:18:08 2011 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 2BAF0E0675 for ; Wed, 11 May 2011 23:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.15 X-Spam-Level: X-Spam-Status: No, score=-9.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Znx8vIYkUmou for ; Wed, 11 May 2011 23:18:07 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by ietfa.amsl.com (Postfix) with ESMTP id A96CEE06F2 for ; Wed, 11 May 2011 23:18:05 -0700 (PDT) X-ASG-Debug-ID: 1305181083-03694916393be70001-uIE7UK Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id 5xYEnjt6refq9lRz for ; Thu, 12 May 2011 08:18:03 +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 31906E407C for ; Thu, 12 May 2011 08:10:18 +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 4OxbFAiT-77D for ; Thu, 12 May 2011 08:10:18 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 17593E4050 for ; Thu, 12 May 2011 08:10:18 +0200 (CEST) From: "Marc Lampo" To: References: <201105112022.p4BKMHmp010275@givry.fdupont.fr> <20110512012832.296D7EAE55F@drugs.dv.isc.org> In-Reply-To: Date: Thu, 12 May 2011 08:10:18 +0200 (CEST) X-ASG-Orig-Subj: RE: [dnsext] DNSSEC, robustness, and several DS records Message-ID: <001c01cc106c$5af59ca0$10e0d5e0$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AcwQRkitxlewHY/1S9K9mxBRGK2m7gAJLv8g Content-Language: en-za X-Originating-IP: [172.20.5.23] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1305181083 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 06:18:08 -0000 Isn't the SHA-1 DS there to accommodate for validating caching name servers that do not understand the SHA-256 "type" ? Sorry to go somewhat off-topic, but still related to strengths of algorithms : Similar "problems" with the DNSKEY algorithms : RSASHA1, NSEC3RSASHA1, RSASHA256 and ..512 A validating caching name server that does not understand a stronger algorithm treats the data as "unsigned" + great design of DNSSEC, this backward compatibility - but pushing towards stronger algorithms, makes them being ignored by "older" software Last time I looked, Microsoft DNS topped at RSASHA1 (5); the root uses algorithm 8 --> Microsoft DNS, even configured to validate, cannot even start to validate. No, I don't want to start a war of which vendor to use or not to use, but by pushing towards better security, the security level can be *reduced* ! (if the push is "too soon") Kind regards, Marc Lampo -----Original Message----- From: Stephan Lagerholm [mailto:stephan.lagerholm@secure64.com] Sent: 12 May 2011 03:46 AM To: Mark Andrews; Francis Dupont Cc: Paul Hoffman; dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records Regarding the RFC4509 discussion, I don't see why anybody would like to upload both a SHA-1 and SHA-2 DS to their parent. With AM, CAT, CH, CL, COM, CZ, DK, EDU, FI, FR, GR, LI, LU, MUSEUM, NET, NL, PM, RE, SE, TF, UK, WF and YT using only the SHA-2 algorithm for their DS in the root zone. Additionally, ARPA, BE, BIZ, CO, JP, MY, XN--0ZWM56D, XN--11B5BS3A9AJ6G, XN--80AKHBYKNJ4F, XN--9T4B11YI5A, XN--DEBA0AD, XN--G6W251D, XN--HGBK6AJ7F53BBA, XN--HLCJ6AYA9ESC7A, XN--JXALPDLP, XN--KGBECHTV, XN--ZCKZAH all requires a resolver to understand SHA-2 to be able to understand the DNSKEY in their zone anyway. I think it is fair to say that the DNSSEC functionality of a resolver without support for SHA-2 is highly limited. As such I don't believe that there are that many of them out there. (Am I wrong?) Do like .COM and Just don't upload the SHA-1 and you will never have this problem. We can perhaps have a different requirement wording in any future RFC that is introducing a new DS algorithm. But for SHA-1 vs. SHA-2 in reality this is not an issue. I'm noticing that FR currently only has a SHA-2 in the root zone. I guess they came to the same conclusion. /S ---------------------------------------------------------------------- Stephan Lagerholm Senior DNS Architect, M.Sc. ,CISSP Secure64 Software Corporation, www.secure64.com Cell: 469-834-3940 >-----Original Message----- >From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf Of >Mark Andrews >Sent: Wednesday, May 11, 2011 8:29 PM >To: Francis Dupont >Cc: Paul Hoffman; dnsext@ietf.org >Subject: Re: [dnsext] DNSSEC, robustness, and several DS records > > >In message <201105112022.p4BKMHmp010275@givry.fdupont.fr>, Francis Dupont >writes: >> In your previous mail you wrote: >> >> Note that the text in RFC 4509 has a SHOULD, not a MUST. The fact >> that the BIND and Unbound people treat it as a MUST seems like a >> bug. >> >> => I don't understand how the SHOULD can be interpreted in order to >> avoid the "bug" (:-). Seriously you can disagree with RFC 4509 >> but not about the way it has to be implemented, i.e., your concern >> is not about what it should be... >> >> Regards >> >> Francis.Dupont@fdupont.fr >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > >Agreed. You are either configured to follow the SHOULD or not and >the default is to fail. Now not having a switch to turn it off >means you don't have a work around once you discover that DS is >wrong which requires contacting the administrators for the zone as >they are the only ones that can tell you whether it is wrong or you >are under attack. You can make a educated guess without contacting >the zone administrators. > >Mark >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext From bortzmeyer@nic.fr Thu May 12 01:00:49 2011 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 ED968E06C2 for ; Thu, 12 May 2011 01:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXQM1P+MinXs for ; Thu, 12 May 2011 01:00:49 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by ietfa.amsl.com (Postfix) with ESMTP id 04E78E0665 for ; Thu, 12 May 2011 01:00:49 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 85FE21C0109; Thu, 12 May 2011 09:55:46 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 802231C00FE; Thu, 12 May 2011 09:55:46 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 7D6B556812C; Thu, 12 May 2011 09:55:46 +0200 (CEST) Date: Thu, 12 May 2011 09:55:46 +0200 From: Stephane Bortzmeyer To: Matt McCutchen Message-ID: <20110512075546.GA17883@nic.fr> References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> <4DCB2E3F.4030701@dougbarton.us> <20110512015806.209E0EAF182@drugs.dv.isc.org> <4DCB4421.5020306@dougbarton.us> <1305174244.2793.8.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1305174244.2793.8.camel@localhost> X-Operating-System: Debian GNU/Linux 6.0.1 X-Kernel: Linux 2.6.32-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 08:00:50 -0000 On Thu, May 12, 2011 at 12:24:04AM -0400, Matt McCutchen wrote a message of 25 lines which said: > The question is what the resolver should do if it gets a DNSKEY that > matches a SHA-1 DS but doesn't match any SHA-256 DS. It has no way > to distinguish a mistake in the SHA-256 DS data in the original zone > from a downgrade attack. Can you explain how such an attack could be possible? Since the DS record set is signed, modifying the SHA-256 record to make it invalid (so the bad guy can attack SHA-1 with clever cryptanalysis) is not possible (unless the bad guy can attack the provisioning channel and, in this case, you're toasted, whatever the RFC says). [Doug Barton already made more or less the same argument, if I understand him correctly.] From bortzmeyer@nic.fr Thu May 12 01:03:30 2011 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 CCBEBE0746 for ; Thu, 12 May 2011 01:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orXrVDPKdjRV for ; Thu, 12 May 2011 01:03:30 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4D499E0724 for ; Thu, 12 May 2011 01:03:12 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 049921C0102; Thu, 12 May 2011 09:58:11 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id F3E141C00FE; Thu, 12 May 2011 09:58:10 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id F1B6056812C; Thu, 12 May 2011 09:58:10 +0200 (CEST) Date: Thu, 12 May 2011 09:58:10 +0200 From: Stephane Bortzmeyer To: Stephan Lagerholm Message-ID: <20110512075810.GB17883@nic.fr> References: <201105112022.p4BKMHmp010275@givry.fdupont.fr> <20110512012832.296D7EAE55F@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 6.0.1 X-Kernel: Linux 2.6.32-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 08:03:30 -0000 On Wed, May 11, 2011 at 07:45:34PM -0600, Stephan Lagerholm wrote a message of 84 lines which said: > I think it is fair to say that the DNSSEC functionality of a > resolver without support for SHA-2 is highly limited. [...] I'm > noticing that FR currently only has a SHA-2 in the root zone. I > guess they came to the same conclusion. There are not only resolvers, there are also signing tools. We allow SHA-1 DS in .FR because some users may be unable to produce SHA-2 DS. (Another solution would be to accept only DNSKEY and create the DS ourselves but this is for another thread.) From wouter@nlnetlabs.nl Thu May 12 01:20:49 2011 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 4255FE070C for ; Thu, 12 May 2011 01:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXyLzl9oUnAf for ; Thu, 12 May 2011 01:20:44 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EE7E0734 for ; Thu, 12 May 2011 01:20:40 -0700 (PDT) Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p4C8KbW7004034 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 12 May 2011 10:20:37 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4DCB9855.7020805@nlnetlabs.nl> Date: Thu, 12 May 2011 10:20:37 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@ietf.org References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> <4DCB2E3F.4030701@dougbarton.us> <20110512015806.209E0EAF182@drugs.dv.isc.org> <4DCB4421.5020306@dougbarton.us> <1305174244.2793.8.camel@localhost> <20110512075546.GA17883@nic.fr> In-Reply-To: <20110512075546.GA17883@nic.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 12 May 2011 10:20:38 +0200 (CEST) Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 08:20:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Stephane, On 05/12/2011 09:55 AM, Stephane Bortzmeyer wrote: > Can you explain how such an attack could be possible? Since the DS > record set is signed, modifying the SHA-256 record to make it invalid > (so the bad guy can attack SHA-1 with clever cryptanalysis) is not > possible (unless the bad guy can attack the provisioning channel and, > in this case, you're toasted, whatever the RFC says). > > [Doug Barton already made more or less the same argument, if I > understand him correctly.] The weakness in MD5 that I heard about (on slashdot I think) was that you could construct data that matched a particular hash. So, if the DS contains some particular hash, then you produce a DNSKEY-dataset whose hash matches the hash given. And spoof the DNSKEY (not the DS). However, even for MD5, the weakness that I once heard about needed a lot of data (one megabyte? wasn't the example a postscript document?), which would be hard to fit into a DNSKEY record in a way that you can still use the DNSKEY to sign data. Of course, you might want to get better advice, such as from the authors of RFC 4509. And they tell you to ignore the SHA1 if a SHA2 is present. with SHOULD (so, this is the best thing to do, but there could be some exception, maybe for diagnostics or so). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNy5hUAAoJEJ9vHC1+BF+NjsQP/3xpOpuwsf4HFNALvf9qRJUv /ofHIXmfD6EjY1psvEaxHrkp5vEIKoTGi3PlYFMEpAvAOiZsE6+M3GZN+ryvXNdY bS7eM6SFRCNz/I0oTtNhVluAB/dilk/Eh/zUPhoGc7Osz7HrWkl3JzWThkYAU3yS I9JmxqL76xKdl+vSqwuf+V43Ar6nqono8HzLzHVLvLpDYGMtPcQkv+E92FiDVoHD 8+TIBrHfla8finLF39Xb9VyQRtw6rPgGri9GwYW4rZDhB3nGyKoFhGBxHbzUHEiN m4bOfzaGlH3M9opajYQjDlaJTTb2qtWV7aiE9+BWP0puJ63IdHV74lkbrLtMKXC1 /48bXL0ynMjZazQzr1byvdwnPCSpxxn3J/hVe/EJUI70geEl2+RFFzgu1oW1vEPY 2lEPIbQvGjBmS+nfSoFO99wbQcRsrIMRV8biqRE0dlFkcxQyRQQ1YZHhUULEHNSM AnVIfvG1B1GYl9iFOAANde8+spf7boqPnqf7TMbLmmrffAtItb6CMDMhQxTwiO9g XoEcsOJLLoKikQBkwN73dkagZhPNALaF9hG8mwXwR90Ze0iYXvFLggL11b/iP4VL XfcfJwMcj5twU52277zy1Zn95clzjLQvY4uAOKcmrNYBaWEpq3S9UDQMzJgn7Ttg 0BRXEW5phfX2DHlK2dVN =lYfw -----END PGP SIGNATURE----- From fanf2@hermes.cam.ac.uk Thu May 12 07:35:13 2011 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 B6177E068E for ; Thu, 12 May 2011 07:35:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57FCsFl17aAJ for ; Thu, 12 May 2011 07:35:09 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 87516E0682 for ; Thu, 12 May 2011 07:35:09 -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]:50372) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1QKWyo-0004VS-E5 (Exim 4.72) (return-path ); Thu, 12 May 2011 15:35:06 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QKWyo-00076p-BQ (Exim 4.67) (return-path ); Thu, 12 May 2011 15:35:06 +0100 Date: Thu, 12 May 2011 15:35:06 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "W.C.A. Wijngaards" In-Reply-To: <4DCB9855.7020805@nlnetlabs.nl> Message-ID: References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> <4DCB2E3F.4030701@dougbarton.us> <20110512015806.209E0EAF182@drugs.dv.isc.org> <4DCB4421.5020306@dougbarton.us> <1305174244.2793.8.camel@localhost> <20110512075546.GA17883@nic.fr> <4DCB9855.7020805@nlnetlabs.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 14:35:13 -0000 W.C.A. Wijngaards wrote: > > The weakness in MD5 that I heard about (on slashdot I think) was that > you could construct data that matched a particular hash. No, it's a collision attack. You can construct two things with the same hash. You can't construct something to match a given hash. This discussion seems silly to me, given that SHA1 is not likely to be vulnerable for a long time, and we will be able to stop relying on it before attacks become practical. We can rely on sensible behaviour by hostmasters rather than building brittleness into the protocol. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5 or 6 later. Rough or very rough. Occasional rain. Moderate or good, occasionally poor. From Ray.Bellis@nominet.org.uk Thu May 12 08:19:19 2011 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 D109CE0671 for ; Thu, 12 May 2011 08:19:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+8poDNuOEzD for ; Thu, 12 May 2011 08:19:15 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id 73B9613000A for ; Thu, 12 May 2011 08:19:13 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=K2zlCS/yYUgDvH86uXN8RDzU5ltaBjD5eQcp0CTH851869VfqwtsaqqO SnCZE4yNlhUgqICsuiSMSvJ6BiuOSrUACnaplVwvL/GoQJAjvIe1wVS1b mJGwsZZTfxuYKxK; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1305213555; x=1336749555; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[dnsext]=20WGLC=20ENDS0-bis|Date:=20Thu ,=2012=20May=202011=2015:19:10=20+0000|Message-ID:=20<586 209E0-AAB6-4FBC-BEC4-311BF0E49E6C@nominet.org.uk>|To:=20E dward=20Lewis=20|CC:=20""=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<3722738d-0ff2-4376-ab1b-c9ba40cf7401> |In-Reply-To:=20 |References:=20<4DC94AE6.5000903@ogud.com>=0D=0A=20; bh=3mgb3szL+QhmAhtSwwWSHaktS0xxZqpoyP1KjGSWbJE=; b=QlvEnJ0LxpdvE4sP53mDu0r/zPn0nrMCApFAuSFcS8kgGQXzo1vBLGc7 zCetUYjcTVjhkAfNlDc12uYUrcQ3+/WljpwVCPAj4lPLSuhqiGMYy5NYq AcjG1GFPcamFY+a; X-IronPort-AV: E=Sophos;i="4.64,358,1301871600"; d="scan'208";a="32844370" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 12 May 2011 16:19:11 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Thu, 12 May 2011 16:19:11 +0100 From: Ray Bellis To: Edward Lewis Thread-Topic: [dnsext] WGLC ENDS0-bis Thread-Index: AQHMDyb+Gzq+bz2At0ay29t0H2UOiJSGXeaAgALi6wA= Date: Thu, 12 May 2011 15:19:10 +0000 Message-ID: <586209E0-AAB6-4FBC-BEC4-311BF0E49E6C@nominet.org.uk> References: <4DC94AE6.5000903@ogud.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <3722738d-0ff2-4376-ab1b-c9ba40cf7401> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dnsext] WGLC ENDS0-bis 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, 12 May 2011 15:19:19 -0000 Ed, Taking two of your paragraphs that I believe are related: >=20 > # 6.8. Middleware Boxes >=20 > This section is a problem. Middleware boxes aren't well defined (yes, th= ere is the parenthetical list of examples), lacking references to documents= that provide definitions here. Going beyond that I don't know what this d= ocument is trying to impart. Are these requirements on non-DNS processes t= hat are acting as stateful proxies for DNS messages in dealing with EDNS0 r= ecords? I believe the intent of 6.8 is to reflect 5625, where I put in text along t= he lines of "if you're trying to be transparent, make sure you don't strip = the EDNS0 options". Hence it's a "get out" for the generally accepted principle that EDNS0 is "= hop by hop", for those cases where the middlebox is intended to be an "invi= sible" hop. > Missing material >=20 > Item 8 >=20 > I think the point that EDNS0 is a hop-by-hop marshaller of parameters, an= d not an end-to-end signalling mechanism is not clear enough. I don't thin= k the architectural placement of EDNS0 is clear described. This should be = in the introductory material. However as you say I think the hop-by-hop principle does need more text - i= n fact I couldn't find any text in either this document or its predecessor = that was explicit about this, despite it being well understood amongst DNS = protocol geeks. This came up when I was reviewing draft-kaplan-dnsext-enum-sip-source-ref-o= pt-code for the Independent Submissions Editor, and it's relevant to draft-= crocker-dnssec-algo-signal too. In both cases I wanted to cite the hop-by-hop principle but couldn't find r= elevant chapter and verse to back it up. kind regards, Ray From paul.hoffman@vpnc.org Thu May 12 08:26:26 2011 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 A0EEAE06BE for ; Thu, 12 May 2011 08:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v5LX4-yWU-e for ; Thu, 12 May 2011 08:26:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F0E29E06AF for ; Thu, 12 May 2011 08:26:25 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4CFQNf9078205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 May 2011 08:26:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4DCB9855.7020805@nlnetlabs.nl> Date: Thu, 12 May 2011 08:26:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> <4DCB2E3F.4030701@dougbarton.us> <20110512015806.209E0EAF182@drugs.dv.isc.org> <4DCB4421.5020306@dougbarton.us> <1305174244.2793.8.camel@localhost> <20110512075546.GA17883@nic.fr> <4DCB9855.7020805@nlnetlabs.nl> To: "W.C.A. Wijngaards" X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 15:26:26 -0000 On May 12, 2011, at 1:20 AM, W.C.A. Wijngaards wrote: > The weakness in MD5 that I heard about (on slashdot I think) was that > you could construct data that matched a particular hash. =20 You may have heard that on Slashdot; it is wrong. There has been no = preimage attack reported on MD5 or SHA1 except on messages that are many = terrabytes long, and even those take more than the 2^128 threshold that = I proposed earlier. --Paul Hoffman From dougb@dougbarton.us Thu May 12 12:05:40 2011 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 333B1E0758 for ; Thu, 12 May 2011 12:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cG1AaXVWwVhs for ; Thu, 12 May 2011 12:05:39 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 107E2E0718 for ; Thu, 12 May 2011 12:05:38 -0700 (PDT) Received: (qmail 29070 invoked by uid 399); 12 May 2011 19:05:34 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 12 May 2011 19:05:34 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DCC2F7C.9020100@dougbarton.us> Date: Thu, 12 May 2011 12:05:32 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Tony Finch References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> <4DCB2E3F.4030701@dougbarton.us> <20110512015806.209E0EAF182@drugs.dv.isc.org> <4DCB4421.5020306@dougbarton.us> <1305174244.2793.8.camel@localhost> <20110512075546.GA17883@nic.fr> <4DCB9855.7020805@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 19:05:40 -0000 On 05/12/2011 07:35, Tony Finch wrote: > W.C.A. Wijngaards wrote: >> >> The weakness in MD5 that I heard about (on slashdot I think) was that >> you could construct data that matched a particular hash. > > No, it's a collision attack. You can construct two things with the same > hash. You can't construct something to match a given hash. > > This discussion seems silly to me, given that SHA1 is not likely to be > vulnerable for a long time, and we will be able to stop relying on it > before attacks become practical. We can rely on sensible behaviour by > hostmasters rather than building brittleness into the protocol. Right, which, btw is an unstated assumption that I was making in my previous posts. I fully agree that we need to move toward SHA-256. In fact in the past I advocated here that the dnssec-bis docs should eliminate SHA-1 altogether, but I got shouted down out of respect for the "installed base" and deployment being "just around the corner." So if both work, sure, disregard SHA-1. Otherwise, go with what works. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From Ed.Lewis@neustar.biz Thu May 12 13:38:59 2011 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 48E1FE067C for ; Thu, 12 May 2011 13:38:59 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jxy0d0Fnn2hS for ; Thu, 12 May 2011 13:38:58 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED4AE066E for ; Thu, 12 May 2011 13:38:58 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p4CKctTb002377; Thu, 12 May 2011 16:38:55 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.215] by Work-Laptop-2.local (PGP Universal service); Thu, 12 May 2011 16:38:56 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 12 May 2011 16:38:56 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <586209E0-AAB6-4FBC-BEC4-311BF0E49E6C@nominet.org.uk> References: <4DC94AE6.5000903@ogud.com> <586209E0-AAB6-4FBC-BEC4-311BF0E49E6C@nominet.org.uk> Date: Thu, 12 May 2011 16:38:52 -0400 To: "" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis Subject: Re: [dnsext] WGLC ENDS0-bis 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, 12 May 2011 20:38:59 -0000 At 15:19 +0000 5/12/11, Ray Bellis wrote: >I believe the intent of 6.8 is to reflect 5625, where I put in text along >the lines of "if you're trying to be transparent, make sure you don't strip >the EDNS0 options". I think that is a fine principle and well stated - what the section is trying to impart. But I'm talking more basically about a lack of a definition of middle box in this document. What I'm hinting at is including a reference where the term is already defined or a paragraph defining the term. >In both cases I wanted to cite the hop-by-hop principle but couldn't find >relevant chapter and verse to back it up. More text is needed then. Given some time I'll try to come up with something. In https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=56283&tid=1305232265 I wrote this "the fact that the DNS is not a client-server protocol, as it is usually treated in text, but a client-cache-server protocol". Beginning with that, there is a difference between hop-by-hop and end-to-end in most DNS messages supporting a transaction. The data model, backed up by DNSSEC, is pretty much built to be end-to-end. EDNS0 on the other hand is hop-by-hop, taking parameters governing the message exchange from one entity to the next, not along the entire end-to-end path that the data travels. ...That's a first scratch of what is needed. Admittedly it is not fleshed out enough to be clear and come to the point. But I'm just squeezed for time now. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From Francis.Dupont@fdupont.fr Thu May 12 15:18:42 2011 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 AE499E07E9 for ; Thu, 12 May 2011 15:18:42 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk-Z1QVmAdj4 for ; Thu, 12 May 2011 15:18:42 -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 A7109E075A for ; Thu, 12 May 2011 15:18: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 p4CMIUBq006069; Fri, 13 May 2011 00:18:30 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201105122218.p4CMIUBq006069@givry.fdupont.fr> From: Francis Dupont To: Doug Barton In-reply-to: Your message of Wed, 11 May 2011 17:47:59 PDT. <4DCB2E3F.4030701@dougbarton.us> Date: Fri, 13 May 2011 00:18:30 +0200 Sender: Francis.Dupont@fdupont.fr Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 22:18:42 -0000 In your previous mail you wrote: A) Insert obligatory rant about why "should" and "may" should never be used in standards documents. => I don't follow your idea... B) I don't think it takes even the smallest leap of imagination to say that if the SHA-256 DS is invalid, and the SHA-1 DS is valid, the SHA-1 should be used and the SHA-256 should be ignored. => it is not a problem of imagination: either you implement what the spec says or you implement something else. And IMHO the first option is never a "bug". I think we could have a fine "angels-on-the-head-of-a-pin" debate about what "present" means in the RFC text => present == is an element of the set but I have a hard time believing that the intent of the text is that if you have something that works it should be ignored in favor of something that doesn't. => but it is the intent: this is why I wrote there is no "valid" in the spec (where my "valid" means your "works"). So I don't expect to see bind or unbound to change their behavior unless/until a new rfc is published with another spec. Regards Francis.Dupont@fdupont.fr From dougb@dougbarton.us Thu May 12 15:33:10 2011 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 CF4F1E07C8 for ; Thu, 12 May 2011 15:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rxRb6Df1MCj for ; Thu, 12 May 2011 15:33:10 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id D85DCE0780 for ; Thu, 12 May 2011 15:33:09 -0700 (PDT) Received: (qmail 17645 invoked by uid 399); 12 May 2011 22:33:03 -0000 Received: from unknown (HELO ?65.241.43.5?) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 12 May 2011 22:33:03 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DCC601E.8090301@dougbarton.us> Date: Thu, 12 May 2011 15:33:02 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Francis Dupont References: <201105122218.p4CMIUBq006069@givry.fdupont.fr> In-Reply-To: <201105122218.p4CMIUBq006069@givry.fdupont.fr> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 12 May 2011 22:33:10 -0000 Francis, FYI your peculiar style of quoting previous text makes your messages very hard to read. More so when they are part of a traditionally quoted message like this one. On 5/12/2011 3:18 PM, Francis Dupont wrote: > In your previous mail you wrote: > > A) Insert obligatory rant about why "should" and "may" should never be > used in standards documents. > > => I don't follow your idea... "Should" and "may" introduce ambiguity and allow different implementors to follow different paths, leading to multiple implementations that all arguably follow the spec, but don't interoperate. > B) I don't think it takes even the smallest leap of imagination to say > that if the SHA-256 DS is invalid, and the SHA-1 DS is valid, the SHA-1 > should be used and the SHA-256 should be ignored. > > => it is not a problem of imagination: either you implement what the > spec says or you implement something else. And IMHO the first option > is never a "bug". And my point is that the language of the spec is unclear, which makes the proper implementation questionable. > I think we could have a fine "angels-on-the-head-of-a-pin" debate about > what "present" means in the RFC text > > => present == is an element of the set My point was that the debate centers around whether or not a DS record can be said to be "present," "an element of the set," or whatever other equivalent term you want to use; if it doesn't work. If what you are saying is that if it exists in any form, functional or not, then it is said to be "present," that's where we disagree. > but I have a hard time believing that the intent of the text is > that if you have something that works it should be ignored in favor > of something that doesn't. > > => but it is the intent: this is why I wrote there is no "valid" > in the spec (where my "valid" means your "works"). And I think one could argue just as effectively that if what is meant is what you're interpreting then a sentence to the effect of "This is true even if the SHA-256 record doesn't work." should have been included. Or maybe not. I recognize that I could be wrong, but I don't agree that things are as cut and dry as you make them out to be. > So I don't expect to see bind or unbound to change their behavior > unless/until a new rfc is published with another spec. And now we get to the heart of why "should" and "may" are bad for technical requirements documentation. If I were an implementor I could very easily look at the spec and say, "Francis is right, I SHOULD skip the SHA-1 record here whether SHA-256 works or not. But I don't like that interpretation of the spec, so I won't." Such an implementation would be just as compliant, by the letter of the spec, as one that did skip the SHA-1. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From matt@mattmccutchen.net Thu May 12 18:48:22 2011 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 5A4FBE065A for ; Thu, 12 May 2011 18:48:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjZP7P7ezLSY for ; Thu, 12 May 2011 18:48:18 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 306D2E0593 for ; Thu, 12 May 2011 18:48:17 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id B661E10AFAB; Thu, 12 May 2011 18:48:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Dge/znttSI8phjfhjZrWPTALCJjBP9sg9BE4WLpkUEy QW7jUJLIAIvTROJ9z04iqrDg0DBeKBvSD+zh3II6FnobuhiwZLoOUHxdO1mmxnWu 6zpjHsj1Tpzc34YLjrl8P8oZtd8GfgPIjGZCsztfdAAwEhLhbUVDIB9goO1co7h0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=5/aYnClAfac9HAQUdG8+vSA5Ezk=; b=tbl+3PbghO iqsjCJP1pB4sEITvByoi6OSzRjAB3ESMbL9BBCKo/IdjfXkRph/xqHzMt1+363iR YFS7SXArVmVaLAqiVbwbQK7ZyGFt5KfH+mhluBjin21jYyAZeqS/6OnwYt8Xfr9/ 09k5UNcy2ZKGqyVCArlbWd17R3z3S1XCI= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id 504A910AFA5; Thu, 12 May 2011 18:48:17 -0700 (PDT) From: Matt McCutchen To: Doug Barton In-Reply-To: <4DCC2F7C.9020100@dougbarton.us> References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> <4DCB2E3F.4030701@dougbarton.us> <20110512015806.209E0EAF182@drugs.dv.isc.org> <4DCB4421.5020306@dougbarton.us> <1305174244.2793.8.camel@localhost> <20110512075546.GA17883@nic.fr> <4DCB9855.7020805@nlnetlabs.nl> <4DCC2F7C.9020100@dougbarton.us> Content-Type: text/plain; charset="UTF-8" Date: Thu, 12 May 2011 21:48:15 -0400 Message-ID: <1305251295.4426.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 13 May 2011 01:48:22 -0000 On Thu, 2011-05-12 at 12:05 -0700, Doug Barton wrote: > [...] So if both work, > sure, disregard SHA-1. Otherwise, go with what works. While you have defended your position amply, in your description you continue to gloss over the issue. The resolver does not know whether the SHA-256 DS is "working" (it has no way to distinguish a "non-working" SHA-256 DS from malicious replacement of the DNSKEY), so what you literally stated above is unimplementable. What I believe you are really proposing, to honor the SHA-1 DS if the SHA-256 DS does not match /for any reason/, is only as secure as the second preimage resistance of SHA-1. I just wanted to make sure this is clear in everyone's mind. -- Matt From dougb@dougbarton.us Thu May 12 19:25:37 2011 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 29897E065A for ; Thu, 12 May 2011 19:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS02PwwAlj8b for ; Thu, 12 May 2011 19:25:33 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id D19C5E06FD for ; Thu, 12 May 2011 19:25:32 -0700 (PDT) Received: (qmail 4512 invoked by uid 399); 13 May 2011 02:25:28 -0000 Received: from unknown (HELO ?65.241.43.5?) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 13 May 2011 02:25:28 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DCC9696.9060600@dougbarton.us> Date: Thu, 12 May 2011 19:25:26 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Matt McCutchen References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> <4DCB2E3F.4030701@dougbarton.us> <20110512015806.209E0EAF182@drugs.dv.isc.org> <4DCB4421.5020306@dougbarton.us> <1305174244.2793.8.camel@localhost> <20110512075546.GA17883@nic.fr> <4DCB9855.7020805@nlnetlabs.nl> <4DCC2F7C.9020100@dougbarton.us> <1305251295.4426.17.camel@localhost> In-Reply-To: <1305251295.4426.17.camel@localhost> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 13 May 2011 02:25:37 -0000 On 5/12/2011 6:48 PM, Matt McCutchen wrote: > On Thu, 2011-05-12 at 12:05 -0700, Doug Barton wrote: >> [...] So if both work, >> sure, disregard SHA-1. Otherwise, go with what works. > > While you have defended your position amply, in your description you > continue to gloss over the issue. The resolver does not know whether > the SHA-256 DS is "working" (it has no way to distinguish a > "non-working" SHA-256 DS from malicious replacement of the DNSKEY), so > what you literally stated above is unimplementable. What I believe you > are really proposing, to honor the SHA-1 DS if the SHA-256 DS does not > match /for any reason/, is only as secure as the second preimage > resistance of SHA-1. > > I just wanted to make sure this is clear in everyone's mind. Thanks for clarifying that. I was (obviously foolishly) thinking that there was a way to distinguish the 2 cases. In that case ignore everything I said, it should fail in Stephane's case. Sorry for wasting everyone's time, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From Francis.Dupont@fdupont.fr Sat May 14 05:11:28 2011 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 97BE8E06B4 for ; Sat, 14 May 2011 05:11:28 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBJj5FVdE+1r for ; Sat, 14 May 2011 05:11:28 -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 95D99E06B1 for ; Sat, 14 May 2011 05:11:27 -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 p4ECBL5S043969; Sat, 14 May 2011 14:11:21 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201105141211.p4ECBL5S043969@givry.fdupont.fr> From: Francis Dupont To: Doug Barton In-reply-to: Your message of Thu, 12 May 2011 15:33:02 PDT. <4DCC601E.8090301@dougbarton.us> Date: Sat, 14 May 2011 14:11:21 +0200 Sender: Francis.Dupont@fdupont.fr Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 14 May 2011 12:11:28 -0000 In your previous mail you wrote: "Should" and "may" introduce ambiguity and allow different implementors to follow different paths, leading to multiple implementations that all arguably follow the spec, but don't interoperate. => if something can introduce an interoperability problem a MUST is required. Here it is not the case so IMHO it is why a SHOULD is used. And my point is that the language of the spec is unclear, which makes the proper implementation questionable. => it seems you are the only person which argues about the meaning of "present"... i.e., I argue the languafe of the spec is clear. My point was that the debate centers around whether or not a DS record can be said to be "present," "an element of the set," or whatever other equivalent term you want to use; if it doesn't work. => if the "if it doesn't work" could matter it would be in the text, there is no such thing so it doesn't matter. If what you are saying is that if it exists in any form, functional or not, then it is said to be "present," that's where we disagree. => it is what I said and I maintain. > So I don't expect to see bind or unbound to change their behavior > unless/until a new rfc is published with another spec. And now we get to the heart of why "should" and "may" are bad for technical requirements documentation. => it seems there are 25 years of IETF just proving the opposite... And ss an implementor I'd like to get more than MUSTs in technical requirements (:-). Regards Francis.Dupont@fdupont.fr From george.barwood@blueyonder.co.uk Sun May 15 23:15:41 2011 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 37ECCE069B for ; Sun, 15 May 2011 23:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.454 X-Spam-Level: X-Spam-Status: No, score=0.454 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7qXn9vTyw26 for ; Sun, 15 May 2011 23:15:40 -0700 (PDT) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by ietfa.amsl.com (Postfix) with ESMTP id BC746E0694 for ; Sun, 15 May 2011 23:15:07 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.2]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110516061506.PFQD16165.mtaout02-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net> for ; Mon, 16 May 2011 07:15:06 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1QLr57-0003ic-U0 for dnsext@ietf.org; Mon, 16 May 2011 07:15:05 +0100 Message-ID: <22823BCF8255413FBF76D4DF5D519471@local> From: "George Barwood" To: Date: Mon, 16 May 2011 07:14:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=3NElcqgl2aoA:10 a=8nJEP1OIZ-IA:10 a=48vgC7mUAAAA:8 a=hlFdjzOTVvTjXkPpUgYA:9 a=7c4ZYOelPRfFOg5oreQA:7 a=wPNLvfGTeEIA:10 a=ZQ5fZReqlZkWP-jv:21 a=VkSF00tIekFM1gg2:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: [dnsext] DNAME YXDOMAIN validation 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, 16 May 2011 06:15:41 -0000 V2hhdCBhcmUgdGhlIHJlcXVpcmVtZW50cyBvbiByZXNvbHZlcnMgZm9yIHZhbGlkYXRpbmcgRE5B TUUgWVhET01BSU4gcmVzcG9uc2VzPw0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWRuc2V4dC1yZmMyNjcyYmlzLWRuYW1lLTIyI3NlY3Rpb24tNS4zLjENCg0Kc2F5cw0K DQogIFRoZSBkb21haW4gbmFtZSBjYW4gZ2V0IHRvbyBsb25nIGR1cmluZyBzdWJzdGl0dXRpb24u ICBGb3IgZXhhbXBsZSwNCiAgIHN1cHBvc2UgdGhlIHRhcmdldCBuYW1lIG9mIHRoZSBETkFNRSBS UiBpcyAyNTAgb2N0ZXRzIGluIGxlbmd0aA0KICAgKG11bHRpcGxlIGxhYmVscyksIGlmIGFuIGlu Y29taW5nIFFOQU1FIHRoYXQgaGFzIGEgZmlyc3QgbGFiZWwgb3ZlciA1DQogICBvY3RldHMgaW4g bGVuZ3RoLCB0aGUgcmVzdWx0IHdvdWxkIGJlIGEgbmFtZSBvdmVyIDI1NSBvY3RldHMuICBJZg0K ICAgdGhpcyBvY2N1cnMgdGhlIHNlcnZlciByZXR1cm5zIGFuIFJDT0RFIG9mIFlYRE9NQUlOIFtS RkMyMTM2XS4gIFRoZQ0KICAgRE5BTUUgcmVjb3JkIGFuZCBpdHMgc2lnbmF0dXJlIChpZiB0aGUg em9uZSBpcyBzaWduZWQpIGFyZSBpbmNsdWRlZA0KICAgaW4gdGhlIGFuc3dlciBhcyBwcm9vZiBm b3IgdGhlIFlYRE9NQUlOICh2YWx1ZSA2KSBSQ09ERS4NCg0Kd2hpY2ggaW1wbGllcyB0aGF0IFlY RE9NQUlOIHJlc3BvbnNlcyBjYW4gYmUgdmFsaWRhdGVkLg0KDQpIb3dldmVyLCBJJ20gd29uZGVy aW5nIGlmIHRoaXMgaXMgYWN0dWFsbHkgdXNlZnVsLCBhbmQgc2ltcGx5IGNsZWFyaW5nIHRoZSBB RA0KYml0IHdvdWxkIGJlIGFjY2VwdGFibGUuIGkuZS4gInZhbGlkYXRvcnMgTUFZIHZhbGlkYXRl IFlYRE9NQUlOIHJlc3BvbnNlcyIgYnV0IG5vIHN0cm9uZ2VyLg0KT3IgbWF5YmUgSSdtIHdyb25n LCBhbmQgWVhET01BSU4gcmVzcG9uc2VzIE1VU1QgYmUgdmFsaWRhdGVkIGlmIHBvc3NpYmxlLCBp biB3aGljaCBjYXNlIEkgdGhpbmsNCnRoaXMgd291bGQgYmUgYmVzdCBzdGF0ZWQgZXhwbGljaXRs eS4NCg0KQXMgYW4gYXNpZGUsICBJIG1heSBiZSBtaXN0YWtlbiwgYnV0IGl0IHNlZW1zIHRoYXQg Ym90aCBCSU5EIGFuZCBVTkJPVU5EIGRvbid0DQpjdXJyZW50bHkgaGFuZGxlIFlYRE9NQUlOIHJl c3BvbnNlcywgcmV0dXJuaW5nIFNFUlZFUkZBSUwgaW5zdGVhZCBvZiBZWERPTUFJTi4gDQpJIHRo aW5rIHRoaXMgaXMgcXVpdGUgbGlrZWx5IHRvIGJlIHRoZSBiZWhhdmlvciBmb3IgbGVnYWN5IHJl c29sdmVycyBhcyB3ZWxsLCBtYXliZSB0aGF0IGNvdWxkIGJlIG5vdGVkLg0KDQpHZW9yZ2UNCg== From wouter@nlnetlabs.nl Mon May 16 01:51:10 2011 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 A1BE0E0763 for ; Mon, 16 May 2011 01:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrRvuMHsY3a5 for ; Mon, 16 May 2011 01:51:09 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9E8E073A for ; Mon, 16 May 2011 01:51:08 -0700 (PDT) Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p4G8p4VK016686 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 16 May 2011 10:51:05 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4DD0E578.1020207@nlnetlabs.nl> Date: Mon, 16 May 2011 10:51:04 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@ietf.org References: <22823BCF8255413FBF76D4DF5D519471@local> In-Reply-To: <22823BCF8255413FBF76D4DF5D519471@local> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 16 May 2011 10:51:05 +0200 (CEST) Subject: Re: [dnsext] DNAME YXDOMAIN validation 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, 16 May 2011 08:51:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi George, On 05/16/2011 08:14 AM, George Barwood wrote: > What are the requirements on resolvers for validating DNAME YXDOMAIN responses? There are no requirements. Because there is no text in RFC2672 or -bis. > http://tools.ietf.org/html/draft-ietf-dnsext-rfc2672bis-dname-22#section-5.3.1 > > says > > The domain name can get too long during substitution. For example, > suppose the target name of the DNAME RR is 250 octets in length > (multiple labels), if an incoming QNAME that has a first label over 5 > octets in length, the result would be a name over 255 octets. If > this occurs the server returns an RCODE of YXDOMAIN [RFC2136]. The > DNAME record and its signature (if the zone is signed) are included > in the answer as proof for the YXDOMAIN (value 6) RCODE. > > which implies that YXDOMAIN responses can be validated. Yes. > However, I'm wondering if this is actually useful, and simply clearing the AD > bit would be acceptable. i.e. "validators MAY validate YXDOMAIN responses" but no stronger. > Or maybe I'm wrong, and YXDOMAIN responses MUST be validated if possible, in which case I think > this would be best stated explicitly. I thought it would be good to include the DNAME (I believe the authority servers already include the DNAME for YXDOMAIN responses, so the signature (when appropriate, DO flag, signed zone) is not a lot of work), just because you can. > As an aside, I may be mistaken, but it seems that both BIND and UNBOUND don't > currently handle YXDOMAIN responses, returning SERVERFAIL instead of YXDOMAIN. > I think this is quite likely to be the behavior for legacy resolvers as well, maybe that could be noted. Yes, there does not seem to be a great deal of utility for validating the YXDOMAIN. It is nice that there is some sort of proof for the RCODE (since for many other RCODEs no proof is possible, and considering the length of effort we took to prove NXDOMAINs). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN0OV4AAoJEJ9vHC1+BF+NC7sP/1f62TjtCcT/6myJNazWFium ONfeQwx25kD3fg7PHAOeiFl02KqiLNdehg3W+DuovK9m7la4SC2x5hGkYl1aJxZK yXF2zPL7zTELhWd2nlrtQHc7KXn+8M9XE8GcHn2jge2wu628Ecch4Yd9tq9caArZ tAcsSpRj4hte1XSw9V3HT9QwBvyUvZm1mbkz4aVdk4ACxsILlCKMV8wCsI6d65xz en4NS1ISGHgCX1RW0D9jBYbFb7CbVCoih35skMkIvznmkYB3VPguCefAUg/CtkVo fSRtJ/skwOxB1Z6P0ojBkrKUWPJJl90dqAgIN59QqBhgxS3SaoSFK7ssfR7eCKar /pZMYi4XFKqI0lwa59g8ykhms3Q7lpANazNZE0IacN5Nf2nzaasVQMx7l3nbsaDd oUuSG4DAIKRJuG6T7VRGq25DYHnFi0wJgdkozRMyVEhn0tEeg9Xj1Ned9bs8/zm0 XPieIDiY6m6mlR7G8xgeft/038QtY6ljBLBn0hNc3f+0WCa6f/1zVcYBgrO7n0Hq MMKiDbUB2fYnt35SwjYz4y3Ot6tmPMR53+9HLfYT2EUj7TGSyAZEyS1tpDJIeDRG aSw3PKKBwFCbFnKP8RjOpKrKO83y29wYhpj37T8cssnno6xneCRn7OHjJjmF/mK8 1M2WsrAM/DZMziCx7xOg =tGwd -----END PGP SIGNATURE----- From brian.peter.dickson@gmail.com Mon May 16 10:01:03 2011 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 289DAE06CF for ; Mon, 16 May 2011 10:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc+BSQx09v86 for ; Mon, 16 May 2011 10:00:58 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 85EFAE06B3 for ; Mon, 16 May 2011 10:00:57 -0700 (PDT) Received: by fxm15 with SMTP id 15so3724777fxm.31 for ; Mon, 16 May 2011 10:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2wGcD5okyrvgFguTrHplYL5FcJHDOTjES1eJ4RBpOjk=; b=IQzaNlCcoY4wtZb379P0baeyG59a/H1QwwjHxdbVk4MTO5Ct6xcdJpnNJ5xei2ZKjv wcdAyuuEDU0/6Xhadk5WBhwxH8hxwkmtZaDPZY8SW2rnnEbgxxVOBQuulxgUXJKXDsgh 64wIFFzRgITqnk4liae6LjYi1/ZnHPfLyhko4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=b+S7sNAV3gFc6h7oYrHc89AFuq/BW8WsraPeXSHsS5m7NaP0NcNOSZdC2lt27T2jad hImO0DwA8FbTnrf9b23UQ0vrkOFy6QEAcvkYN2Mjt1pPTrRzujXcj0Dn9o5QaiLRlr5z i3gZzbNQTDM15o7Taw8bmNmmwBAciTYC/EjGM= MIME-Version: 1.0 Received: by 10.223.75.15 with SMTP id w15mr1239793faj.134.1305565256614; Mon, 16 May 2011 10:00:56 -0700 (PDT) Received: by 10.223.146.65 with HTTP; Mon, 16 May 2011 10:00:56 -0700 (PDT) In-Reply-To: <20110512012832.296D7EAE55F@drugs.dv.isc.org> References: <201105112022.p4BKMHmp010275@givry.fdupont.fr> <20110512012832.296D7EAE55F@drugs.dv.isc.org> Date: Mon, 16 May 2011 13:00:56 -0400 Message-ID: From: Brian Dickson To: Mark Andrews Content-Type: multipart/alternative; boundary=0015174c19565a024a04a3679955 Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 16 May 2011 17:01:03 -0000 --0015174c19565a024a04a3679955 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 11, 2011 at 9:28 PM, Mark Andrews wrote: > > In message <201105112022.p4BKMHmp010275@givry.fdupont.fr>, Francis Dupont > writes: > > In your previous mail you wrote: > > > > Note that the text in RFC 4509 has a SHOULD, not a MUST. The fact > > that the BIND and Unbound people treat it as a MUST seems like a > > bug. > > > > => I don't understand how the SHOULD can be interpreted in order to > > avoid the "bug" (:-). Seriously you can disagree with RFC 4509 > > but not about the way it has to be implemented, i.e., your concern > > is not about what it should be... > > > > Regards > > > > Francis.Dupont@fdupont.fr > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > Agreed. You are either configured to follow the SHOULD or not and > the default is to fail. Now not having a switch to turn it off > means you don't have a work around once you discover that DS is > wrong which requires contacting the administrators for the zone as > they are the only ones that can tell you whether it is wrong or you > are under attack. You can make a educated guess without contacting > the zone administrators. > > Mark > > There are subtleties in the logic for following RFC 4035, which RFC 4509 kind of glosses over with its "SHOULD" recommendation. (IMHO, the "glossing over" is what creates the "bugs", when RFC 4509 is looked at in isolation, without considering RFC 4035.) When both 4035 and 4509 are taken together, those nuances become more obvious. While there is room for different interpretations, some/most of those lead to avoidable problems. BTW - the motivation here is as follows: encode as much logic which is unambiguous as possible, where that logic does not lead to weakness to downgrade attack in the absence of significant operator error. Encoding the "educated guess" into the resolver software minimizes the need for resolver operator intervention to cases that can't be disambiguated. Here's a fundamental arithmetic thing: In order for a SEP to be validated, the DS record has to match all of the Key Tag, the Algorithm, AND the Hash of the DNSKEY. (NB - both the Key Tag and the Hash depend on the Algorithm.) So, two DS records with the same Key Tag, but different Algorithms, CANNOT match the same DNSKEY. (Ditto for same Algorithm/different Key Tags.) So, the important question is, should the "SHOULD" in RFC 4509 apply: - Only to DS RRs that (appear to) refer to a single DNSKEY? - Only to DS RRs which share an Algorithm? - To all DS RRs without looking at Algorithm or Key Tag? When there are two different algorithms, given that we (should) treat all algorithms equally, I'd argue that this is a case where RFC 4509 should NOT apply, IMHO. This was the situation that Stephane experienced, FYI, although in his case the values for Key Tag happened to still match. The separation by Algorithms would have prevented the "bug" from resulting in "Bogus" / "Unknown" from being the validation result. I'd suggest that the most likely scenarios to be seen in production networks will be DS sets that include both SHA-1 and SHA-256 for the same DNSKEY (and thus algorithm), and possibly also additional DS record(s) with only SHA-256 on additional DNSKEY(s). BTW - the reason for having one DS pair with SHA-1+SHA-256 (for one DNSKEY) and another DS with SHA-256 ONLY (for a second DNSKEY), is that the following properties apply: - the SHA-256-ONLY DS *should* only get "touched" when there is activity on the corresponding DNSKEY, and what doesn't get "touched" is unlikely to be "broken". RRSIG validity is orthogonal to "breaking" the content of the DNSKEY and its relationship to the parent's DS record. - the DS with both SHA-1 and SHA-256 involves synchronized data, on two DS records and a DNSKEY record. If the DNSKEY record is updated, and the DS record for SHA-1 is updated but the DS record for SHA-256 is not, this would be indistinguishable from a downgrade attack. When you combine the two bullet points, and you get: - fat fingers can break a single DNSKEY's validation modulo RFC 4509, but is much less likely to invalidate both DNSKEYs if both types (SHA-256 only and SHA-256+SHA-1) are present. Since the attack vectors do not involve the DS sets directly, the presence of DS records for a given algorithm that do not include SHA-256, suggests operator error or deliberate choice, and alongside different algorithms with SHA-256 (with or without SHA-1), those DS records of SHA-1 only should not be ignored. It is still more secure to have the method of implementing RFC 4509 be: (0) validate the DS RRSET via its RRSIG(s). (1) partition the DS RRSET into Algorithm subsets; (2) for each Algorithm, if both SHA-256 and SHA-1 are present, suppress the SHA-1 records (3) do the rest of 4035 using the resulting DS RRSET (using whatever local policy is, e.g. either require all Algorithms to validate, or require any Algorithm to validate) IMHO, of course. Brian --0015174c19565a024a04a3679955 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 11, 2011 at 9:28 PM, Mark An= drews <marka@isc.org<= /a>> wrote:

In message <201105112022.p4BKMHmp010275@givry.fdupont.fr>, Francis Dupont wr= ites:
> =A0In your previous mail you wrote:
>
> =A0 =A0Note that the text in RFC 4509 has a SHOULD, not a MUST. The fa= ct
> =A0 =A0that the BIND and Unbound people treat it as a MUST seems like = a
> =A0 =A0bug.
>
> =3D> I don't understand how the SHOULD can be interpreted in or= der to
> avoid the "bug" (:-). Seriously you can disagree with RFC 45= 09
> but not about the way it has to be implemented, i.e., your concern
> is not about what it should be...
>
> Regards
>
> Francis.Dupont@fdupont.fr=
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext

Agreed. =A0You are either configured to follow the SHOULD or no= t and
the default is to fail. =A0Now not having a switch to turn it off
means you don't have a work around once you discover that DS is
wrong which requires contacting the administrators for the zone as
they are the only ones that can tell you whether it is wrong or you
are under attack. =A0You can make a educated guess without contacting
the zone administrators.

Mark


There are subtleties in the logic for fol= lowing RFC 4035, which RFC 4509 kind of glosses over with its "SHOULD&= quot; recommendation.
(IMHO, the "glossing over" is what creat= es the "bugs", when RFC 4509 is looked at in isolation, without c= onsidering RFC 4035.)
When both 4035 and 4509 are taken together, those nuances become more obvio= us. While there is room for different interpretations, some/most of those l= ead to avoidable problems.
BTW - the motivation here is as follows: enco= de as much logic which is unambiguous as possible, where that logic does no= t lead to weakness to downgrade attack in the absence of significant operat= or error.
Encoding the "educated guess" into the resolver software minimize= s the need for resolver operator intervention to cases that can't be di= sambiguated.

Here's a fundamental arithmetic thing: In order for= a SEP to be validated, the DS record has to match all of the Key Tag, the = Algorithm, AND the Hash of the DNSKEY. (NB - both the Key Tag and the Hash = depend on the Algorithm.)
So, two DS records with the same Key Tag, but different Algorithms, CANNOT = match the same DNSKEY. (Ditto for same Algorithm/different Key Tags.)
So, the important question is, should the "SHOULD" in RFC 4509 = apply:
- Only to DS RRs that (appear to) refer to a single DNSKEY?
- Only to DS= RRs which share an Algorithm?
- To all DS RRs without looking at Algori= thm or Key Tag?


When there are two different algorithms, given t= hat we (should) treat all algorithms equally, I'd argue that this is a = case where RFC 4509 should NOT apply, IMHO.
This was the situation that Stephane experienced, FYI, although in his case= the values for Key Tag happened to still match. The separation by Algorith= ms would have prevented the "bug" from resulting in "Bogus&q= uot; / "Unknown" from being the validation result.

I'd suggest that the most likely scenarios to be seen in production= networks will be DS sets that include both SHA-1 and SHA-256 for the same = DNSKEY (and thus algorithm), and possibly also additional DS record(s) with= only SHA-256 on additional DNSKEY(s).

BTW - the reason for having one DS pair with SHA-1+SHA-256 (for one DNS= KEY) and another DS with SHA-256 ONLY (for a second DNSKEY), is that the fo= llowing properties apply:
- the SHA-256-ONLY DS *should* only get "= touched" when there is activity on the corresponding DNSKEY, and what = doesn't get "touched" is unlikely to be "broken". R= RSIG validity is orthogonal to "breaking" the content of the DNSK= EY and its relationship to the parent's DS record.
- the DS with both SHA-1 and SHA-256 involves synchronized data, on two DS = records and a DNSKEY record. If the DNSKEY record is updated, and the DS re= cord for SHA-1 is updated but the DS record for SHA-256 is not, this would = be indistinguishable from a downgrade attack.

When you combine the two bullet points, and you get:
- fat fingers c= an break a single DNSKEY's validation modulo RFC 4509, but is much less= likely to invalidate both DNSKEYs if both types (SHA-256 only and SHA-256+= SHA-1) are present.

Since the attack vectors do not involve the DS sets directly, the prese= nce of DS records for a given algorithm that do not include SHA-256, sugges= ts operator error or deliberate choice, and alongside different algorithms = with SHA-256 (with or without SHA-1), those DS records of SHA-1 only should= not be ignored.
It is still more secure to have the method of implementing RFC 4509 be:
= (0) validate the DS RRSET via its RRSIG(s).
(1) partition the DS RRSET i= nto Algorithm subsets;
(2) for each Algorithm, if both SHA-256 and SHA-1= are present, suppress the SHA-1 records
(3) do the rest of 4035 using the resulting DS RRSET (using whatever local = policy is, e.g. either require all Algorithms to validate, or require any A= lgorithm to validate)

IMHO, of course.
Brian
--0015174c19565a024a04a3679955-- From kim.davies@icann.org Mon May 16 10:25:49 2011 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 F0610E0719 for ; Mon, 16 May 2011 10:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5hsVl0eXOvi for ; Mon, 16 May 2011 10:25:48 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 09E79E06BB for ; Mon, 16 May 2011 10:25:48 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 16 May 2011 10:25:47 -0700 From: Kim Davies To: "dnsext@ietf.org" , "idna-update@alvestrand.no" Date: Mon, 16 May 2011 10:25:45 -0700 Thread-Topic: Case studies in IDN variant TLDs Thread-Index: AcwT7ksfV/eaBKT5QHGi6Afl/oWA5g== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DC6FCC49637D47A79E65B1D5C4F2CCEEicannorg_" MIME-Version: 1.0 Subject: [dnsext] Case studies in IDN variant TLDs 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, 16 May 2011 17:25:49 -0000 --_000_DC6FCC49637D47A79E65B1D5C4F2CCEEicannorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear colleagues, A quick update on the working ongoing within ICANN on variant TLDs. ICANN i= s currently formulating a set of teams to each tackle a specific script, an= d try to identify the variant requirements for that specific community. The= case studies will be for the following six groups: Arabic, Chinese (Tradit= ional and Simplified), Cyrillic, Devanagari, Greek, and Latin. After those = teams each agree their own list of requirements, an analysis will be done t= o try and identify how approaches can be developed that cater for these dif= ferent requirements. It is anticipated teams will be comprised of community representatives, lin= guistic experts, DNS and IDNA experts, security & scalability experts, poli= cy experts, and registry/registrar operations experts. ICANN is currently looking for volunteers to work on these teams. If you ar= e interested please take a look at http://www.icann.org/en/announcements/an= nouncement-20apr11-en.htm It is hoped that ICANN's work will ultimately result in a clearer set of re= quirements, that in turn may help guide possible future protocol work in th= e IETF. kim --_000_DC6FCC49637D47A79E65B1D5C4F2CCEEicannorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear colleagues,

A quick update on the working ongoing within ICANN on = variant TLDs. ICANN is currently formulating a set of teams to each tackle = a specific script, and try to identify the variant requirements for that sp= ecific community. The case studies will be for the following six groups: Ar= abic, Chinese (Traditional and Simplified), Cyrillic, Devanagari, Greek, an= d Latin. After those teams each agree their own list of requirements, an an= alysis will be done to try and identify how approaches can be developed tha= t cater for these different requirements.

It is an= ticipated teams will be comprised of community representatives, lingui= stic experts, DNS and IDNA experts, security & scalability experts, pol= icy experts, and registry/registrar operations experts.

ICANN is currently looking for volunteers to work on these teams. If = you are interested please take a look at http://www.icann.org/en/announcem= ents/announcement-20apr11-en.htm

It is = hoped that ICANN's work will ultimately result in a clearer set of requirem= ents, that in turn may help guide possible future protocol work in the IETF= .

kim
= --_000_DC6FCC49637D47A79E65B1D5C4F2CCEEicannorg_-- From george.barwood@blueyonder.co.uk Mon May 16 11:15:37 2011 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 A8EAFE079A for ; Mon, 16 May 2011 11:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.218 X-Spam-Level: * X-Spam-Status: No, score=1.218 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_20=-0.74, J_CHICKENPOX_52=0.6, MIME_BASE64_TEXT=1.753, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiqGdit0NUzk for ; Mon, 16 May 2011 11:15:36 -0700 (PDT) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by ietfa.amsl.com (Postfix) with ESMTP id B4D30E0799 for ; Mon, 16 May 2011 11:15:33 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.4]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110516181529.YIYA3152.mtaout03-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Mon, 16 May 2011 19:15:29 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1QM2KH-0000ri-9E; Mon, 16 May 2011 19:15:29 +0100 Message-ID: <481B7D2048D44E988F9968AEEF4EFF27@local> From: "George Barwood" To: "W.C.A. Wijngaards" , References: <22823BCF8255413FBF76D4DF5D519471@local> <4DD0E578.1020207@nlnetlabs.nl> Date: Mon, 16 May 2011 19:15:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=I1x6_YhjcwUA:10 a=3NElcqgl2aoA:10 a=8nJEP1OIZ-IA:10 a=48vgC7mUAAAA:8 a=F5-z33WhAAAA:8 a=mNUaEz08pOpgB_XXUe0A:9 a=cMhFUN-2cy3vwdufepoA:7 a=wPNLvfGTeEIA:10 a=LOTjP7iKY08A:10 a=lZB815dzVvQA:10 a=LBeFHwr47n4orSip:21 a=14NKUdgVX3p83JAF:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [dnsext] DNAME YXDOMAIN validation 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, 16 May 2011 18:15:37 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlcuQy5BLiBXaWpuZ2FhcmRz IiA8d291dGVyQE5MbmV0TGFicy5ubD4NClRvOiA8ZG5zZXh0QGlldGYub3JnPg0KU2VudDogTW9u ZGF5LCBNYXkgMTYsIDIwMTEgOTo1MSBBTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIEROQU1FIFlY RE9NQUlOIHZhbGlkYXRpb24NCg0KDQo+IC0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0t LS0NCj4gSGFzaDogU0hBMQ0KPiANCj4gSGkgR2VvcmdlLA0KPiANCj4gT24gMDUvMTYvMjAxMSAw ODoxNCBBTSwgR2VvcmdlIEJhcndvb2Qgd3JvdGU6DQo+PiBXaGF0IGFyZSB0aGUgcmVxdWlyZW1l bnRzIG9uIHJlc29sdmVycyBmb3IgdmFsaWRhdGluZyBETkFNRSBZWERPTUFJTiByZXNwb25zZXM/ DQo+IA0KPiBUaGVyZSBhcmUgbm8gcmVxdWlyZW1lbnRzLiAgQmVjYXVzZSB0aGVyZSBpcyBubyB0 ZXh0IGluIFJGQzI2NzIgb3IgLWJpcy4NCg0KT2ssIGdpdmVuIHRoZSBnZW5lcmFsIGltcHJlY2F0 aW9ucyB0byB2YWxpZGF0ZSBhcyBwZXIgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDAz NSNzZWN0aW9uLTQuMg0KSSB0aGluayBhIHN0YXRlbWVudCB0aGF0IFlYRE9NQUlOIHJlc3BvbnNl cyBuZWVkIG5vdCBiZSB2YWxpZGF0ZWQgd291bGQgYmUgdXNlZnVsLg0KDQo+PiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRuc2V4dC1yZmMyNjcyYmlzLWRuYW1lLTIyI3Nl Y3Rpb24tNS4zLjENCj4+IA0KPj4gc2F5cw0KPj4gDQo+PiAgIFRoZSBkb21haW4gbmFtZSBjYW4g Z2V0IHRvbyBsb25nIGR1cmluZyBzdWJzdGl0dXRpb24uICBGb3IgZXhhbXBsZSwNCj4+ICAgIHN1 cHBvc2UgdGhlIHRhcmdldCBuYW1lIG9mIHRoZSBETkFNRSBSUiBpcyAyNTAgb2N0ZXRzIGluIGxl bmd0aA0KPj4gICAgKG11bHRpcGxlIGxhYmVscyksIGlmIGFuIGluY29taW5nIFFOQU1FIHRoYXQg aGFzIGEgZmlyc3QgbGFiZWwgb3ZlciA1DQo+PiAgICBvY3RldHMgaW4gbGVuZ3RoLCB0aGUgcmVz dWx0IHdvdWxkIGJlIGEgbmFtZSBvdmVyIDI1NSBvY3RldHMuICBJZg0KPj4gICAgdGhpcyBvY2N1 cnMgdGhlIHNlcnZlciByZXR1cm5zIGFuIFJDT0RFIG9mIFlYRE9NQUlOIFtSRkMyMTM2XS4gIFRo ZQ0KPj4gICAgRE5BTUUgcmVjb3JkIGFuZCBpdHMgc2lnbmF0dXJlIChpZiB0aGUgem9uZSBpcyBz aWduZWQpIGFyZSBpbmNsdWRlZA0KPj4gICAgaW4gdGhlIGFuc3dlciBhcyBwcm9vZiBmb3IgdGhl IFlYRE9NQUlOICh2YWx1ZSA2KSBSQ09ERS4NCj4+IA0KPj4gd2hpY2ggaW1wbGllcyB0aGF0IFlY RE9NQUlOIHJlc3BvbnNlcyBjYW4gYmUgdmFsaWRhdGVkLg0KPiANCj4gWWVzLg0KPiANCj4+IEhv d2V2ZXIsIEknbSB3b25kZXJpbmcgaWYgdGhpcyBpcyBhY3R1YWxseSB1c2VmdWwsIGFuZCBzaW1w bHkgY2xlYXJpbmcgdGhlIEFEDQo+PiBiaXQgd291bGQgYmUgYWNjZXB0YWJsZS4gaS5lLiAidmFs aWRhdG9ycyBNQVkgdmFsaWRhdGUgWVhET01BSU4gcmVzcG9uc2VzIiBidXQgbm8gc3Ryb25nZXIu DQo+PiBPciBtYXliZSBJJ20gd3JvbmcsIGFuZCBZWERPTUFJTiByZXNwb25zZXMgTVVTVCBiZSB2 YWxpZGF0ZWQgaWYgcG9zc2libGUsIGluIHdoaWNoIGNhc2UgSSB0aGluaw0KPj4gdGhpcyB3b3Vs ZCBiZSBiZXN0IHN0YXRlZCBleHBsaWNpdGx5Lg0KPiANCj4gSSB0aG91Z2h0IGl0IHdvdWxkIGJl IGdvb2QgdG8gaW5jbHVkZSB0aGUgRE5BTUUgKEkgYmVsaWV2ZSB0aGUgYXV0aG9yaXR5DQo+IHNl cnZlcnMgYWxyZWFkeSBpbmNsdWRlIHRoZSBETkFNRSBmb3IgWVhET01BSU4gcmVzcG9uc2VzLCBz byB0aGUNCj4gc2lnbmF0dXJlICh3aGVuIGFwcHJvcHJpYXRlLCBETyBmbGFnLCBzaWduZWQgem9u ZSkgaXMgbm90IGEgbG90IG9mDQo+IHdvcmspLCBqdXN0IGJlY2F1c2UgeW91IGNhbi4NCj4gDQo+ PiBBcyBhbiBhc2lkZSwgIEkgbWF5IGJlIG1pc3Rha2VuLCBidXQgaXQgc2VlbXMgdGhhdCBib3Ro IEJJTkQgYW5kIFVOQk9VTkQgZG9uJ3QNCj4+IGN1cnJlbnRseSBoYW5kbGUgWVhET01BSU4gcmVz cG9uc2VzLCByZXR1cm5pbmcgU0VSVkVSRkFJTCBpbnN0ZWFkIG9mIFlYRE9NQUlOLiANCj4+IEkg dGhpbmsgdGhpcyBpcyBxdWl0ZSBsaWtlbHkgdG8gYmUgdGhlIGJlaGF2aW9yIGZvciBsZWdhY3kg cmVzb2x2ZXJzIGFzIHdlbGwsIG1heWJlIHRoYXQgY291bGQgYmUgbm90ZWQuDQo+IA0KPiBZZXMs IHRoZXJlIGRvZXMgbm90IHNlZW0gdG8gYmUgYSBncmVhdCBkZWFsIG9mIHV0aWxpdHkgZm9yIHZh bGlkYXRpbmcNCj4gdGhlIFlYRE9NQUlOLiAgSXQgaXMgbmljZSB0aGF0IHRoZXJlIGlzIHNvbWUg c29ydCBvZiBwcm9vZiBmb3IgdGhlIFJDT0RFDQo+IChzaW5jZSBmb3IgbWFueSBvdGhlciBSQ09E RXMgbm8gcHJvb2YgaXMgcG9zc2libGUsIGFuZCBjb25zaWRlcmluZyB0aGUNCj4gbGVuZ3RoIG9m IGVmZm9ydCB3ZSB0b29rIHRvIHByb3ZlIE5YRE9NQUlOcykuDQoNCk9rLCBidXQgSSBkb24ndCB0 aGluayB0aGF0IGVpdGhlciBCSU5EIG9yIFVOQk9VTkQgaGFuZGxpbmcgb2YgWVhET01BSU4gaXMg Y29ycmVjdCAoSU1PKS4NCkknbGwgYWRtaXQgYXMgYnVncyBnbywgdGhpcyBpcyBleHRyZW1lbHkg bWlub3IsIGFuZCB2ZXJ5IHVubGlrZWx5IHRvIGNhdXNlIGFueSBraW5kIG9mIG9wZXJhdGlvbmFs IHByb2JsZW0sIA0Kc28gdGhpcyBtYXkgc2VlbSB2ZXJ5IHBlZGFudGljLCBidXQuLg0KDQpXaXRo IGJvdGggVU5CT1VORCBhbmQgQklORCwgdGhlIGJlaGF2aW9yIGRlcGVuZHMgb24gd2hldGhlciB0 aGUgRE5BTUUgaXMgY2FjaGVkLg0KDQpVTkJPVU5EOg0KSWYgdGhlIEROQU1FIGlzIGNhY2hlZCwg VU5CT1VORCBjb3JyZWN0bHkgcmV0dXJucyBqdXN0IHRoZSBETkFNRSB3aXRoIFJjb2RlPVlYRE9N QUlOIChncmVhdCEpLiBBRCBpcyBub3Qgc2V0IChvaykuDQpJZiB0aGUgRE5BTUUgaXMgbm90IGNh Y2hlZCwgVU5CT1VORCBzZWVtcyB0byByZWdhcmQgdGhlIFlYRE9NQUlOIHJlc3BvbnNlIGFzIExh bWUsIHNpbmNlIGl0IHJlcGVhdHMgdGhlIHF1ZXJ5IDYgdGltZXMgYmVmb3JlIGdpdmluZyB1cCBh bmQgcmV0dXJuaW5nIFNFUlZFUkZBSUwuDQoNCkJJTkQ6DQpJZiB0aGUgRE5BTUUgaXMgY2FjaGVk LCBpdCBjb3JyZWN0bHkgcmV0dXJucyB0aGUgRE5BTUUgKG9ubHkpLCBidXQgd2l0aCBSY29kZT1P ayByYXRoZXIgdGhhbiBZWERPTUFJTi4gQUQgaXMgc2V0Lg0KSWYgdGhlIEROQU1FIGlzIG5vdCBj YWNoZWQsIGl0IGRvZXNuJ3QgcmVwZWF0IHRoZSBxdWVyeSwgYnV0IHJldHVybnMgU0VSVkVSRkFJ TC4NCg0KVGhlIHRlc3QgZG9tYWluIEknbSB1c2luZyBpcw0KDQphMTIzNDU2Nzg5LmxvbmdkLnRl c3QyLml0ZWMtdXNhLmNvbQ0KDQpLaW5kIHJlZ2FyZHMsDQpHZW9yZ2UNCg== From hallam@gmail.com Tue May 17 09:07:23 2011 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 C5D8AE0834 for ; Tue, 17 May 2011 09:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HceRzBawlqj for ; Tue, 17 May 2011 09:07:22 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7F14E06C8 for ; Tue, 17 May 2011 09:07:22 -0700 (PDT) Received: by gxk19 with SMTP id 19so258216gxk.31 for ; Tue, 17 May 2011 09:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OPOmumHdxojHG/uBlx89YS+FfXcoCAPb8IjFM+V5glU=; b=OrKTcLNTbxgaYoisxRSAZ7TejiLW+WVGd3B90ZSs3ltVZbRtDDTMH1XB2yALccauB5 vxlMxHIRCVAsymcpYGp5lS5eRo932gAa8FN/zAUdpdbGWUxOyGGBcl5u5xthldp52WPa PhHEpb/9d3DYwVD5OziLzZq8W8g0EsYSUCiFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EY64rfM0A8BtuAZyAS/dBiIvvRWuPuL9NZFWnLC7E+rNRaCIDDLkKas9nBrLR6DQTE Gk49W25kHMtrWwNn7eXvLYhO5iyu75w6+KyDILZ/4IuEcCSIK7kfGXKmgbx1VOy5wJrq eVwm8V/IE1iwgy0KhsKO6ULDam7aG2pA0jBE4= MIME-Version: 1.0 Received: by 10.101.2.1 with SMTP id e1mr439054ani.18.1305648441909; Tue, 17 May 2011 09:07:21 -0700 (PDT) Received: by 10.101.36.13 with HTTP; Tue, 17 May 2011 09:07:21 -0700 (PDT) In-Reply-To: References: <201105112022.p4BKMHmp010275@givry.fdupont.fr> <20110512012832.296D7EAE55F@drugs.dv.isc.org> Date: Tue, 17 May 2011 12:07:21 -0400 Message-ID: From: Phillip Hallam-Baker To: Brian Dickson Content-Type: multipart/alternative; boundary=001636c594ff94e2eb04a37af719 Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 17 May 2011 16:07:23 -0000 --001636c594ff94e2eb04a37af719 Content-Type: text/plain; charset=ISO-8859-1 Some points responding to various issues in the thread. 1) No, it is not likely that we will have an issue with SHA-1 with respect to DNSSEC. The reason for this is that DNSSEC is not used to provide non-repudiation. Thus it is not necessary to be able to state today that we are confident that SHA-1 will be acceptably secure in 20 years time. I have asked Adi Shamir about likely progress on SHA1 and I think we are good wrt DNSSEC for at least ten years. 2) Despite this, there is a cost to using non-standard or deprecated crypto. Every single time someone wants to use a deprecated algorithm they have to produce a justification for doing so. Those costs mount up and the point is soon reached where the cost of constantly explaining why SHA-1 is safe is greater than the switching cost. I regret not proposing to upgrade DIGEST to SHA1 when we had the chance. Even though it would not add any security to the scheme (any attack on the digest construction is dominated by brute forcing the password space), it would have saved time overall. 3) There are real benefits to making exactly one set of cryptographic algorithms mandatory across all IETF protocols. At this point we don't have much discussion over whether to make RSA or AES mandatory they are just the default mandatory algorithms to be used across the board. I expect that the SHA3 competition will result in a similar situation for Digest and MAC functions. That will still leave some niche requirements for RC4 and DSA and once all the patents are expired there will be a likelihood of adding ECC. But as far as mandatory to implement is concerned, I think we can limit the set to RSA2048 + AES + SHA3 + SHA3-MAC. 4) Since SHA3 is being worked on right now, it would seem to me that the appropriate upgrade path for DNSSEC would be to ignore SHA2 and skip straight from SHA1 to SHA3. 5) Since RSA1024 is in the process of being deprecated, DNSSEC may well turn out to be one of the cases where there is an exception to requiring RSA2048. DSA-SHA3 will be slower than RSA but the signatures created will be 512 bits as opposed to 2048 and that is likely to make a difference for DNSSEC. 6) If we end up adding a mandatory algorithm we might well want to revisit some of the other design considerations in DNSSEC. At the time Don made his original proposals there were several optimizations that could have been employed that were in patent. Now those patents are expired it may make sense to re-open them. One of the biggest hassles in DNSSEC is that the RRSIG records cover individual record sets of the same type rather than all the records at a domain. This is a fairly obvious candidate for using Merkle trees. So there would be one public key signature for all the records in the zone and each individual RRset would contain the intermediate tree nodes to enable it to be verified. The way I would do it would be to define a new Signature algorithm for DSA+SHA3+Merkle Trees. So my conclusion is that the group should take no action on SHA1 now but that it should return to work on this topic after the SHA3 competition is completed and it should consider a proposal that could start deployment long before it became essential to make a switch. --001636c594ff94e2eb04a37af719 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Some points responding to various issues in the thread.

1) No, it is not likely that we will have an issue with= SHA-1 with respect to DNSSEC. The reason for this is that DNSSEC is not us= ed to provide non-repudiation. Thus it is not necessary to be able to state= today that we are confident that SHA-1 will be acceptably secure in 20 yea= rs time.

I have asked Adi Shamir about likely progress on SHA1 a= nd I think we are good wrt DNSSEC for at least ten years.


2) Despite this, there is a cost to using non-standa= rd or deprecated crypto. Every single time someone wants to use a deprecate= d algorithm they have to produce a justification for doing so. Those costs = mount up and the point is soon reached where the cost of constantly explain= ing why SHA-1 is safe is greater than the switching cost.

I regret not proposing to upgrade DIGEST to SHA1 when w= e had the chance. Even though it would not add any security to the scheme (= any attack on the digest construction is dominated by brute forcing the pas= sword space), it would have saved time overall.


3) There are real benefits to making exa= ctly one set of cryptographic algorithms mandatory across all IETF protocol= s. At this point we don't have much discussion over whether to make RSA= or AES mandatory they are just the default mandatory algorithms to be used= across the board. I expect that the SHA3 competition will result in a simi= lar situation for Digest and MAC functions.

That will still leave some niche requirements for RC4 a= nd DSA and once all the patents are expired there will be a likelihood of a= dding ECC. But as far as mandatory to implement is concerned, I think we ca= n limit the set to RSA2048 + AES + SHA3 + SHA3-MAC.


4) Since SHA3 is being worked on right n= ow, it would seem to me that the appropriate upgrade path for DNSSEC would = be to ignore SHA2 and skip straight from SHA1 to SHA3.


5) Since RSA1024 is in the process of being deprecated,= DNSSEC may well turn out to be one of the cases where there is an exceptio= n to requiring RSA2048. DSA-SHA3 will be slower than RSA but the signatures= created will be 512 bits as opposed to 2048 and that is likely to make a d= ifference for DNSSEC.


6) If we end up adding a mandatory algor= ithm we might well want to revisit some of the other design considerations = in DNSSEC. At the time Don made his original proposals there were several o= ptimizations that could have been employed that were in patent. Now those p= atents are expired it may make sense to re-open them.

One of the biggest hassles in DNSSEC is that the RRSIG = records cover individual record sets of the same type rather than all the r= ecords at a domain. This is a fairly obvious candidate for using Merkle tre= es. So there would be one public key signature for all the records in the z= one and each individual RRset would contain the intermediate tree nodes to = enable it to be verified.

The way I would do it would be to define a new Signatur= e algorithm for DSA+SHA3+Merkle Trees.


<= div>

So my conclusion is that the group should= take no action on SHA1 now but that it should return to work on this topic= after the SHA3 competition is completed and it should consider a proposal = that could start deployment long before it became essential to make a switc= h.=A0
--001636c594ff94e2eb04a37af719-- From fanf2@hermes.cam.ac.uk Tue May 17 10:38:50 2011 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 099BAE06C6 for ; Tue, 17 May 2011 10:38:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsYPynNi4eiS for ; Tue, 17 May 2011 10:38:47 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id D9482E06B0 for ; Tue, 17 May 2011 10:38:45 -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]:43483) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1QMOED-00069s-Dq (Exim 4.72) (return-path ); Tue, 17 May 2011 18:38:41 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QMOED-00039l-95 (Exim 4.67) (return-path ); Tue, 17 May 2011 18:38:41 +0100 Date: Tue, 17 May 2011 18:38:41 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <201105112022.p4BKMHmp010275@givry.fdupont.fr> <20110512012832.296D7EAE55F@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 17 May 2011 17:38:50 -0000 Phillip Hallam-Baker wrote: > > 1) No, it is not likely that we will have an issue with SHA-1 with respect > to DNSSEC. The reason for this is that DNSSEC is not used to provide > non-repudiation. Thus it is not necessary to be able to state today that we > are confident that SHA-1 will be acceptably secure in 20 years time. > > I have asked Adi Shamir about likely progress on SHA1 and I think we are > good wrt DNSSEC for at least ten years. A useful point, thanks. > 4) Since SHA3 is being worked on right now, it would seem to me that the > appropriate upgrade path for DNSSEC would be to ignore SHA2 and skip > straight from SHA1 to SHA3. SHA2 is already widely deployed in DNSSEC, e.g. in the root zone and many TLDs. > One of the biggest hassles in DNSSEC is that the RRSIG records cover > individual record sets of the same type rather than all the records at a > domain. Why is that a hassle? It seems like an advantage to me. In particular it makes it possible to sign a dynamic zone where there is no such thing as "all the records at a domain". Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5 or 6 later. Rough or very rough. Occasional rain. Moderate or good, occasionally poor. From hallam@gmail.com Tue May 17 13:43:18 2011 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 D4C5CE0781 for ; Tue, 17 May 2011 13:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjPFukf1xG66 for ; Tue, 17 May 2011 13:43:17 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 57976E06DB for ; Tue, 17 May 2011 13:43:17 -0700 (PDT) Received: by gwb20 with SMTP id 20so373653gwb.31 for ; Tue, 17 May 2011 13:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8YYtLtuaxjZxjfrpwMxi2xazu5tfHd8uTHareLf+C8A=; b=dtpLDoAFFEqA6uDVdUS/YXTPPmtWDm9RCQrw89AYazaWoxbxdLZz0fSU/0GgWEvjbY oV80K+RvtJDYu++kAmC2wJ4lyX6+GX002QnrLnRzcbN0EfzUOvVKTkUmWRNvBHyHHzBI 6Zg5I3+gJq3ckv9YFkgew+4qeIJ3FEdOR6V6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ak8Ki3hH7tKL7pnzBejbs1S7SO82xv3OEfjx9HLImpX3L/pm0822Kb5fjed4gKsCqt 63MhGGeKPzcK2EVINEgMNsQ2lvKvqP0YvFjybgTN/TnKCEx7Qmnsnxn21NHAp2D5K1IA Vj1OX3tsnS/SSOuqf+LOMasCmoO8QdkOIKVGA= MIME-Version: 1.0 Received: by 10.101.98.8 with SMTP id a8mr623591anm.62.1305664996646; Tue, 17 May 2011 13:43:16 -0700 (PDT) Received: by 10.101.36.13 with HTTP; Tue, 17 May 2011 13:43:16 -0700 (PDT) In-Reply-To: References: <201105112022.p4BKMHmp010275@givry.fdupont.fr> <20110512012832.296D7EAE55F@drugs.dv.isc.org> Date: Tue, 17 May 2011 16:43:16 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=001636ed6ce3521f8504a37ed29b Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] DNSSEC, robustness, and several DS records 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, 17 May 2011 20:43:19 -0000 --001636ed6ce3521f8504a37ed29b Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 17, 2011 at 1:38 PM, Tony Finch wrote: > Phillip Hallam-Baker wrote: > > > > 1) No, it is not likely that we will have an issue with SHA-1 with > respect > > to DNSSEC. The reason for this is that DNSSEC is not used to provide > > non-repudiation. Thus it is not necessary to be able to state today that > we > > are confident that SHA-1 will be acceptably secure in 20 years time. > > > > I have asked Adi Shamir about likely progress on SHA1 and I think we are > > good wrt DNSSEC for at least ten years. > > A useful point, thanks. > > > 4) Since SHA3 is being worked on right now, it would seem to me that the > > appropriate upgrade path for DNSSEC would be to ignore SHA2 and skip > > straight from SHA1 to SHA3. > > SHA2 is already widely deployed in DNSSEC, e.g. in the root zone and > many TLDs. > > > One of the biggest hassles in DNSSEC is that the RRSIG records cover > > individual record sets of the same type rather than all the records at a > > domain. > > Why is that a hassle? It seems like an advantage to me. In particular it > makes it possible to sign a dynamic zone where there is no such thing as > "all the records at a domain". > It means that a client will frequently need to verify multiple RRSigs for the same zone. Using Merkle trees the public key operation can be done one per zone and leveraged over all the records. For example, let us say that example.com has A, AAAA, TXT and MX present. The signature is calculated as follows = DSA ( H ( H ( H(A) + H (AAAA)) + H ( H(TXT) + H (MX) ) )) The RRSIG records would be A: SIG + [H (AAAA)] + [H ( H(TXT) + H (MX) )] + '0' AAAA: SIG + [H (A)] + [H ( H(TXT) + H (MX) )] + '1' TXT: SIG + [H ( H(A) + H (AAAA))] + [H (MX] + '2' MX: SIG + [H ( H(A) + H (AAAA)) ] + [H (TXT)] + '3' Note that each RRSIG is 512 + 256 + 256 + 16 = 1040 bits/130 bytes long plus whatever packaging is needed. When validating this type of RRSIG the validator would first check to see if it already has a signature verification result cached for the SIG value. So even if there were 4 RR types in a zone it would only perform one public key operation. -- Website: http://hallambaker.com/ --001636ed6ce3521f8504a37ed29b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, May 17, 2011 at 1:38 PM, Tony Fi= nch <dot@dotat.at&= gt; wrote:
Phillip Hallam-Baker <hallam@gmail.com> wrote:
>
> 1) No, it is not likely that we will have an issue with SHA-1 with res= pect
> to DNSSEC. The reason for this is that DNSSEC is not used to provide > non-repudiation. Thus it is not necessary to be able to state today th= at we
> are confident that SHA-1 will be acceptably secure in 20 years time. >
> I have asked Adi Shamir about likely progress on SHA1 and I think we a= re
> good wrt DNSSEC for at least ten years.

A useful point, thanks.

> 4) Since SHA3 is being worked on right now, it would seem to me that t= he
> appropriate upgrade path for DNSSEC would be to ignore SHA2 and skip > straight from SHA1 to SHA3.

SHA2 is already widely deployed in DNSSEC, e.g. in the root zone and<= br> many TLDs.

> One of the biggest hassles in DNSSEC is that the RRSIG records cover > individual record sets of the same type rather than all the records at= a
> domain.

Why is that a hassle? It seems like an advantage to me. In particular= it
makes it possible to sign a dynamic zone where there is no such thing as
"all the records at a domain".

It means that a client will frequently need to ve= rify multiple RRSigs for the same zone.

Using Merk= le trees the public key operation can be done one per zone and leveraged ov= er all the records.


For example, let us say that example.com has A, AAAA, TXT and MX present.
<= div>
The signature is calculated as follows


<sig> =A0=3D DSA ( H ( =A0H ( H(A) + H (AAAA)) + = H ( H(TXT) + H (MX) ) ))

The RRSIG records would b= e=A0

A: =A0SIG + [H (AAAA)] =A0+ [H ( H(TXT) + H (= MX) )] + '0'
AAAA:=A0SIG + [H (A)] = =A0+ [H ( H(TXT) + H (MX) )] + '1'
TXT: SIG + [H ( H(A) += H (AAAA))] + [H (MX] + '2'
MX: = =A0SIG + [H ( H(A) + H (AAAA)) ] + [H (TXT)] + '3'

Note th= at each RRSIG is 512 + 256 + 256 + 16 =3D 1040 =A0bits/130 =A0bytes long pl= us =A0whatever packaging is needed.
=A0
When validatin= g this type of RRSIG the validator would first check to see if it already h= as a signature verification result cached for the SIG value. So even if the= re were 4 RR types in a zone it would only perform one public key operation= .

--001636ed6ce3521f8504a37ed29b-- From wwwrun@rfc-editor.org Wed May 18 07:36:59 2011 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 7C565E0736 for ; Wed, 18 May 2011 07:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkLPRw77J-Zr for ; Wed, 18 May 2011 07:36:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id BA906E0669 for ; Wed, 18 May 2011 07:36:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 777E4E0701; Wed, 18 May 2011 07:36:54 -0700 (PDT) To: ogud@ogud.com, rdroms.ietf@gmail.com, jari.arkko@piuha.net, ogud@ogud.com, ajs@shinkuro.com From: RFC Errata System Message-Id: <20110518143654.777E4E0701@rfc-editor.org> Date: Wed, 18 May 2011 07:36:54 -0700 (PDT) Cc: ed.lewis@neustar.biz, dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] [Editorial Errata Reported] RFC3226 (2810) 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, 18 May 2011 14:36:59 -0000 The following errata report has been submitted for RFC3226, "DNSSEC and IPv6 A6 aware server/resolver message size requirements". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3226&eid=2810 -------------------------------------- Type: Editorial Reported by: Edward Lewis Section: 2.1 Original Text ------------- DNSSEC OK[OK] specifies how ... Corrected Text -------------- DNSSEC OK[RFC3225] specifies how ... Notes ----- Reference "link" is broken. 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. -------------------------------------- RFC3226 (draft-ietf-dnsext-message-size-04) -------------------------------------- Title : DNSSEC and IPv6 A6 aware server/resolver message size requirements Publication Date : December 2001 Author(s) : O. Gudmundsson Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From Klaus.Malorny@knipp.de Thu May 19 01:04:27 2011 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 4277DE068C for ; Thu, 19 May 2011 01:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fuwojTyO0eC for ; Thu, 19 May 2011 01:04:26 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c-eth0-0.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA48E067C for ; Thu, 19 May 2011 01:04:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 5D75733; Thu, 19 May 2011 10:04:18 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id gkRRXPKGjhtm; Thu, 19 May 2011 10:04:12 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id CB05732; Thu, 19 May 2011 10:04:12 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id p4J84C4L006233; Thu, 19 May 2011 10:04:12 +0200 (MESZ) Message-ID: <4DD4CEFB.3050702@knipp.de> Date: Thu, 19 May 2011 10:04:11 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110518 Thunderbird/3.3a4pre MIME-Version: 1.0 To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dnsext] NS/NSEC/NSEC3 records in the Additional section 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, 19 May 2011 08:04:27 -0000 Hi, it would be great if any of the experts here could do me a favour and help me on the following question, as I did not find a satisfying answer on my research in the relevant RFCs. I am wondering whether the Additional section may contain NS records, and, if so, whether the respective NSEC/NSEC3 record to prove the non-existence of the DS record for this delegation shall be placed also in the Additional section or in the Authority section instead. If I have the following zone, tld. SOA ... tld. NS ns1.sld.tld. sld.tld. NS ns2.other. sld.tld. NS ns3.other. I think it would make sense to include the NS records of sld.tld. (and DS records if signed) in the Additional section if the NS records of tld. are included in the Authority section, as this information is available anyway and should be useful for the resolver. This is, however, contrary to the behaviour of BIND, which I consider as a reference. Also, in the case that tld. is signed and sld.tld. not, the question is whether the respective NSEC/NSEC3 record shall be also in the Additional section. RFCs 403x and 5155 mention only the Authority section, but the described case does not occur at all in these RFCs (unless I missed it). Regards, Klaus From fweimer@bfk.de Thu May 19 04:00:26 2011 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 2927BE06E2 for ; Thu, 19 May 2011 04:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2W+21Ogxq3k for ; Thu, 19 May 2011 04:00:25 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4D4E065D for ; Thu, 19 May 2011 04:00:22 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QN0xo-0003rg-LV; Thu, 19 May 2011 11:00:20 +0000 Received: by bfk.de with local id 1QN0ug-0007tF-Cy; Thu, 19 May 2011 10:57:06 +0000 From: Florian Weimer To: Klaus Malorny References: <4DD4CEFB.3050702@knipp.de> Date: Thu, 19 May 2011 10:57:06 +0000 In-Reply-To: <4DD4CEFB.3050702@knipp.de> (Klaus Malorny's message of "Thu, 19 May 2011 10:04:11 +0200") Message-ID: <82k4dnez5p.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] NS/NSEC/NSEC3 records in the Additional section 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, 19 May 2011 11:00:26 -0000 * Klaus Malorny: > I think it would make sense to include the NS records of sld.tld. (and > DS records if signed) in the Additional section if the NS records of > tld. are included in the Authority section, as this information is > available anyway and should be useful for the resolver. This is, > however, contrary to the behaviour of BIND, which I consider as a > reference. You should send unusual records only in response to DO=3D1 queries. Otherwise, you risk that the client cannot interpret them. (The risk with DNSSEC-capable clients is still there, of course, but it seems less.) There is no precedent for copying NS records to the additional section, AFAIK. Given the amount of work put into reducing response sizes, it's also unlikely that such a feature would be a win for all parties involved. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Klaus.Malorny@knipp.de Thu May 19 06:53:33 2011 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 3770FE0745 for ; Thu, 19 May 2011 06:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7yhyrb4wlFD for ; Thu, 19 May 2011 06:53:32 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c-eth0-0.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id 804C1E07BC for ; Thu, 19 May 2011 06:53:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 7755953; Thu, 19 May 2011 15:53:26 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id K+Uk+plfoKel; Thu, 19 May 2011 15:53:20 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 657BF52; Thu, 19 May 2011 15:53:20 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id p4JDrId1002529; Thu, 19 May 2011 15:53:19 +0200 (MESZ) Message-ID: <4DD520D0.4030702@knipp.de> Date: Thu, 19 May 2011 15:53:20 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110518 Thunderbird/3.3a4pre MIME-Version: 1.0 To: Florian Weimer References: <4DD4CEFB.3050702@knipp.de> <82k4dnez5p.fsf@mid.bfk.de> In-Reply-To: <82k4dnez5p.fsf@mid.bfk.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] NS/NSEC/NSEC3 records in the Additional section 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, 19 May 2011 13:53:33 -0000 On 19/05/11 12:57, Florian Weimer wrote: > * Klaus Malorny: > > You should send unusual records only in response to DO=1 queries. > Otherwise, you risk that the client cannot interpret them. (The risk > with DNSSEC-capable clients is still there, of course, but it seems > less.) That statement makes me wonder how robust the resolvers are ;-) > > There is no precedent for copying NS records to the additional section, > AFAIK. Given the amount of work put into reducing response sizes, it's > also unlikely that such a feature would be a win for all parties > involved. > Yes, but the idea was that if the NS records in the authority section are of any use (while only the use as alternative name servers comes to my mind), then the additional NS records would allow to omit an extra query to the tld. name servers. While in the meantime I more or less managed to cope with the complexity of authoritative name servers (esp. in conjunction with DNSSEC), resolvers are still somewhat secret and magical to me. So I probably will stay away from that idea for the sake of stability and reliability. Regards, Klaus From Ed.Lewis@neustar.biz Thu May 19 07:10:35 2011 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 07976E06C0 for ; Thu, 19 May 2011 07:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFg+qKzW3gPr for ; Thu, 19 May 2011 07:10:33 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 87F6DE06BD for ; Thu, 19 May 2011 07:10:33 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p4JEAUPA065890; Thu, 19 May 2011 10:10:31 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.201.181] by work-laptop-2 (PGP Universal service); Thu, 19 May 2011 10:10:31 -0400 X-PGP-Universal: processed; by work-laptop-2 on Thu, 19 May 2011 10:10:31 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DD4CEFB.3050702@knipp.de> References: <4DD4CEFB.3050702@knipp.de> Date: Thu, 19 May 2011 10:10:10 -0400 To: Klaus Malorny From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] NS/NSEC/NSEC3 records in the Additional section 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, 19 May 2011 14:10:35 -0000 At 10:04 +0200 5/19/11, Klaus Malorny wrote: >I am wondering whether the Additional section may contain NS records, and, >if so, whether the respective NSEC/NSEC3 record to prove the non-existence >of the DS record for this delegation shall be placed also in the >Additional section or in the Authority section instead. I cannot think of any situation in which an NS set would appear in the additional section of a response (specifically a message with OPCODE=query, QR=1). NS records will appear in the answer section if and only if they type NS matches the QTYPE (NS, ANY, AXFR, IXFR if I'm not mistaken). NS records will appear in the authority section for a number of reasons, one is to direct the next iterative query to another set of servers (a referral), to establish the source as the authority for what is in the question and answer sections, and maybe some other situation I'm not thinking of right now. Presence or (proof of) absence of DS records, when germane, will appear in the authority section. (Again, unless DS matches the QTYPE.) >If I have the following zone, > >tld. SOA ... >tld. NS ns1.sld.tld. > >sld.tld. NS ns2.other. >sld.tld. NS ns3.other. > >I think it would make sense to include the NS records of sld.tld. (and DS >records if signed) in the Additional section if the NS records of tld. >are included in the Authority section, as this information is available >anyway and should be useful for the resolver. This is, however, contrary >to the behaviour of BIND, which I consider as a reference. Responding to that suggestion begins with this question - what is the query you have in mind? If the response would include the NS set of tld. in the authority, then the message means that the answer lies in the tld zone, therefore, there's no need to go to the sld.tld. servers. If you are thinking that a query like "shinkuro.us/IN/DS" directed to an authoritative server should have the DS in the answer, the NS of US in the authority and NS of shinkuro.us in the additional, there are a two reasons not to do this. One is that the shinkuro.us records here have a very low trustworthy rating (see RFC 2181 for that). Two, it is unlikely a validator would ask for the DS record unless the data "below" it that is being validated was already in hand - hence the NS set is already in hand (or perhaps TTL'd out). When we were designing DNSSEC we were more generous in including extra information until we discovered that often times the extra records (in additional) were unneeded because the cache already had them and hence represented unneeded bytes in the message. In the 90's our concern was bandwidth, now is it is message size (fragmentation, firewalls that don't know EDNS0, etc.). >Also, in the case that tld. is signed and sld.tld. not, the question is >whether the respective NSEC/NSEC3 record shall be also in the Additional >section. RFCs 403x and 5155 mention only the Authority section, but >the described case does not occur at all in these RFCs (unless I missed it). DNSSEC is supposed to be consumed in data flows internal to the DNS. As such, DS records and NSEC/NSEC3 records and others would never be part of other helpful records that are what is put into the additional. E.g., the A/AAAA record matching the RDATA names of MX records are counter examples. DNSSEC isn't meant to be helpful to the answer, it is meant to make sure the answer meets certain security properties. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From ajs@shinkuro.com Fri May 20 14:11:21 2011 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 3A874E0797 for ; Fri, 20 May 2011 14:11:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KN1gr4z1ZMvy for ; Fri, 20 May 2011 14:11:20 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 328E7E070E for ; Fri, 20 May 2011 14:11:20 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0B8E61ECB420 for ; Fri, 20 May 2011 21:11:18 +0000 (UTC) Date: Fri, 20 May 2011 17:11:17 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110520211117.GQ491@shinkuro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] [ajs@shinkuro.com: Request for publication: draft-ietf-dnsext-rfc2672bis-dname-22] 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, 20 May 2011 21:11:21 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear colleagues, I have requested publication of draft-ietf-dnsext-rfc2672bis-dname. I will update the status of the document to reflect our request. Thanks to the editors of the document for their long work. Best, Andrew (document shepherd) -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. --pf9I7BMVVzbSWLtt Content-Type: message/rfc822 Content-Disposition: inline Date: Fri, 20 May 2011 17:08:16 -0400 From: Andrew Sullivan To: dnsext-ads@tools.ietf.org, iesg-secretary@ietf.org Subject: Request for publication: draft-ietf-dnsext-rfc2672bis-dname-22 Message-ID: <20110520210816.GP491@shinkuro.com> Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Dear Ralph, This is a request for publication of the draft draft-ietf-dnsext-rfc2672bis-dname-22.txt on the Standards Track. This document is an update to RFC 2672 and if published will render that RFC obsolete. This draft does not advance DNAME on the standards track under the procedures of RFC 2026; its intended status is as Proposed Standard. At a later time, when the current situation with respect to the standards track is clearer, we will undertake advancement. As required by RFC 4858, below is the completed current template for the Document Shepherd Write-Up. --- begin PROTO write-up. --- This is the completed Document Shepherd Write-Up as required by RFC 4858 for the draft draft-ietf-dnsext-rfc2672bis-dname-22. This template was completed 2011-05-04. The template version is dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Andrew Sullivan is the Document Shepherd. He has reviewed the document and believes it is ready. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been part of the DNSEXT work for a number of years. It is on version 22; the -00 was published in 2006. It has been through several lengthy discussions on the WG mailing list. Recent calls for any additional comments did not result in any new work. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues 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. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) 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? There was at least one WG participant who maintained privately that he could not support the document publicly, because he believes it introduces a subtle incompatibility; but that he was not willing to object publicly. The shepherd sought elaboration of this critique, but (1) it wasn't forthcoming and (2) nobody else made it. (1.f) 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 entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. Note that the complaint about NOT RECOMMENDED & 2119 isn't quite true: the phrase is only in the document in order to update a different document that already uses that phrase. (1.h) Has the document split its references into normative and informative? 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 strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are so split, and everything is correct. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Yes. There is a request to update an existing registry. It is identified. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? N/A (1.k) 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 The DNS DNAME RRTYPE redirects subtrees of the domain name space. This memo updates the original specification found in RFC 2672. It also aligns RFC 3363 and RFC 4294 with the revision. Working Group Summary The DNS Extensions Working Group has spent a considerable amount of time on this document. It is the product of extended revie --pf9I7BMVVzbSWLtt-- From fw@deneb.enyo.de Mon May 23 14:00:08 2011 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 02DD5E07F3 for ; Mon, 23 May 2011 14:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DlRteJk5fSa for ; Mon, 23 May 2011 14:00:07 -0700 (PDT) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id B4D3FE07EE for ; Mon, 23 May 2011 14:00:06 -0700 (PDT) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QOcEM-0005Ob-2A; Mon, 23 May 2011 23:00:02 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.72) (envelope-from ) id 1QOcEL-0003uw-R4; Mon, 23 May 2011 23:00:01 +0200 From: Florian Weimer To: Olafur Gudmundsson References: <4DC94AE6.5000903@ogud.com> Date: Mon, 23 May 2011 23:00:01 +0200 In-Reply-To: <4DC94AE6.5000903@ogud.com> (Olafur Gudmundsson's message of "Tue, 10 May 2011 10:25:42 -0400") Message-ID: <878vtxku9a.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC ENDS0-bis 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, 23 May 2011 21:00:08 -0000 * Olafur Gudmundsson: > This document obsoletes RFC2671. The big changes from RFC2671 are: > - explicit usage of RFC2119 terms and labeling EDNS0 support as MUST; > - discussion on payload sizes and selection; > - closing of the extended label types registry and classifying > bit-labels as Historic; > - cleanup of IANA actions (that did not take place when RFC2671 > was issued). I would like to see guidance to implementors how they can actually detect EDNS0 support or the lack thereof. Alternatively, a minimum level of support could be made mandatory, eventually making the existing detection logic obsolete. From Ed.Lewis@neustar.biz Mon May 23 14:08:25 2011 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 50C9AE07F3 for ; Mon, 23 May 2011 14:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-D4VRvnt2su for ; Mon, 23 May 2011 14:08:24 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 970B5E079C for ; Mon, 23 May 2011 14:08:24 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p4NL8MIJ098267; Mon, 23 May 2011 17:08:22 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.118] by work-laptop-2 (PGP Universal service); Mon, 23 May 2011 17:08:22 -0400 X-PGP-Universal: processed; by work-laptop-2 on Mon, 23 May 2011 17:08:22 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <878vtxku9a.fsf@mid.deneb.enyo.de> References: <4DC94AE6.5000903@ogud.com> <878vtxku9a.fsf@mid.deneb.enyo.de> Date: Mon, 23 May 2011 17:08:19 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] WGLC ENDS0-bis 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, 23 May 2011 21:08:25 -0000 At 23:00 +0200 5/23/11, Florian Weimer wrote: >* Olafur Gudmundsson: > >> This document obsoletes RFC2671. The big changes from RFC2671 are: >> - explicit usage of RFC2119 terms and labeling EDNS0 support as MUST; >> - discussion on payload sizes and selection; >> - closing of the extended label types registry and classifying >> bit-labels as Historic; >> - cleanup of IANA actions (that did not take place when RFC2671 >> was issued). > >I would like to see guidance to implementors how they can actually >detect EDNS0 support or the lack thereof. Alternatively, a minimum >level of support could be made mandatory, eventually making the >existing detection logic obsolete. As far as declaring "a minimum level of support": an RFC cannot say "you must implement me, even if you were implemented last year." That just doesn't work. For backwards compatibility, we are stuck with probing for functionality. This is a weakness of the DNS architecture. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From joao@bondis.org Tue May 24 00:37:45 2011 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 09DB1E06CE for ; Tue, 24 May 2011 00:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZezM7fJjIxU for ; Tue, 24 May 2011 00:37:44 -0700 (PDT) Received: from smtp1.bondis.org (voyager.c-l-i.net [194.176.119.229]) by ietfa.amsl.com (Postfix) with ESMTP id 6B62DE06B6 for ; Tue, 24 May 2011 00:37:43 -0700 (PDT) Received: from book3.c-l-i.net (book3.c-l-i.net [204.62.249.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.bondis.org (Postfix) with ESMTPSA id 96AE11AB301; Tue, 24 May 2011 07:37:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joao Damas In-Reply-To: Date: Tue, 24 May 2011 09:37:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DC94AE6.5000903@ogud.com> <878vtxku9a.fsf@mid.deneb.enyo.de> To: Edward Lewis X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC ENDS0-bis 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, 24 May 2011 07:37:45 -0000 On 23 May 2011, at 23:08, Edward Lewis wrote: > At 23:00 +0200 5/23/11, Florian Weimer wrote: >> * Olafur Gudmundsson: >>=20 >>> This document obsoletes RFC2671. The big changes from RFC2671 are: >>> - explicit usage of RFC2119 terms and labeling EDNS0 support as = MUST; >>> - discussion on payload sizes and selection; >>> - closing of the extended label types registry and classifying >>> bit-labels as Historic; >>> - cleanup of IANA actions (that did not take place when RFC2671 >>> was issued). >>=20 >> I would like to see guidance to implementors how they can actually >> detect EDNS0 support or the lack thereof. Alternatively, a minimum >> level of support could be made mandatory, eventually making the >> existing detection logic obsolete. >=20 > As far as declaring "a minimum level of support": an RFC cannot say = "you must implement me, even if you were implemented last year." That = just doesn't work. >=20 Yep. > For backwards compatibility, we are stuck with probing for = functionality. This is a weakness of the DNS architecture. > --=20 DNS transactions are meant to take a minimum of resources on either = side. That is kind of contrary to a feature negotiation handshake ahead = of the query (though one could cache a server's characteristics after = the first exchange if the two messages, query and response, are able to = transport that information. I think that's all that could be said here Joao From fw@deneb.enyo.de Wed May 25 10:49:51 2011 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 50832E06A1 for ; Wed, 25 May 2011 10:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDyshdkKGBHl for ; Wed, 25 May 2011 10:49:50 -0700 (PDT) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id BD240E070A for ; Wed, 25 May 2011 10:49:50 -0700 (PDT) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QPIDL-00044f-Qc; Wed, 25 May 2011 19:49:47 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.72) (envelope-from ) id 1QPIDL-0007ei-Id; Wed, 25 May 2011 19:49:47 +0200 From: Florian Weimer To: Edward Lewis References: <4DC94AE6.5000903@ogud.com> <878vtxku9a.fsf@mid.deneb.enyo.de> Date: Wed, 25 May 2011 19:49:47 +0200 In-Reply-To: (Edward Lewis's message of "Mon\, 23 May 2011 17\:08\:19 -0400") Message-ID: <87r57mwtz8.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC ENDS0-bis 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, 25 May 2011 17:49:51 -0000 * Edward Lewis: >>I would like to see guidance to implementors how they can actually >>detect EDNS0 support or the lack thereof. Alternatively, a minimum >>level of support could be made mandatory, eventually making the >>existing detection logic obsolete. > > As far as declaring "a minimum level of support": an RFC cannot say > "you must implement me, even if you were implemented last year." That > just doesn't work. A vendor which errors out or drops EDNS0-enabled queries would no longer be able to claim to implement the current version of the DNS protocol. It worked for HTTP/0.9 and SSLv2. It did not work for extended label types or RIPv1. > For backwards compatibility, we are stuck with probing for > functionality. This is a weakness of the DNS architecture. It's not an architectural problem, I think. You could implement pretty reliable signaling, but EDNS0 doesn't do it. (Basically, you need two bits, the query contains 01, and the response 10, so that you can detect stripping and dumb reflection.) Anyway, what I'm asking for is documentation for the probing algorithm. Are there existing implementations which use the presence of DNSSEC data as an indicator for EDNS0 support, as suggested in the draft? From paf@cisco.com Wed May 25 11:51:12 2011 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 10C78E0717 for ; Wed, 25 May 2011 11:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JDxgqNkXwYV for ; Wed, 25 May 2011 11:51:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 37DECE06A1 for ; Wed, 25 May 2011 11:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=892; q=dns/txt; s=iport; t=1306349471; x=1307559071; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=GYi7HNHvrP6BsyFWvu6DOywntMAKklH+D3X7UzmrKDg=; b=Dx8CeLOSHIb57f6z3ehroF0rooq+xEl4eUqr3tN3jnF9fbSnYsujUjNp mWy/IGG75apZ5nljzFXA1rMeTNGBaI47yd6e74rYkWVN0RegQvTrK1REU DEg2DkWLNROr0abgFqIMY5eqG4Rkm1hAdPigWlR0XV/BVfaQeBUWU/jWM E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgGAHBP3U2rRDoH/2dsb2JhbACYJ44FeKYRgR2da4YcBJAvjyM X-IronPort-AV: E=Sophos;i="4.65,268,1304294400"; d="scan'208";a="703315935" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 25 May 2011 18:51:10 +0000 Received: from sjc-vpn7-1534.cisco.com (sjc-vpn7-1534.cisco.com [10.21.149.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4PIp9cS011458 for ; Wed, 25 May 2011 18:51:09 GMT From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 25 May 2011 14:51:09 -0400 Message-Id: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> To: dnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal 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, 25 May 2011 18:51:12 -0000 As the wg shepherd on the document draft-ietf-dnsext-dnssec-algo-signal, = I am hereby informing we today start a four week working group last = call. Abstract 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 they support. The authors have informed me that there is one issue they specifically = would like to have comment on: how the option effects the hop-by-hop = nature of EDNS. They believe they addressed those concerns in the = updated Section 3.4 about recursive resolver considerations. The wg last call ends on June 22, 2011. Patrik From paul.hoffman@vpnc.org Wed May 25 12:09:40 2011 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 1054D130087 for ; Wed, 25 May 2011 12:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhxuF7ex+rYh for ; Wed, 25 May 2011 12:09:38 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 72EF4130081 for ; Wed, 25 May 2011 12:09:38 -0700 (PDT) Received: from [165.227.249.211] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4PJ9XeC051187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 25 May 2011 12:09:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> Date: Wed, 25 May 2011 12:09:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1084) Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal 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, 25 May 2011 19:09:40 -0000 I have read this document and support its publication. I have = reservations about its actual utility, but in the absence of any better = proposal to help zone administrators decide when to change algorithms, = this approach seems reasonable and worthy of standardization. --Paul Hoffman From Ed.Lewis@neustar.biz Wed May 25 13:16:44 2011 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 C0DD21300B6 for ; Wed, 25 May 2011 13:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.691 X-Spam-Level: X-Spam-Status: No, score=-105.691 tagged_above=-999 required=5 tests=[AWL=-0.788, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQLBAUFFboWX for ; Wed, 25 May 2011 13:16:44 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id D0A69130085 for ; Wed, 25 May 2011 13:16:43 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p4PKGd69014302; Wed, 25 May 2011 16:16:39 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.118] by work-laptop-2 (PGP Universal service); Wed, 25 May 2011 16:16:40 -0400 X-PGP-Universal: processed; by work-laptop-2 on Wed, 25 May 2011 16:16:40 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> Date: Wed, 25 May 2011 16:16:37 -0400 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Edward Lewis Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz, dnsext@ietf.org Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal 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, 25 May 2011 20:16:44 -0000 At 14:51 -0400 5/25/11, Patrik F=E4ltstr=F6m wrote: >As the wg shepherd on the document draft-ietf-dnsext-dnssec-algo-signal, I >am hereby informing we today start a four week working group last call. I'm assuming you mean this document: http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-01 I don't support this document even though I support this ideal: # This proposed EDNS option serves to measure the acceptance and use of # new digital signing and hash algorithms. (That is - I don't think this document achieves its goal.) I get that it is good to know what the right=20 algorithm (in the DNSSEC sense) to use is. But I=20 don't like the thought that a client's algorithm=20 request would be used to alter the contents of an=20 response. It would be better to be aware of=20 algorithms, what's deployed, and what to signed=20 with in a strategic posture, not a tactical=20 posture. In the document there is this in section 5: # When an authoritative server sees the DAU option in the OPT meta-RR # in a request the normal algorithm for servicing requests is followed. However, in 3.1 it says this: # Typically, stub resolvers rely on an upstream recursive server (or # cache) to provide a response; any algorithm support on the stub # resolver's side SHOULD be honored (if possible) by an upstream # recursive cache. What if a server is both authoritative and an=20 upstream recursive cache? If, "honored" (in the=20 latter draft fragment) means to send only the=20 algorithm that is in the stub's request OPT RR,=20 there's a conflict with "normal...servicing." I feel that this draft has the potential to open=20 up a can of worms with interactions between=20 signaling bits (namely DNSSEC OK in EDNS0 and the=20 CD bit in the header) and having to deal up and=20 down the authority to (validating) forwarder to=20 (validating) cache to stub resolvers. I don't think that algorithm roll (or choice) is=20 the issue we thought it was a few years ago when=20 the idea behind this draft came up, i.e., I don't=20 see the draft solving a real problem. For=20 example, it could be more likely that a=20 recommendation will come out to change key size=20 from 1024 to 2048 than change from SHA-1 to=20 SHA-256. Recent haggling over hash algorithms=20 has convinced me that attacks on hash algorithms=20 aren't much of a threat because of the limited=20 syntax of DNS records. Perhaps even less of a=20 threat than the difference in key lengths. I don't think this option is needed now, and=20 could cause architectural pain later on. PS : Section 4 shouldn't be there (at least not=20 standalone). And there is no reference or=20 definition of "middlebox." This is incorrect in 3.4.1: # A validating recursive resolver MUST set the DO bit [RFC4035] to # indicate that it wishes to receive DNSSEC RRs in the response. If Try this, as an example: "$ dig @a.dns.jp jp dnskey" (No EDNS0, no DO, but I get DNSKEY records back.) -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From internet-drafts@ietf.org Thu May 26 06:39:57 2011 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 1C66EE073C; Thu, 26 May 2011 06:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17NIbtVPZd9g; Thu, 26 May 2011 06:39:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E5DE0657; Thu, 26 May 2011 06:39:56 -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: 3.55 Message-ID: <20110526133956.21761.91655.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2011 06:39:56 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-registry-fixes-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 13:39:57 -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 : Applicability Statement: DNS Security (DNSSEC) DNSKEY Al= gorithm IANA Registry Author(s) : Scott Rose Filename : draft-ietf-dnsext-dnssec-registry-fixes-08.txt Pages : 8 Date : 2011-05-26 The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms that is incomplete in that it lacks the implementation status of each algorithm. This document provides an applicability statement on algorithm implementation compliance status for DNSSEC implementations. This status is to measure compliance to this RFC only. This document replaces that registry table with a new IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers that lists (or assigns) each algorithm's status based on the current reference. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-fixes= -08.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-registry-fixes-= 08.txt From scottr.nist@gmail.com Thu May 26 06:46:50 2011 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 AA769E06D6 for ; Thu, 26 May 2011 06:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZR8WBohw7L0 for ; Thu, 26 May 2011 06:46:49 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id C31B6E0657 for ; Thu, 26 May 2011 06:46:48 -0700 (PDT) Received: by wwk4 with SMTP id 4so4466198wwk.1 for ; Thu, 26 May 2011 06:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=EMzdsEE0DHWoBfTnuYqs18PzSiOadZlQq3ST6KSC114=; b=Xa/XX/zBIU4/lsKlf1gqEqrvWYa8+3ihvjhDSd/ZK4lTCWOJ/xvGOc2wVbQa+DqBNe ZOeFkIJxtsKOCYk2iHNi5UINEjY92ow9z8fe2fyL0p7ZLb6RUnff8fAsCCPatynYVyEP UzYvSDXiCEH5DqSTEMVa8+aZkOlNxZPuuRYFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=ElYY1F2VftW0d6qx9gcLoPNT1WDIZflMxpRycFQWJL6ttaw700Ej8flrNM9h6iBPxx p09ZckQ199KPke4B1Y+MwkwBZbyqjHnohGVxeiNuoHYn/zH8FiBXmqcxObcF0YzXIgW3 wTpSvo1rBetRrudF8EiZtazxoY7vDjS8YykQw= MIME-Version: 1.0 Received: by 10.216.46.21 with SMTP id q21mr5819701web.113.1306417607619; Thu, 26 May 2011 06:46:47 -0700 (PDT) Received: by 10.216.9.66 with HTTP; Thu, 26 May 2011 06:46:47 -0700 (PDT) In-Reply-To: <20110526133956.21761.91655.idtracker@ietfa.amsl.com> References: <20110526133956.21761.91655.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2011 09:46:47 -0400 Message-ID: From: Scott Rose To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=0016e65512d26e350b04a42e0d09 Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-registry-fixes-08.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: scott.rose@nist.gov List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 13:46:50 -0000 --0016e65512d26e350b04a42e0d09 Content-Type: text/plain; charset=ISO-8859-1 This version is basically a copy edit revision - fixing some of the text for readability and included some statements about the text being normative and not the IANA registry this document creates. This is in response to several comments about the purpose of the document. Scott On Thu, May 26, 2011 at 9:39 AM, wrote: > 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. > > Title : Applicability Statement: DNS Security (DNSSEC) > DNSKEY Algorithm IANA Registry > Author(s) : Scott Rose > Filename : draft-ietf-dnsext-dnssec-registry-fixes-08.txt > Pages : 8 > Date : 2011-05-26 > > The DNS Security Extensions (DNSSEC) requires the use of > cryptographic algorithm suites for generating digital signatures over > DNS data. There is currently an IANA registry for these algorithms > that is incomplete in that it lacks the implementation status of each > algorithm. This document provides an applicability statement on > algorithm implementation compliance status for DNSSEC > implementations. This status is to measure compliance to this RFC > only. This document replaces that registry table with a new IANA > registry table for Domain Name System Security (DNSSEC) Algorithm > Numbers that lists (or assigns) each algorithm's status based on the > current reference. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-fixes-08.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-registry-fixes-08.txt > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --0016e65512d26e350b04a42e0d09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This version is basically a copy edit revision - fixing some of the text fo= r readability and included some statements about the text being normative a= nd not the IANA registry this document creates. =A0This is in response to s= everal comments about the purpose of the document.

Scott


On Thu, M= ay 26, 2011 at 9:39 AM, <internet-drafts@ietf.org> wrote:
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.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Applicability Statement: DNS Se= curity (DNSSEC) DNSKEY Algorithm IANA Registry
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Scott Rose
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-dnsext-dnssec-registry= -fixes-08.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-26

=A0 The DNS Security Extensions (DNSSEC) requires the use of
=A0 cryptographic algorithm suites for generating digital signatures over<= br> =A0 DNS data. =A0There is currently an IANA registry for these algorithms<= br> =A0 that is incomplete in that it lacks the implementation status of each<= br> =A0 algorithm. =A0This document provides an applicability statement on
=A0 algorithm implementation compliance status for DNSSEC
=A0 implementations. =A0This status is to measure compliance to this RFC =A0 only. =A0This document replaces that registry table with a new IANA =A0 registry table for Domain Name System Security (DNSSEC) Algorithm
=A0 Numbers that lists (or assigns) each algorithm&#39;s status based = on the
=A0 current reference.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/d= raft-ietf-dnsext-dnssec-registry-fixes-08.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/dra= ft-ietf-dnsext-dnssec-registry-fixes-08.txt
_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext

--0016e65512d26e350b04a42e0d09-- From iesg-secretary@ietf.org Thu May 26 08:22:57 2011 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 BB11BE0718; Thu, 26 May 2011 08:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tRibxZYRQ0v; Thu, 26 May 2011 08:22:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE07E0677; Thu, 26 May 2011 08:22:57 -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: 3.55 Message-ID: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2011 08:22:57 -0700 Cc: dnsext@ietf.org Subject: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) 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, 26 May 2011 15:22:57 -0000 The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry' as a 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 2011-06-09. 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 The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms that is incomplete in that it lacks the implementation status of each algorithm. This document provides an applicability statement on algorithm implementation compliance status for DNSSEC implementations. This status is to measure compliance to this RFC only. This document replaces that registry table with a new IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers that lists (or assigns) each algorithm's status based on the current reference. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-fixes/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-fixes/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu May 26 13:56:29 2011 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 9C994E07AB; Thu, 26 May 2011 13:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24VUKp4vs3dE; Thu, 26 May 2011 13:56:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254E6E0796; Thu, 26 May 2011 13:56:29 -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: 3.55 Message-ID: <20110526205629.21816.5196.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2011 13:56:29 -0700 Cc: dnsext@ietf.org Subject: [dnsext] Last Call: (Update to DNAME Redirection in the DNS) 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, 26 May 2011 20:56:29 -0000 The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Update to DNAME Redirection in the DNS' as a 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 2011-06-09. 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 The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2672bis-dname/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2672bis-dname/ No IPR declarations have been submitted directly on this I-D. From presnick@qualcomm.com Mon May 30 16:53:41 2011 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 C3D40E073C; Mon, 30 May 2011 16:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.589 X-Spam-Level: X-Spam-Status: No, score=-105.589 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_00=-2.599, GB_OPRAH=2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUp9QP4MSKbh; Mon, 30 May 2011 16:53:40 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id D0C5CE0700; Mon, 30 May 2011 16:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1306799620; x=1338335620; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DE42E02.8070706@qualcomm.com>|Date:=20Mo n,=2030=20May=202011=2018:53:38=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20|CC:=20|Subject:=20Re:=20Last=20Call:=20=09(Applicability=0D=0A =20Statement:=20DNS=20Security=20(DNSSEC)=20DNSKEY=09Algo rithm=20IANA=20Registry)=20to=20Proposed=0D=0A=20Standard |References:=20<20110526152257.21795.30012.idtracker@ietf a.amsl.com>|In-Reply-To:=20<20110526152257.21795.30012.id tracker@ietfa.amsl.com>|Content-Type:=20text/plain=3B=20c harset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=TIyVjsg/sGnKItcT9Jz/ylMj7NaQeqiw0oelH+iU9Bk=; b=DImm5sW2q3HcF3R9sMQ2VpKrnO3tOYwwYR7GymxW703HPeoAKTXDxWqo dQjWesozs6tHwV4yQeZyVrr8PUY6c3ahyjCor8LGL0YRb7frTujkDw2Tg wrKk2CalnhlFjg61TCOudbeUe6GCKgLKglYdxXvs+s0GUjBtRHWxFAwvN s=; X-IronPort-AV: E=McAfee;i="5400,1158,6362"; a="94339303" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 30 May 2011 16:53:40 -0700 X-IronPort-AV: E=Sophos;i="4.65,291,1304319600"; d="scan'208";a="141712666" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 30 May 2011 16:53:40 -0700 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 30 May 2011 16:53:39 -0700 Message-ID: <4DE42E02.8070706@qualcomm.com> Date: Mon, 30 May 2011 18:53:38 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> In-Reply-To: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) 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: Mon, 30 May 2011 23:53:41 -0000 On 5/26/11 10:22 AM, The IESG wrote: > The IESG has received a request from the DNS Extensions WG (dnsext) to > consider the following document: > - 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA > Registry' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Speaking as individual, not AD. The document says in section 2.1: > 2.1. Updates and Additions > > This document updates three entries in the Domain Name System > Security (DNSSEC) Algorithm Registry. They are: > > The description for assignment number 4 is changed to "Reserved until > 2020". > > The description for assignment number 9 is changed to "Reserved until > 2020". > > The description for assignment number 11 is changed to "Reserved > until 2020". OK, I give up....What happens in the year 2020? The end of the Mayan calendar? Another prediction of the coming apocalypse? Oprah will return? Without the jokes: I find "due dates" in standards completely ridiculous, without any purpose, and object strongly to them. I cannot see what the dates add to the reservation of these code points, and there is no explanation of dates (let alone these *particular* dates) in the draft. These either need to be explained in excruciating detail or removed. > Registry entries 13-251 remains Unassigned. That would be a surprise, since the current registry at says: 13-122 Unassigned 123-251 Reserved [RFC6014][standards track] This document makes a change to 123-251. That either needs justification in the document or needs to be reverted. In my (personal) opinion, this document is not ready for publication in its current form. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From ajs@anvilwalrusden.com Tue May 31 04:12:11 2011 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 EDA6FE0830; Tue, 31 May 2011 04:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, GB_OPRAH=2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE3JaR9wjELn; Tue, 31 May 2011 04:12:11 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEE4E082D; Tue, 31 May 2011 04:12:11 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4D7BB1ECB41C; Tue, 31 May 2011 11:12:09 +0000 (UTC) Date: Tue, 31 May 2011 07:12:08 -0400 From: Andrew Sullivan To: Pete Resnick Message-ID: <20110531111207.GB25706@shinkuro.com> References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> <4DE42E02.8070706@qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE42E02.8070706@qualcomm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ietf@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) 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: Tue, 31 May 2011 11:12:12 -0000 On Mon, May 30, 2011 at 06:53:38PM -0500, Pete Resnick wrote: > >2.1. Updates and Additions > > > > This document updates three entries in the Domain Name System > > Security (DNSSEC) Algorithm Registry. They are: > > > > The description for assignment number 4 is changed to "Reserved until > > 2020". > > > > The description for assignment number 9 is changed to "Reserved until > > 2020". > > > > The description for assignment number 11 is changed to "Reserved > > until 2020". > > OK, I give up....What happens in the year 2020? The end of the Mayan > calendar? Another prediction of the coming apocalypse? Oprah will > return? > > Without the jokes: I find "due dates" in standards completely > ridiculous, without any purpose, and object strongly to them. I > cannot see what the dates add to the reservation of these code > points, and there is no explanation of dates (let alone these > *particular* dates) in the draft. These either need to be explained > in excruciating detail or removed. These are all typecodes that have "leaked". In the case of 4, it was "reserved for elliptic curve" but it is clear that there may be more than one elliptic curve algorithm and we can't be sure which curve might be being tested with this. In the case of 9 and 11, it was due to a keen implementer of SHA2. The SHA2 specification originally left WGLC with two numbers for each of SHA256 and SHA512. This was to "alias" NSEC vs. NSEC3 (see how SHA1 is handled). After WGLC, some WG participants objected vociferously, and it became clear that WG consensus was against such aliasing. But one implementation had already shipped with the four assignments in place. We picked 2020 as a time by which we figured any software using any of this would have to have been updated. My personal preference would have been to specify that the four code points were all reserved until all other code points were used, but that seemed too complicated a rule so we picked 2020. Why do you think this all needs to be outlined in the draft? Why do such rules (which are, after all, just destined for a registry) need to be given a rationale? > > Registry entries 13-251 remains Unassigned. > > That would be a surprise, since the current registry at This is my fault; I missed it in my own review. The draft will be updated to reflect the changes to the registry made by RFC 6014 (which reserves 123-251). Thanks for catching this. A (as document shepherd) -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Tue May 31 07:42:39 2011 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 3802BE06B7; Tue, 31 May 2011 07:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.554 X-Spam-Level: X-Spam-Status: No, score=-101.554 tagged_above=-999 required=5 tests=[AWL=-0.955, BAYES_00=-2.599, GB_OPRAH=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvyTDv6tDxw6; Tue, 31 May 2011 07:42:38 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E8DAFE068E; Tue, 31 May 2011 07:42:32 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4VEgSQl046921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 May 2011 07:42:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110531111207.GB25706@shinkuro.com> Date: Tue, 31 May 2011 07:42:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7212D562-D16F-42C3-96F0-5B91CE8C50F9@vpnc.org> References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> <4DE42E02.8070706@qualcomm.com> <20110531111207.GB25706@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: Pete Resnick , ietf@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) 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: Tue, 31 May 2011 14:42:39 -0000 On May 31, 2011, at 4:12 AM, Andrew Sullivan wrote: > On Mon, May 30, 2011 at 06:53:38PM -0500, Pete Resnick wrote: >=20 >>> 2.1. Updates and Additions >>>=20 >>> This document updates three entries in the Domain Name System >>> Security (DNSSEC) Algorithm Registry. They are: >>>=20 >>> The description for assignment number 4 is changed to "Reserved = until >>> 2020". >>>=20 >>> The description for assignment number 9 is changed to "Reserved = until >>> 2020". >>>=20 >>> The description for assignment number 11 is changed to "Reserved >>> until 2020". >>=20 >> OK, I give up....What happens in the year 2020? The end of the Mayan >> calendar? Another prediction of the coming apocalypse? Oprah will >> return? >>=20 >> Without the jokes: I find "due dates" in standards completely >> ridiculous, without any purpose, and object strongly to them. I >> cannot see what the dates add to the reservation of these code >> points, and there is no explanation of dates (let alone these >> *particular* dates) in the draft. These either need to be explained >> in excruciating detail or removed. >=20 > These are all typecodes that have "leaked".=20 >=20 > In the case of 4, it was "reserved for elliptic curve" but it is clear > that there may be more than one elliptic curve algorithm and we can't > be sure which curve might be being tested with this. >=20 > In the case of 9 and 11, it was due to a keen implementer of SHA2. > The SHA2 specification originally left WGLC with two numbers for each > of SHA256 and SHA512. This was to "alias" NSEC vs. NSEC3 (see how > SHA1 is handled). After WGLC, some WG participants objected > vociferously, and it became clear that WG consensus was against such > aliasing. But one implementation had already shipped with the four > assignments in place. >=20 > We picked 2020 as a time by which we figured any software using any of > this would have to have been updated. My personal preference would > have been to specify that the four code points were all reserved until > all other code points were used, but that seemed too complicated a > rule so we picked 2020. It sounds like Pete is saying "picking 2020 is complicated", so maybe = the original idea ("until all other code points are used") is better. > Why do you think this all needs to be outlined in the draft? Why do > such rules (which are, after all, just destined for a registry) need > to be given a rationale? =20 So that someone evaluating the document can understand the rationale for = the decision points in the document. Switching to "until all other code = points are used" is self-explaining. --Paul Hoffman From scottr.nist@gmail.com Tue May 31 10:18:04 2011 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 B2861E068E for ; Tue, 31 May 2011 10:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4KMV3l2sYNz for ; Tue, 31 May 2011 10:18:04 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B571DE0662 for ; Tue, 31 May 2011 10:18:03 -0700 (PDT) Received: by wyb29 with SMTP id 29so4102323wyb.31 for ; Tue, 31 May 2011 10:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=fb0zYENajew1NfPjwpQMNPfBF3+Qvb+YCMQK8EIeu+c=; b=AcVwoQTkmMb2Ukv5jhvDsn0PMyjgvl/aTlxbll5AeV8wVEXFa2NUipKBf2gnkf3szM snyxkgRpUkCh8WieAzecmt6IzRXPQZEc/uQNeIF49KvRNRPpZVDF1DMjH/AhZS1cOC2v Omp0f0W7o0buxxSrs5fSxpVypyT/4ifPymCGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=FVtIe/2tNsqlnQ4dfrHP98bjpZEFE2QvPAwTWLr3RkC9gcrafj5IONOtBdwxSBt7Eo G15/jhK3IJPXBFkGx/grn2XsUhkpYT4BM0Xjruz21BsZ6I8TRiQPNjIXGfeymeokErgK jtiVtXqFgC4hb4F/zEVnmKIK+knNXL5Sz87K0= MIME-Version: 1.0 Received: by 10.216.14.199 with SMTP id d49mr6018706wed.65.1306862282664; Tue, 31 May 2011 10:18:02 -0700 (PDT) Received: by 10.216.87.21 with HTTP; Tue, 31 May 2011 10:18:02 -0700 (PDT) Date: Tue, 31 May 2011 13:18:02 -0400 Message-ID: From: Scott Rose To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=001485f9a7c820eb0d04a4959629 Subject: [dnsext] Small proposed change to draft-registry-fixes X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: scott.rose@nist.gov List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:18:04 -0000 --001485f9a7c820eb0d04a4959629 Content-Type: text/plain; charset=ISO-8859-1 There was a comment during last call of draft-registry-fixes about Section 2.1. The text: The description for assignment number 4 is changed to "Reserved until 2020". The description for assignment number 9 is changed to "Reserved until 2020". The description for assignment number 11 is changed to "Reserved until 2020". The reasoning behind the date 2010 was an attempt to "wait out" older implementations that may have included these codes as previous reservations for algorithms that were never specified. The proposed text would change "Reserved until 2020" in the above to "Reserved until all other codes have been allocated" Or should it simply be "Reserved" and leave it at that? Scott --001485f9a7c820eb0d04a4959629 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There was a comment during last call of draft-registry-fixes about Section = 2.1. =A0The text:

The description for assignment nu= mber 4 is changed to "Reserved until
=A0 =A02020".

=A0 =A0The description for assignment number 9 is changed to= "Reserved until
=A0 =A02020".

=A0 =A0The description for assignment number 11 is changed to "Reserv= ed
=A0 =A0until 2020".


The reasoning behind the date 2010 was an attempt to "wait out" = older implementations that may
have included these codes as previ= ous reservations for algorithms that were never specified.

The proposed text would change "Reserved until 202= 0" in the above to "Reserved until all other codes have been allo= cated"

Or should it simply be "Reserved&= quot; and leave it at that?

Scott
--001485f9a7c820eb0d04a4959629-- From paul.hoffman@vpnc.org Tue May 31 10:20:50 2011 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 9281AE088E for ; Tue, 31 May 2011 10:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff2eycvTzjLo for ; Tue, 31 May 2011 10:20:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 54C2CE0860 for ; Tue, 31 May 2011 10:20:49 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4VHKkle058701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 May 2011 10:20:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 31 May 2011 10:20:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: scott.rose@nist.gov X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] Small proposed change to draft-registry-fixes 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, 31 May 2011 17:20:50 -0000 On May 31, 2011, at 10:18 AM, Scott Rose wrote: > There was a comment during last call of draft-registry-fixes about = Section 2.1. The text: >=20 > The description for assignment number 4 is changed to "Reserved until > 2020". >=20 > The description for assignment number 9 is changed to "Reserved = until > 2020". >=20 > The description for assignment number 11 is changed to "Reserved > until 2020". >=20 >=20 > The reasoning behind the date 2010 was an attempt to "wait out" older = implementations that may > have included these codes as previous reservations for algorithms that = were never specified. >=20 > The proposed text would change "Reserved until 2020" in the above to = "Reserved until all other codes have been allocated" >=20 > Or should it simply be "Reserved" and leave it at that? The latter has the same effect as the former and is less contentious. --Paul Hoffman From Ed.Lewis@neustar.biz Tue May 31 10:33:19 2011 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 E0A83E06A0 for ; Tue, 31 May 2011 10:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.408 X-Spam-Level: X-Spam-Status: No, score=-106.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YGHgyPoVgA3 for ; Tue, 31 May 2011 10:33:14 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 93D36E068E for ; Tue, 31 May 2011 10:33:14 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p4VHX9ae043203; Tue, 31 May 2011 13:33:10 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.129.58] by Work-Laptop-2.local (PGP Universal service); Tue, 31 May 2011 13:33:10 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 31 May 2011 13:33:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 31 May 2011 13:32:58 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Small proposed change to draft-registry-fixes 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, 31 May 2011 17:33:20 -0000 At 13:18 -0400 5/31/11, Scott Rose wrote: >Or should it simply be "Reserved" and leave it at that? How soon are we going to run out of numbers? (It's not like we haven't been sloppy before. See RR type code 3,4,7,8,10,...,40, or my favorites 32 [double useless] and 33 [half useless].) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From ajs@anvilwalrusden.com Tue May 31 10:54:18 2011 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 46EB3E06D9; Tue, 31 May 2011 10:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnxujNdNXsU7; Tue, 31 May 2011 10:54:17 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 90FD0E06C0; Tue, 31 May 2011 10:54:17 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A81961ECB41C; Tue, 31 May 2011 17:54:15 +0000 (UTC) Date: Tue, 31 May 2011 13:54:14 -0400 From: Andrew Sullivan To: ietf@ietf.org, dnsext@ietf.org Message-ID: <20110531175413.GI25706@shinkuro.com> References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> <4DE42E02.8070706@qualcomm.com> <20110531111207.GB25706@shinkuro.com> <7212D562-D16F-42C3-96F0-5B91CE8C50F9@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7212D562-D16F-42C3-96F0-5B91CE8C50F9@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) 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: Tue, 31 May 2011 17:54:18 -0000 On Tue, May 31, 2011 at 07:42:28AM -0700, Paul Hoffman wrote: > It sounds like Pete is saying "picking 2020 is complicated", so > maybe the original idea ("until all other code points are used") is > better. > > > Why do you think this all needs to be outlined in the draft? Why do > > such rules (which are, after all, just destined for a registry) need > > to be given a rationale? > > So that someone evaluating the document can understand the rationale > for the decision points in the document. Switching to "until all > other code points are used" is self-explaining. In that case, I think the right answer is to do something along the following lines: 1. Alter the relevant passage in section 2.1 as follows: The description for assignment number 4 is changed to "Reserved". The description for assignment number 9 is changed to "Reserved". The description for assignment number 11 is changed to "Reserved". 2. Alter the new registry table in the same way. 3. Add a subsection 2.4, "Rationale for reserving assignments 4, 9, and 11", as follows: Assignment numbers 4, 9, and 11 are believed to have been used in software released on the Internet prior to the publication of this memo, which is why they are hereby reserved. The assignments were never requested of nor made by IANA. The point of (3) is to make the reasoning clear and to make it clear to future IETF participants that they could plausibly reuse those code points after sufficient time had passed. (We have a problem in the DNS of much of the reasoning being contained in our oral tradition, and I'd like to break that cycle.) How's that sound? A -- Andrew Sullivan ajs@anvilwalrusden.com From roy@nominet.org.uk Tue May 31 15:16:45 2011 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 26541E072C for ; Tue, 31 May 2011 15:16:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FJM6wi13rLY for ; Tue, 31 May 2011 15:16:44 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id DB40CE066A for ; Tue, 31 May 2011 15:16:42 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version; b=QXoxXD0SzIl3tD3Es4ehXvl3MmWxAPvOHltnNxsJ2jfoigHfLXRTtGSb rHf4/T4JcObNU9U5dcVut3MVVxYpXnR3etKnsOzq3FrzVqa2101ym5+Vw s3WnEyorLhV/skZ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1306880204; x=1338416204; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Roy=20Arends=20|Subject:=20R e:=20[dnsext]=20CDS=20RRTYPE=20review=20-=20Comments=20pe riod=20end=20Mar=2029th|Date:=20Tue,=2031=20May=202011=20 22:16:37=20+0000|Message-ID:=20|To:=20"dnsext@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<3d52a802-7b56-472a-b535-d95fbf51 27ac>|In-Reply-To:=20; bh=swTdtuOnm6oZ2gMh5KhsVRZOJbbxR93gLJk+zrSMAeg=; b=tO/P8RdvLWCfZKnmIalP2w2VTIoUiBpHE6LkNYoNuB+QpCOgU/keL5zy xxbm1fy7zpcIz9sXwOK5dPHcP7WTfkxLptPoW+g+rdzP+vDZ2wgxE2ppX qm05eMr2SKIhX7v; X-IronPort-AV: E=Sophos;i="4.65,299,1304290800"; d="scan'208";a="33258371" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 31 May 2011 23:16:40 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Tue, 31 May 2011 23:16:40 +0100 From: Roy Arends To: "dnsext@ietf.org" Thread-Topic: [dnsext] CDS RRTYPE review - Comments period end Mar 29th Thread-Index: AQHMH+BpQhUPzoiiUEGdG1ZU15OyDw== Date: Tue, 31 May 2011 22:16:37 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <3d52a802-7b56-472a-b535-d95fbf5127ac> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th 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, 31 May 2011 22:16:45 -0000 Dear WG, This message ends the review process for the CDS RRTYPE, according to my judgment this request meets both requirements of section 3.1.1 and none of section 3.1.2 of RFC5395 and should be accepted. Best Regards, Roy Arends On 3/8/11 7:33 PM, "Roy Arends" wrote: > Dear Colleagues, >=20 > Below is a resubmission of a completed template requesting a new > RRTYPE assignment under the procedures of RFC5395. >=20 > This message starts a 3 weeks period for an expert-review of the DNS > RRTYPE parameter allocation for URI specified in > http://tools.ietf.org/id/draft-barwood-dnsop-ds-publish-01.txt >=20 > If you have any new comments regarding this request that have not yet > being made, please post them here before Mar 29th 18:00 UTC. >=20 > Kind Regards, > Roy Arends >=20 > --begin 5395 template URI-- >=20 > A. Submission Date: 15 November 2010 >=20 > B. Submission Type: > [X] New RRTYPE > [ ] Modification to existing RRTYPE >=20 > C. Contact Information for submitter: > Name: George Barwood > Email Address: george.barwood@blueyonder.co.uk > International telephone number: +44 1452 722670 > Other contact handles: N/A >=20 > D. Motivation for the new RRTYPE application? >=20 > To allow a copy of the DS RRset [RFC4034] to be published > in the child zone, which is used to update the parent DS RRset. > It is expected that this will allow the rollover of a key signin= g > key to be automated. >=20 > E. Description of the proposed RR type. >=20 > The format is identical to the DS record. > However there is no special processing for servers/resolvers. >=20 > F. What existing RRTYPE or RRTYPEs come closest to filling that > need and why are they unsatisfactory? >=20 > None. >=20 > G. What mnemonic is requested for the new RRTYPE (optional)? >=20 > CDS to stand for "Child DS". >=20 > H. Does the requested RRTYPE make use of any existing IANA > Registry or require the creation of a new IANA sub-registry in > DNS Parameters? >=20 > It uses the same registries as the DS record. >=20 > I. Does the proposal require/expect any changes in DNS > servers/resolvers that prevent the new type from being > processed as an unknown RRTYPE (see [RFC3597])? >=20 > No. >=20 > J. Comments: > An RFC describing in detail how the CDS RRset may be used > to update the parent DS RRset is anticipated. The current draft > is draft-barwood-dnsop-ds-publish-01. >=20 > --end 5395 template URI-- >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From roy@nominet.org.uk Tue May 31 15:43:52 2011 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 4F7C2E0879 for ; Tue, 31 May 2011 15:43:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8F-XfRl1zel7 for ; Tue, 31 May 2011 15:43:51 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id 371FEE078B for ; Tue, 31 May 2011 15:43:50 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=igBU7Kie2crbrETjP8DBO1vk27/iutkvm2wm4VbpboW5puBkQq9Jnqrm 2k984hF5cbZ2oYP57Zg8Zt+9ZWe7uQoz+HmCDKXArqzUbObkxqJhyXTOd YvFzG+LWDaGm9Pj; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1306881831; x=1338417831; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Roy=20Arends=20|Subject:=20R equest=20for=20discussion=20on=20special=20dnssec=20proce ssing=20policy.|Date:=20Tue,=2031=20May=202011=2022:43:48 =20+0000|Message-ID:=20 |To:=20"dnsext@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20; bh=SkFvcksw5acQbgwoDpC/hjwyx33+2QgV0AI4kwXk4fU=; b=nyro+ZjbiOBxuZ+T/g8gmdwFFOvUTg/0UOGJFupR3dMTibc+HPduT2pw bHHzfFVVb2R1MsTr9fVzFjSUXQaFNF3+b0PBY5eoB+VnLVmGGjT0lNldq /CfywldW8oMd6ej; X-IronPort-AV: E=Sophos;i="4.65,299,1304290800"; d="scan'208";a="33258526" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 31 May 2011 23:43:50 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Tue, 31 May 2011 23:43:49 +0100 From: Roy Arends To: "dnsext@ietf.org" Thread-Topic: Request for discussion on special dnssec processing policy. Thread-Index: Acwf5DR1HxNOPyY5wkKrPkxXDy26KA== Date: Tue, 31 May 2011 22:43:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dnsext] Request for discussion on special dnssec processing policy. 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, 31 May 2011 22:43:52 -0000 Having done expert reviews a few times, I wonder if the 3.1.1. DNS RRTYPE Allocation Policy in RFC 5395 should be extended. Similar to 'additional section processing', requests for RRTYPE allocation can refer to special DNSSEC processing. As an example, the CDS draft states that the CDS type MUST be signed by a DNSKEY with the SEP flag set. To me, that is an exception to the general case, and could be considered 'special dnssec processing'. Note that I full= y understand the reasoning in the CDS draft, and also that SEP is merely an operational hint.... still, this is an exception. RFC 5395 does not address these concerns, hence my request for discussion. Let me know, Thanks, Roy From marka@isc.org Tue May 31 18:10:20 2011 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 F0F3EE07B5 for ; Tue, 31 May 2011 18:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=2.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpPc6S27dLdf for ; Tue, 31 May 2011 18:10:20 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id DF36BE0763 for ; Tue, 31 May 2011 18:10:19 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 35C4D5F98ED; Wed, 1 Jun 2011 01:10:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (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 B9FFB216C7A; Wed, 1 Jun 2011 01:09:58 +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 E528A102C648; Wed, 1 Jun 2011 11:09:56 +1000 (EST) To: Edward Lewis From: Mark Andrews References: In-reply-to: Your message of "Tue, 31 May 2011 13:32:58 -0400." Date: Wed, 01 Jun 2011 11:09:56 +1000 Message-Id: <20110601010956.E528A102C648@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Small proposed change to draft-registry-fixes 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, 01 Jun 2011 01:10:21 -0000 In message , Edward Lewis writes: > At 13:18 -0400 5/31/11, Scott Rose wrote: > > >Or should it simply be "Reserved" and leave it at that? > > How soon are we going to run out of numbers? We will *never* run out of numbers though it will take some standards work to extend the number space. We already have two working examples of how to do this (oid and domain). > (It's not like we haven't been sloppy before. See RR type code > 3,4,7,8,10,...,40, or my favorites 32 [double useless] and 33 [half > useless].) > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Now, don't say I'm always complaining. > Wait, that's a complaint, isn't it? > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org