From miekg@atoom.net Mon Jan 2 02:46:23 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2A921F8EFA for ; Mon, 2 Jan 2012 02:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghkN5AROYIJE for ; Mon, 2 Jan 2012 02:46:22 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1AE21F8D54 for ; Mon, 2 Jan 2012 02:46:21 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id B8EEB3FF5D; Mon, 2 Jan 2012 11:46:13 +0100 (CET) Date: Mon, 2 Jan 2012 11:46:13 +0100 From: Miek Gieben To: dnsext list Message-ID: <20120102104613.GB12764@miek.nl> Mail-Followup-To: dnsext list MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0ntfKIWw70PvrIHh" Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: [dnsext] SIG inception/expiration 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 Jan 2012 10:46:23 -0000 --0ntfKIWw70PvrIHh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello list, A recent dnssec-deployment discussion led to the question on why the expiration/inception time in the RRSIG are in the "wrong" order. I did some digging in the archives and the closest I found was this: In the drafts leading up to RFC 2065, the SIG RDATA is defined: http://tools.ietf.org/html/draft-ietf-dnssec-secext-00#section-5.1 In there it is: "time signed", "signature expiration" And then in -02 (there is no -01) http://tools.ietf.org/html/draft-ietf-dnssec-secext-02#section-4.1 It is: "signature expiration", "time signed". Where is stays up to RFC 2065. In RFC 2535 "time signed" is renamed to "signature inception", but the ordering isn't changed. So it's "signature expiration", "signature inceptio= n". Does anybody know (remember?) why the switch was made during=20 draft-ietf-dnssec-secext-00 and -02? grtz, --=20 Miek --0ntfKIWw70PvrIHh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8BivUACgkQJYuFzziA0PYtqACgglLkWBVw6nuATY4RqUHfaCcj 92kAnjwSiLsw45Cwp1/XywoUhY52IGGR =BCFa -----END PGP SIGNATURE----- --0ntfKIWw70PvrIHh-- From marka@isc.org Mon Jan 2 05:52:56 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856FE21F847F for ; Mon, 2 Jan 2012 05:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opdStMQnREBC for ; Mon, 2 Jan 2012 05:52:56 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF1021F847D for ; Mon, 2 Jan 2012 05:52:55 -0800 (PST) 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 5626E5F9891 for ; Mon, 2 Jan 2012 13:52:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:a5bf:2e56:edf6:466e]) (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 1E62E216C6A for ; Mon, 2 Jan 2012 13:52:34 +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 EAA9D1AC279D for ; Tue, 3 Jan 2012 00:52:27 +1100 (EST) To: dnsext list From: Mark Andrews References: <20120102104613.GB12764@miek.nl> Mail-Followup-To: dnsext list In-reply-to: Your message of "Mon, 02 Jan 2012 11:46:13 BST." <20120102104613.GB12764@miek.nl> Date: Tue, 03 Jan 2012 00:52:27 +1100 Message-Id: <20120102135227.EAA9D1AC279D@drugs.dv.isc.org> Subject: Re: [dnsext] SIG inception/expiration 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 Jan 2012 13:52:56 -0000 In message <20120102104613.GB12764@miek.nl>, Miek Gieben writes: > Hello list, > > A recent dnssec-deployment discussion led to the question on why the > expiration/inception time in the RRSIG are in the "wrong" order. Actually the order makes lots of sense. Expiration time is almost always the critical value in a signature. Inception time is almost always in the past. One could completely remove inception time and still have secure signatures. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From miekg@atoom.net Mon Jan 2 06:03:40 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2209C21F849B for ; Mon, 2 Jan 2012 06:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBYJBRmQtWds for ; Mon, 2 Jan 2012 06:03:39 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id A103A21F846B for ; Mon, 2 Jan 2012 06:03:39 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id 1CF243FFFB; Mon, 2 Jan 2012 15:03:38 +0100 (CET) Date: Mon, 2 Jan 2012 15:03:38 +0100 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20120102140337.GJ12764@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <20120102104613.GB12764@miek.nl> <20120102135227.EAA9D1AC279D@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCKy2vjPBX+S/5dE" Content-Disposition: inline In-Reply-To: <20120102135227.EAA9D1AC279D@drugs.dv.isc.org> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] SIG inception/expiration 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 Jan 2012 14:03:40 -0000 --FCKy2vjPBX+S/5dE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting at 00:52 on Jan 3 in "Re: [dnsext] SIG inc..." ] >=20 > In message <20120102104613.GB12764@miek.nl>, Miek Gieben writes: > > Hello list, > >=20 > > A recent dnssec-deployment discussion led to the question on why the > > expiration/inception time in the RRSIG are in the "wrong" order. >=20 > Actually the order makes lots of sense. Expiration time is almost > always the critical value in a signature. Inception time is almost > always in the past. One could completely remove inception time > and still have secure signatures. But was this the original reason to change the order? And someone, not trained in the Jedi ways of DNSSEC, will look at an RRSIG = and assume the first time stamp is the inception and the second one is expirati= on. grtz, --=20 Miek --FCKy2vjPBX+S/5dE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8BuTkACgkQJYuFzziA0Pb9agCg46Ni2Xc665aIMSRO1ctlOJI+ tFEAn0poEnXmhaKKUS6C/H6AhwKeNlbB =1mcq -----END PGP SIGNATURE----- --FCKy2vjPBX+S/5dE-- From bmanning@karoshi.com Mon Jan 2 07:13:08 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4D821F87FA for ; Mon, 2 Jan 2012 07:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KB1DCA0r5Js for ; Mon, 2 Jan 2012 07:13:07 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6910121F87D6 for ; Mon, 2 Jan 2012 07:13:07 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q02FD6JL027624 for ; Mon, 2 Jan 2012 15:13:07 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q02FD4Ef027623 for dnsext@ietf.org; Mon, 2 Jan 2012 15:13:04 GMT Date: Mon, 2 Jan 2012 15:13:04 +0000 From: bmanning@vacation.karoshi.com To: dnsext@ietf.org Message-ID: <20120102151304.GA27585@vacation.karoshi.com.> References: <20120102104613.GB12764@miek.nl> <20120102135227.EAA9D1AC279D@drugs.dv.isc.org> <20120102140337.GJ12764@miek.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120102140337.GJ12764@miek.nl> User-Agent: Mutt/1.4.1i Subject: Re: [dnsext] SIG inception/expiration 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 Jan 2012 15:13:09 -0000 On Mon, Jan 02, 2012 at 03:03:38PM +0100, Miek Gieben wrote: > [ Quoting at 00:52 on Jan 3 in "Re: [dnsext] SIG inc..." ] > > > > In message <20120102104613.GB12764@miek.nl>, Miek Gieben writes: > > > Hello list, > > > > > > A recent dnssec-deployment discussion led to the question on why the > > > expiration/inception time in the RRSIG are in the "wrong" order. > > > > Actually the order makes lots of sense. Expiration time is almost > > always the critical value in a signature. Inception time is almost > > always in the past. One could completely remove inception time > > and still have secure signatures. > > But was this the original reason to change the order? > > And someone, not trained in the Jedi ways of DNSSEC, will look at an RRSIG and > assume the first time stamp is the inception and the second one is expiration. > > grtz, > > -- > Miek it is possible to publish multiple sigs at the same time but covering different intervals. marks simplistic pov presumes that a sig is active when it appears. as for ordering, Ed may chime in anyday now... /bill > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From internet-drafts@ietf.org Mon Jan 2 12:44:27 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60A421F84B5; Mon, 2 Jan 2012 12:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXsImB+LM-RM; Mon, 2 Jan 2012 12:44:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FB121F84AE; Mon, 2 Jan 2012 12:44:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120102204427.31212.1972.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2012 12:44:27 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-ecdsa-02.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 20:44:28 -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 : Elliptic Curve DSA for DNSSEC Author(s) : Paul Hoffman Wouter Wijngaards Filename : draft-ietf-dnsext-ecdsa-02.txt Pages : 8 Date : 2012-01-02 This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-02.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-ecdsa-02.txt From hallam@gmail.com Mon Jan 2 15:50:35 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0999A21F8ABE for ; Mon, 2 Jan 2012 15:50:35 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW0ZengOHje2 for ; Mon, 2 Jan 2012 15:50:33 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CAE8721F8AC3 for ; Mon, 2 Jan 2012 15:50:33 -0800 (PST) Received: by obcuz6 with SMTP id uz6so13884075obc.31 for ; Mon, 02 Jan 2012 15:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1gQzdvPY2huTGoIDotKuB8H5ftxtls2wcK39SL0rf1E=; b=nz1wk562CCPR7RMPRuXkiszvp6KyWc6Rl7jKalCjDQRUpZZRcmKGpetsbY3P2svqTg 8GC5CXyHhKlJ54akwXFMARRRBhZSCaVji45MAHqIPXDnJWDAwonSB5PsyX6+/ImxT3zg KlWudcOAr4bSOrWnneb4I1+WD/gftko1fliAE= MIME-Version: 1.0 Received: by 10.182.43.10 with SMTP id s10mr38970321obl.43.1325548233200; Mon, 02 Jan 2012 15:50:33 -0800 (PST) Received: by 10.182.45.134 with HTTP; Mon, 2 Jan 2012 15:50:33 -0800 (PST) In-Reply-To: <33E4E5A5-FCA8-4918-9B74-A49F16725CD7@vpnc.org> References: <20111222221911.8008.qmail@joyce.lan> <33E4E5A5-FCA8-4918-9B74-A49F16725CD7@vpnc.org> Date: Mon, 2 Jan 2012 18:50:33 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d0446311692940a04b5943f6a Cc: John Levine , dnsext@ietf.org Subject: Re: [dnsext] SRV prefix registry 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 Jan 2012 23:50:35 -0000 --f46d0446311692940a04b5943f6a Content-Type: text/plain; charset=ISO-8859-1 Looks to me as if 6335 addresses all my concerns. The exact set of procedures really does not matter to me in the slightest, just so long as there is a defined registry the procedures will adapt as needed. On reserving other prefixes, all that matters is that the same name does not get registered for more than one purpose. That argues for a single registry of prefixes. I don't care what the rationale, anyone who tries to deploy a new protocol that is not SPF with the prefix _spf is going to end up causing unnecessary pain, misery and gnashing of teeth. Chances are that at some point in the future there will be some prefix based protocol that all 'prefixish' type schemes would want to use. So the SPF group would likely be rather upset to find that their ability to participate in some generalized prefix mechanism had been pre-empted by an unrelated protocol squatting on 'their' prefix. The assignment criteria is 'expert review'. These are precisely the type of issue that I would hope the expert would be flagging as problems. If the name is not available for registration the registry should say so, that is the purpose of the registry. I would suggest registering the Transport Protocol 'Other' to cover these cases and getting the service names reserved. This would appear to be within the scope of the 'grandfathering' process that IANA and Stuart Cheshire are already engaged in to transfer his registry over. On Thu, Dec 22, 2011 at 5:39 PM, Paul Hoffman wrote: > On Dec 22, 2011, at 2:19 PM, John Levine wrote: > > >> Would it be over and above what's in RFC 6335? > > > > It might be nice to reserve or otherwise deal with the underscore names > > used elsewhere in the DNS such as _vouch, _spf, _domainkey, and _adsp. > > > That is a topic change. Phill asked about SRV, and Craig correctly pointed > out that Phill's concern is already dealt with in RFC 6335. If it is not > fully dealt with, Phill needs to get section 5 of RFC 6335 updated. > > A registry for "underscore names that have been registered" is completely > different. RFC 6335 is "Internet Assigned Numbers Authority (IANA) > Procedures for the Management of the Service Name and Transport Protocol > Port Number Registry": note that that has nothing to do with "underscore > names". If you want a registry for those, start a new Internet Draft. > > --Paul Hoffman > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --f46d0446311692940a04b5943f6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Looks to me as if 6335 addresses all my concerns. The exact set of procedur= es really does not matter to me in the slightest, just so long as there is = a defined registry the procedures will adapt as needed.


On reserving other prefixes, all that matters is that the sa= me name does not get registered for more than one purpose. That argues for = a single registry of prefixes.

I don't care wh= at the rationale, anyone who tries to deploy a new protocol that is not SPF= with the prefix _spf is going to end up causing unnecessary pain, misery a= nd gnashing of teeth. Chances are that at some point in the future there wi= ll be some prefix based protocol that all 'prefixish' type schemes = would want to use. So the SPF group would likely be rather upset to find th= at their ability to participate in some generalized prefix mechanism had be= en pre-empted by an unrelated protocol squatting on 'their' prefix.=

The assignment criteria is 'expert review'. The= se are precisely the type of issue that I would hope the expert would be fl= agging as problems. If the name is not available for registration the regis= try should say so, that is the purpose of the registry.


I would suggest registering the Transpor= t Protocol 'Other' to cover these cases and getting the service nam= es reserved. This would appear to be within the scope of the 'grandfath= ering' process that IANA and Stuart Cheshire are already engaged in to = transfer his registry over.
=A0

On Thu, Dec 22, 2011 at 5= :39 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Dec 22, 2011, at 2:19 PM, John Levine wrote:

>> Would it be over and above what's in RFC 6335?
>
> It might be nice to reserve or otherwise deal with the underscore name= s
> used elsewhere in the DNS such as _vouch, _spf, _domainkey, and _adsp.=


That is a topic change. Phill asked about SRV, and Craig correctly po= inted out that Phill's concern is already dealt with in RFC 6335. If it= is not fully dealt with, Phill needs to get section 5 of RFC 6335 updated.=

A registry for "underscore names that have been registered" is co= mpletely different. RFC 6335 is "Internet Assigned Numbers Authority (= IANA) Procedures for the Management of the Service Name and Transport Proto= col Port Number Registry": note that that has nothing to do with "= ;underscore names". If you want a registry for those, start a new Inte= rnet Draft.

--Paul Hoffman

_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext



--
= Website: http://hallambaker.com/
--f46d0446311692940a04b5943f6a-- From hallam@gmail.com Mon Jan 2 16:02:51 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B3611E8073 for ; Mon, 2 Jan 2012 16:02:51 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqBV+hC3TPzi for ; Mon, 2 Jan 2012 16:02:50 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D506111E8083 for ; Mon, 2 Jan 2012 16:02:50 -0800 (PST) Received: by obcuz6 with SMTP id uz6so13889023obc.31 for ; Mon, 02 Jan 2012 16:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IcNZQOE4dzFxoC6E1/pwnLRz2I4QGfaqcWklQesjgHY=; b=nMkdKDvOeEcdxQP//SpTiNHFDtz/PtpIkzB/adPRHVQb5HcXmgbWuGQT20QaMShN0X dTfooBfhDvwnjcx1JDB5o43MdCd1Fm9z0epxQpSyKa/Gw9i9BD8J1QT1vKkiEht2Ho1K hPfA/YE3BrAQ0Oc5sfnlSMJNwOIYIEyGKjLYI= MIME-Version: 1.0 Received: by 10.182.13.105 with SMTP id g9mr43159726obc.63.1325548970526; Mon, 02 Jan 2012 16:02:50 -0800 (PST) Received: by 10.182.45.134 with HTTP; Mon, 2 Jan 2012 16:02:50 -0800 (PST) In-Reply-To: <8BBDD425-FA9C-4C12-95C2-487FDA2E2679@nominet.org.uk> References: <8BBDD425-FA9C-4C12-95C2-487FDA2E2679@nominet.org.uk> Date: Mon, 2 Jan 2012 19:02:50 -0500 Message-ID: From: Phillip Hallam-Baker To: Ray Bellis Content-Type: multipart/alternative; boundary=f46d044285f28548ff04b5946b03 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] SRV prefix registry 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, 03 Jan 2012 00:02:51 -0000 --f46d044285f28548ff04b5946b03 Content-Type: text/plain; charset=ISO-8859-1 Actually Dave is doing two things, one that is covered by 6335 and another which is subtly different, he is trying to ground the fact that underscore prefix DNS names are used to apply attributes to the base name. The defacto position is that underscore prefix names are attributes bound to a node rather than being distinct nodes in their own right. This is something that the application layer would like to see caching resolvers aware of at a minimum. On Fri, Dec 23, 2011 at 4:55 AM, Ray Bellis wrote: > > On 22 Dec 2011, at 13:20, Phillip Hallam-Baker wrote: > > One piece of unfinished business that really should be cleared up before > DNSEXT closes is the lack of an IANA registry for SRV prefixes. > > This is now a big problem because people have been taking maters into > their own hands. I did for SAML and XKMS. There are many thousand SRV > prefixes in use. They should be recorded 'somewhere'. > > > I can write up a short draft if there is interest. > > > Isn't this similar to what Dave Crocker already sent to DNSOP? > > > > Ray > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > -- Website: http://hallambaker.com/ --f46d044285f28548ff04b5946b03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually Dave is doing two things, one that is covered by 6335 and another = which is subtly different, he is trying to ground the fact that underscore = prefix DNS names are used to apply attributes to the base name.

The defacto position is that underscore prefix names are attribu= tes bound to a node rather than being distinct nodes in their own right. Th= is is something that the application layer would like to see caching resolv= ers aware of at a minimum.=A0




On Fr= i, Dec 23, 2011 at 4:55 AM, Ray Bellis <Ray.Bellis@nominet.org.uk> wro= te:

On 22 D= ec 2011, at 13:20, Phillip Hallam-Baker wrote:

One piece of unfinished business that really should be cleared up be= fore DNSEXT closes is the lack of an IANA registry for SRV prefixes.

This is now a big problem because people have been taking ma= ters into their own hands. I did for SAML and XKMS. There are many thousand= SRV prefixes in use. They should be recorded 'somewhere'.


I can write up a short draft if there is= interest.=A0

Isn't this similar= to what Dave Crocker already sent to DNSOP?

<<= a href=3D"http://www.ietf.org/id/draft-crocker-dns-attrleaf-06.txt" target= =3D"_blank">http://www.ietf.org/id/draft-crocker-dns-attrleaf-06.txt>= ;

Ray



_______________________________= ________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext




--
Website:= http://hallambaker.com/

--f46d044285f28548ff04b5946b03-- From Ed.Lewis@neustar.biz Mon Jan 2 16:13:39 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1B021F84A3 for ; Mon, 2 Jan 2012 16:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pTokxZxIFxc for ; Mon, 2 Jan 2012 16:13:38 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6A95B21F8450 for ; Mon, 2 Jan 2012 16:13:38 -0800 (PST) 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 q030DalT060942; Mon, 2 Jan 2012 19:13:37 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.103] by Work-Laptop-2.local (PGP Universal service); Mon, 02 Jan 2012 19:13:39 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 02 Jan 2012 19:13:39 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20120102151304.GA27585@vacation.karoshi.com.> References: <20120102104613.GB12764@miek.nl> <20120102135227.EAA9D1AC279D@drugs.dv.isc.org> <20120102140337.GJ12764@miek.nl> <20120102151304.GA27585@vacation.karoshi.com.> Date: Mon, 2 Jan 2012 19:13:34 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] SIG inception/expiration 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, 03 Jan 2012 00:13:39 -0000 At 15:13 +0000 1/2/12, wrote: >as for ordering, Ed may chime in anyday now... Since you asked...the order was set before my time. (DNSSEC was in discussion for about 2 years before I joined TIS.) I don't know the rationale behind the ordering. It does seem "odd" - but to me that's just the way it has always been. Maybe Olafur, Brian, Donald, Jim Galvin and/or others (Gilmore?) might know. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Vote for the word of the day: "Papa"razzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate "red tape" From d3e3e3@gmail.com Mon Jan 2 17:42:46 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8657121F857B for ; Mon, 2 Jan 2012 17:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.264 X-Spam-Level: X-Spam-Status: No, score=-104.264 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWubFoIutOoo for ; Mon, 2 Jan 2012 17:42:45 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA2E21F852A for ; Mon, 2 Jan 2012 17:42:45 -0800 (PST) Received: by laah2 with SMTP id h2so6644859laa.31 for ; Mon, 02 Jan 2012 17:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=BWB23WXh3boULNcQfswRYv2fFbvhU8OBQVD7wamddxo=; b=rqFCLMBql3AjiojLq01Ak4K1QPolLaakZ84Km6mCXpTY58lbIgK+3pEF6wegKayttl rbLR5bNOKIoBGbrMKfVxGrCb3+hH4hVbCeM64NHXestuPUwuCwog+kEGI02tI6Zr3Six C0vT6jYKKgMEqemxAQvym71nec2uIx/Hb8vYk= Received: by 10.152.128.196 with SMTP id nq4mr42758876lab.35.1325554964229; Mon, 02 Jan 2012 17:42:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.112.99 with HTTP; Mon, 2 Jan 2012 17:42:23 -0800 (PST) In-Reply-To: References: <20120102104613.GB12764@miek.nl> <20120102135227.EAA9D1AC279D@drugs.dv.isc.org> <20120102140337.GJ12764@miek.nl> <20120102151304.GA27585@vacation.karoshi.com.> From: Donald Eastlake Date: Mon, 2 Jan 2012 20:42:23 -0500 Message-ID: To: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] SIG inception/expiration 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, 03 Jan 2012 01:42:46 -0000 I don't remember why it changed. One tends to think of the "logical" order as being from-to. But I would note that, to put the most critical information earliest, address fields are normally to-from, that is, "destination-source". Perhaps it was changed in analogy to that. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Mon, Jan 2, 2012 at 7:13 PM, Edward Lewis wrote: > At 15:13 +0000 1/2/12, wrote: > >> as for ordering, Ed may chime in anyday now... > > > Since you asked...the order was set before my time. =A0(DNSSEC was in > discussion for about 2 years before I joined TIS.) =A0I don't know the > rationale behind the ordering. =A0It does seem "odd" - but to me that's j= ust > the way it has always been. > > Maybe Olafur, Brian, Donald, Jim Galvin and/or others (Gilmore?) might kn= ow. > -- > -=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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0You can leave a voice mess= age at +1-571-434-5468 > > Vote for the word of the day: > "Papa"razzi - father that constantly takes photos of the baby > Corpureaucracy - The institution of corporate "red tape" > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From jad@jadickinson.co.uk Tue Jan 3 07:57:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0FF21F847A for ; Tue, 3 Jan 2012 07:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RI7T-S75ts2 for ; Tue, 3 Jan 2012 07:57:24 -0800 (PST) Received: from cpanelsmarthost3.zen.co.uk (cpanelsmarthost3.zen.co.uk [82.71.204.227]) by ietfa.amsl.com (Postfix) with ESMTP id D82C521F842A for ; Tue, 3 Jan 2012 07:57:23 -0800 (PST) Received: from [88.98.24.67] (helo=shcp01.hosting.zen.net.uk) by cpanelsmarthost3.zen.co.uk with esmtp (Exim 4.72) (envelope-from ) id 1Ri6jp-0003pR-S0 for dnsext@ietf.org; Tue, 03 Jan 2012 15:57:21 +0000 Received: from [86.12.159.228] (helo=[192.168.1.21]) by shcp01.hosting.zen.net.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Ri6jm-0002eG-Gw for dnsext@ietf.org; Tue, 03 Jan 2012 15:57:18 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: John Dickinson In-Reply-To: <20120102140337.GJ12764@miek.nl> Date: Tue, 3 Jan 2012 15:57:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120102104613.GB12764@miek.nl> <20120102135227.EAA9D1AC279D@drugs.dv.isc.org> <20120102140337.GJ12764@miek.nl> To: dnsext@ietf.org X-Mailer: Apple Mail (2.1251.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jadickinson.co.uk Subject: Re: [dnsext] SIG inception/expiration 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, 03 Jan 2012 15:57:24 -0000 On 2 Jan 2012, at 14:03, Miek Gieben wrote: > [ Quoting at 00:52 on Jan 3 in "Re: [dnsext] SIG = inc..." ] >>=20 >> In message <20120102104613.GB12764@miek.nl>, Miek Gieben writes: >>> Hello list, >>>=20 >>> A recent dnssec-deployment discussion led to the question on why the >>> expiration/inception time in the RRSIG are in the "wrong" order. >>=20 >> Actually the order makes lots of sense. Expiration time is almost >> always the critical value in a signature. Inception time is almost >> always in the past. One could completely remove inception time >> and still have secure signatures. >=20 > But was this the original reason to change the order? >=20 > And someone, not trained in the Jedi ways of DNSSEC, will look at an = RRSIG and > assume the first time stamp is the inception and the second one is = expiration. That is true. I have often had to double check this order - I just = remember that there is something funny with it now and always double = check.=20 I had always thought that, as Mark said, inception makes no difference = to security, and that perhaps there is no operational reason to use any = value other than 0 for the inception. Setting it to zero would at least = stop it standing out in the RRSIG. However, a quick re-read of 4034 = 3.1.5 reminds me that=20 The Signature Expiration and Inception field values specify a date and time in the form of a 32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The longest interval that can be expressed by this format without wrapping is approximately 136 years. An RRSIG RR can have an Expiration field value that is numerically smaller than the Inception field value if the expiration field value is near the 32-bit wrap-around point or if the signature is long lived. Because of this, all comparisons involving these fields MUST use "Serial number arithmetic", as defined in [RFC1982]. As a direct consequence, the values contained in these fields cannot refer to dates more than 68 years in either the past or the future. so I guess it does need to be set to something reasonable if you use = very long validity periods or we are nearing 2106. However, it makes me = wonder if there is ever a reason to compare them, and if serial number = arithmatic is actually meaningful here?=20 John From Internet-Drafts@ietf.org Tue Jan 3 08:15:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0CC21F8471; Tue, 3 Jan 2012 08:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqPscWZnTKw8; Tue, 3 Jan 2012 08:15:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02D921F84E3; Tue, 3 Jan 2012 08:15:01 -0800 (PST) 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.64p1 Message-ID: <20120103161501.30861.31418.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 08:15:01 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D ACTION:draft-ietf-dnsext-rfc2671bis-edns0-06.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 16:15:02 -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 : Extension Mechanisms for DNS (EDNS0) Author(s) : J. Damas, et al Filename : draft-ietf-dnsext-rfc2671bis-edns0-06.txt Pages : 13 Date : 2012-01-03 The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward compatible mechanisms for allowing the protocol to grow. This document updates the EDNS0 specification [RFC2671] based on feedback from deployment experience in several implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-06.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-rfc2671bis-edns0-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-01-03080846.I-D@ietf.org> --NextPart-- From internet-drafts@ietf.org Tue Jan 3 12:22:35 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A9D11E80F5; Tue, 3 Jan 2012 12:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSUqYiSiau18; Tue, 3 Jan 2012 12:22:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A747511E80E8; Tue, 3 Jan 2012 12:22:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120103202228.15067.34860.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 12:22:28 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-03.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:22:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. Title : Signaling Cryptographic Algorithm Understanding in DNSSEC Author(s) : Steve Crocker Scott Rose Filename : draft-ietf-dnsext-dnssec-algo-signal-03.txt Pages : 8 Date : 2012-01-03 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-03= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-03.= txt From scottr.nist@gmail.com Tue Jan 3 12:35:35 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BCE11E8107 for ; Tue, 3 Jan 2012 12:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VToHO62SuvH for ; Tue, 3 Jan 2012 12:35:34 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5852011E80C7 for ; Tue, 3 Jan 2012 12:35:34 -0800 (PST) Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q03KZD3e017043 for ; Tue, 3 Jan 2012 15:35:13 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Scott Rose In-Reply-To: <20120103202228.15067.34860.idtracker@ietfa.amsl.com> Date: Tue, 3 Jan 2012 15:35:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120103202228.15067.34860.idtracker@ietfa.amsl.com> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr.nist@gmail.com Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-03.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:35:35 -0000 This is basically a keep alive version, although there is one major = change. The option for listing the DS hashes has been removed since it = doesn't add much. If people think it is necessary it can be made a = second EDNS option with a new code (both can be in the draft). Scott On Jan 3, 2012, at 3:22 PM, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the DNS Extensions Working = Group of the IETF. >=20 > Title : Signaling Cryptographic Algorithm = Understanding in DNSSEC > Author(s) : Steve Crocker > Scott Rose > Filename : draft-ietf-dnsext-dnssec-algo-signal-03.txt > Pages : 8 > Date : 2012-01-03 >=20 > The DNS Security Extensions (DNSSEC) were developed to provide = origin > authentication and integrity protection for DNS data by using = digital > signatures. These digital signatures can be generated using > different algorithms. This draft sets out to specify a way for > validating end-system resolvers to signal to a server which > cryptographic algorithms they support. >=20 >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-0= 3.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-03= .txt >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From ogud@ogud.com Tue Jan 3 13:32:23 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C65411E80B2 for ; Tue, 3 Jan 2012 13:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAPeNNxIiGVY for ; Tue, 3 Jan 2012 13:32:23 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id E75D011E80B1 for ; Tue, 3 Jan 2012 13:32:22 -0800 (PST) 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 q03LWKQn068650 for ; Tue, 3 Jan 2012 16:32:21 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F0373E5.1000207@ogud.com> Date: Tue, 03 Jan 2012 16:32:21 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120102104613.GB12764@miek.nl> In-Reply-To: <20120102104613.GB12764@miek.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] SIG inception/expiration 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, 03 Jan 2012 21:32:23 -0000 On 02/01/2012 05:46, Miek Gieben wrote: > Hello list, > > A recent dnssec-deployment discussion led to the question on why the > expiration/inception time in the RRSIG are in the "wrong" order. > > I did some digging in the archives and the closest I found was this: > > In the drafts leading up to RFC 2065, the SIG RDATA is defined: > http://tools.ietf.org/html/draft-ietf-dnssec-secext-00#section-5.1 > > In there it is: "time signed", "signature expiration" > > And then in -02 (there is no -01) > http://tools.ietf.org/html/draft-ietf-dnssec-secext-02#section-4.1 > > It is: "signature expiration", "time signed". Where is stays up to RFC 2065. > I do not remember why/if the order was changed, but seem to recall that my first DNSSEC code written in fall 1994 (signer) did not inter operate with later code (resolver spring 1995) and the reason was the order change and I always coded from current drafts. > In RFC 2535 "time signed" is renamed to "signature inception", but the > ordering isn't changed. So it's "signature expiration", "signature inception". > > Does anybody know (remember?) why the switch was made during > draft-ietf-dnssec-secext-00 and -02? > No and I can not find version 01 anywhere. Olafur From bmanning@karoshi.com Tue Jan 3 14:03:26 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09A811E80CE for ; Tue, 3 Jan 2012 14:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUrc-welMrMr for ; Tue, 3 Jan 2012 14:03:25 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id BC60F11E80CC for ; Tue, 3 Jan 2012 14:03:25 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q03M3PJL000576; Tue, 3 Jan 2012 22:03:25 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q03M3OIf000575; Tue, 3 Jan 2012 22:03:24 GMT Date: Tue, 3 Jan 2012 22:03:24 +0000 From: bmanning@vacation.karoshi.com To: Olafur Gudmundsson Message-ID: <20120103220324.GA395@vacation.karoshi.com.> References: <20120102104613.GB12764@miek.nl> <4F0373E5.1000207@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F0373E5.1000207@ogud.com> User-Agent: Mutt/1.4.1i Cc: dnsext@ietf.org Subject: Re: [dnsext] SIG inception/expiration 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, 03 Jan 2012 22:03:26 -0000 On Tue, Jan 03, 2012 at 04:32:21PM -0500, Olafur Gudmundsson wrote: > > I do not remember why/if the order was changed, but seem to recall that > my first DNSSEC code written in fall 1994 (signer) did not inter operate > with later code (resolver spring 1995) and the reason was the order > change and I always coded from current drafts. gahhh... should I pull out my code fm that era? > >In RFC 2535 "time signed" is renamed to "signature inception", but the > >ordering isn't changed. So it's "signature expiration", "signature > >inception". > > > >Does anybody know (remember?) why the switch was made during > >draft-ietf-dnssec-secext-00 and -02? > > > > No and I can not find version 01 anywhere. WDIFF sez: http://ietfreport.isoc.org/cgi-bin/htmlwdiff?f1=..%2Fall-ids%2Fdraft-ietf-dnssec-secext-02.txt&f2=..%2Fall-ids%2Fdraft-ietf-dnssec-secext-01.txt this didn't change btwn 01 and 02... WDIFF sez it didn't change btwn 00 and 01... BUT.... 00-01 has this identical text: 5.1 SIG RDATA Format The RDATA portion of a SIG RR is as shown below. The integrity of the RDATA information and that of the SIG RRs owner, type, and class are protected by the signature field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signer's name | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time signed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sig length | / +-+-+-+-+-+-+-+-+ signature -+ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 01-02 has this identical text: 4.1 SIG RDATA Format The RDATA portion of a SIG RR is as shown below. The integrity of the RDATA information and that of the SIG RRs owner, type, and class are protected by the signature field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type covered | algorithm | labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time signed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key footprint | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------------------------------------------------------------------------------- /bill > > Olafur > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From marka@isc.org Tue Jan 3 17:29:49 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80EF21F8484 for ; Tue, 3 Jan 2012 17:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4wFMXJr7bb9 for ; Tue, 3 Jan 2012 17:29:49 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5FD21F8442 for ; Tue, 3 Jan 2012 17:29:49 -0800 (PST) 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 DB5F3C9427; Wed, 4 Jan 2012 01:29:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:157:6bc5:2c94:be00]) (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 8F28A216C6A; Wed, 4 Jan 2012 01:29:25 +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 B19951AC80F2; Wed, 4 Jan 2012 12:29:22 +1100 (EST) To: John Dickinson From: Mark Andrews References: <20120102104613.GB12764@miek.nl> <20120102135227.EAA9D1AC279D@drugs.dv.isc.org> <20120102140337.GJ12764@miek.nl> In-reply-to: Your message of "Tue, 03 Jan 2012 15:57:20 -0000." Date: Wed, 04 Jan 2012 12:29:22 +1100 Message-Id: <20120104012922.B19951AC80F2@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] SIG inception/expiration 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, 04 Jan 2012 01:29:50 -0000 In message , John Dicki nson writes: > > On 2 Jan 2012, at 14:03, Miek Gieben wrote: > > > [ Quoting at 00:52 on Jan 3 in "Re: [dnsext] SIG inc..." ] > >> > >> In message <20120102104613.GB12764@miek.nl>, Miek Gieben writes: > >>> Hello list, > >>> > >>> A recent dnssec-deployment discussion led to the question on why the > >>> expiration/inception time in the RRSIG are in the "wrong" order. > >> > >> Actually the order makes lots of sense. Expiration time is almost > >> always the critical value in a signature. Inception time is almost > >> always in the past. One could completely remove inception time > >> and still have secure signatures. > > > > But was this the original reason to change the order? > > > > And someone, not trained in the Jedi ways of DNSSEC, will look at an RRSIG > and > > assume the first time stamp is the inception and the second one is expirati > on. > > That is true. I have often had to double check this order - I just remember t > hat there is something funny with it now and always double check. > > I had always thought that, as Mark said, inception makes no difference to sec > urity, and that perhaps there is no operational reason to use any value other > than 0 for the inception. Setting it to zero would at least stop it standing > out in the RRSIG. However, a quick re-read of 4034 3.1.5 reminds me that What I said is that it could be removed all together. Given that it is there it needs to be set appropriately. > The Signature Expiration and Inception field values specify a date > and time in the form of a 32-bit unsigned number of seconds elapsed > since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network > byte order. The longest interval that can be expressed by this > format without wrapping is approximately 136 years. An RRSIG RR can > have an Expiration field value that is numerically smaller than the > Inception field value if the expiration field value is near the > 32-bit wrap-around point or if the signature is long lived. Because > of this, all comparisons involving these fields MUST use "Serial > number arithmetic", as defined in [RFC1982]. As a direct > consequence, the values contained in these fields cannot refer to > dates more than 68 years in either the past or the future. > > so I guess it does need to be set to something reasonable if you use very lon > g validity periods or we are nearing 2106. However, it makes me wonder if the > re is ever a reason to compare them, and if serial number arithmatic is actua > lly meaningful here? Serial number arithmetic is important. > John > > > _______________________________________________ > 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 miekg@atoom.net Tue Jan 3 23:48:17 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F4E21F860D for ; Tue, 3 Jan 2012 23:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uj7JXkk7dlh8 for ; Tue, 3 Jan 2012 23:48:17 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id F089921F85CC for ; Tue, 3 Jan 2012 23:48:16 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id B0E353FF2F; Wed, 4 Jan 2012 08:48:08 +0100 (CET) Date: Wed, 4 Jan 2012 08:48:08 +0100 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20120104074808.GA27592@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <20120102104613.GB12764@miek.nl> <4F0373E5.1000207@ogud.com> <20120103220324.GA395@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <20120103220324.GA395@vacation.karoshi.com.> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] SIG inception/expiration 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, 04 Jan 2012 07:48:17 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting at 22:03 on Jan 3 in "Re: [dnsext] S= IG inc..." ] > > my first DNSSEC code written in fall 1994 (signer) did not inter operat= e=20 > > with later code (resolver spring 1995) and the reason was the order=20 > > change and I always coded from current drafts. >=20 > gahhh... should I pull out my code fm that era? Why not? I'm curious. Regards, Miek --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8EBDgACgkQJYuFzziA0PYSmwCgwoeUgtfx+k+O4HQn9mqtOXmy NQ0An3icSr+VnxGY88Ey3LbLHS6pfBey =BX8z -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From miekg@atoom.net Tue Jan 3 23:56:44 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895D921F864D for ; Tue, 3 Jan 2012 23:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHS9iitEk21N for ; Tue, 3 Jan 2012 23:56:44 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA2821F863C for ; Tue, 3 Jan 2012 23:56:44 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id 5D85D3FFE7; Wed, 4 Jan 2012 08:56:43 +0100 (CET) Date: Wed, 4 Jan 2012 08:56:43 +0100 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20120104075643.GB27592@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <20120103202228.15067.34860.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8P1HSweYDcXXzwPJ" Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-03.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 07:56:44 -0000 --8P1HSweYDcXXzwPJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting at 15:35 on Jan 3 in "Re: [dnsext] I-D A= ct..." ] > This is basically a keep alive version, although there is one major chang= e. > > The option for listing the DS hashes has been removed since it doesn't add > much. If people think it is necessary it can be made a second EDNS option > with a new code (both can be in the draft). I think that is OK.=20 But something else that pops up: how about signaling new hash algorithms for nsec3 records? Right now, rolling the hash algorithm in nsec3 is next to impossible (prolly the only way to do it is rolling the algorithms codes again). It that something to add to the draft? grtz, --=20 Miek --8P1HSweYDcXXzwPJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8EBjsACgkQJYuFzziA0PYv5gCglpuGSvIsP1WTStK0LGqJpc/b 0m0AoJCd0kPL59Sc3KclXz3wMlrIRtJK =VWNE -----END PGP SIGNATURE----- --8P1HSweYDcXXzwPJ-- From miekg@atoom.net Wed Jan 4 01:29:47 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED08C21F864D for ; Wed, 4 Jan 2012 01:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X49Ey9YwAn6A for ; Wed, 4 Jan 2012 01:29:47 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 69C9F21F8600 for ; Wed, 4 Jan 2012 01:29:47 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id 9060B3FFFB; Wed, 4 Jan 2012 10:29:46 +0100 (CET) Date: Wed, 4 Jan 2012 10:29:46 +0100 From: Miek Gieben To: dnsext list Message-ID: <20120104092946.GA4199@miek.nl> Mail-Followup-To: dnsext list MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: [dnsext] NSEC4 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, 04 Jan 2012 09:29:48 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear dnsext, We have written down a little experiment that we have performed, called NSEC4. The goal of the experiment was to optimize denial of existence records. It is not our intention to standardize this, as we are aware of the backwards compatibility issues this has with the current DNSSEC family RFCs, and we do not want to discomfort the ongoing DNSSEC deployment. However, we do want to document this to archive the insights we have gained by doing this experiment. Therefor, we have submitted the following draft: http://www.ietf.org/id/draft-gieben-nsec4-00.txt This experiment resolves two things: * Reduces the size of the denial of existence response; * Adds Opt-Out to un-hashed names. We would be grateful if you would like to read this. Our question is what is the best place to archive this? Re-reading RFC 2026, we are considering to put this on the experimental non-standards track. Thoughts? Best regards, Miek Gieben, Matthijs Mekking --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8EHAoACgkQJYuFzziA0PbSiACg9dV6/A7j0hg+o5UKLT1iBGLJ 06cAoI1JoZdy83RRO4SIHmbg2s1hZrmF =tKQW -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From roy@nominet.org.uk Wed Jan 4 02:24:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294F421F85D8 for ; Wed, 4 Jan 2012 02:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+A+vnWeL7eT for ; Wed, 4 Jan 2012 02:24:15 -0800 (PST) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2050E21F85D6 for ; Wed, 4 Jan 2012 02:24:13 -0800 (PST) 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=rGM+XOylMbSfVRc3MQFkz8PtABWJ/TUgtTXyiOaTJyD3xmDgix/3gR79 V91ZVd61OU1qcAEy2AJC5EM8xVQ911iA7Dl3Xs1MFU836t1oh69TiXvSs Ykh4lPHcln5e9XB; 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=1325672655; x=1357208655; 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]=20NSEC4|Date:=20Wed,=204=20Jan=202012=2010: 24:11=20+0000|Message-ID:=20<40816163-6712-4FEF-9FE3-324A 2A8BCA09@nominet.org.uk>|To:=20Miek=20Gieben=20|CC:=20dnsext=20list=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20|In-Reply-To:=20<20120104092946.GA4199@miek.nl> |References:=20<20120104092946.GA4199@miek.nl>; bh=gUPkYAjebMS2H/JFbDlp9GWYSjdU1Wm7e/FtU3VLXN4=; b=AJf/jYKdkPIWrOeWh+a+0/GglA45wW7tRhjV1bjbAiFNEKO/1kpomHZW PpeksYD2ppuoULl4lOyDZnIPmaubBy/6/Uh2AOjzgLkZ7BekmRbcyveic AI2P8vtRAzdA5+K; X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; d="scan'208";a="30443253" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 04 Jan 2012 10:24:12 +0000 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; Wed, 4 Jan 2012 10:24:12 +0000 From: Roy Arends To: Miek Gieben Thread-Topic: [dnsext] NSEC4 Thread-Index: AQHMysN0QMofPn5zwUGGws6y9tBntJX8AHiA Date: Wed, 4 Jan 2012 10:24:11 +0000 Message-ID: <40816163-6712-4FEF-9FE3-324A2A8BCA09@nominet.org.uk> References: <20120104092946.GA4199@miek.nl> In-Reply-To: <20120104092946.GA4199@miek.nl> 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 Cc: dnsext list Subject: Re: [dnsext] NSEC4 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, 04 Jan 2012 10:24:16 -0000 On Jan 4, 2012, at 9:29 AM, Miek Gieben wrote: > Dear dnsext, >=20 > We have written down a little experiment that we have performed, called N= SEC4. > The goal of the experiment was to optimize denial of existence records. > It is not our intention to standardize this, as we are aware of the backw= ards > compatibility issues this has with the current DNSSEC family RFCs, and we= do > not want to discomfort the ongoing DNSSEC deployment. >=20 > However, we do want to document this to archive the insights we have gain= ed > by doing this experiment. Therefor, we have submitted the following draft= : >=20 > http://www.ietf.org/id/draft-gieben-nsec4-00.txt >=20 > This experiment resolves two things: > * Reduces the size of the denial of existence response; > * Adds Opt-Out to un-hashed names. >=20 > We would be grateful if you would like to read this. >=20 > Our question is what is the best place to archive this? Re-reading RFC 20= 26, > we are considering to put this on the experimental non-standards track. >=20 > Thoughts? Nice! During the development of NSEC3 we (nsec3 editors) discussed both optimizat= ions (no hash, and wildcard bit). We called "no hash" an identity function = [1], and figured out we could always define it as an NSEC3 hash function la= ter. We called the wildcard bit an asterisk flag, but figured that wildcard= expansions are per record type, not per full name, and that the proof woul= d be even more different from nsec than before (and the group seemed to be = suffering from NSEC3 fatigue at the time). Again, we thought we could alway= s define an additional flag later. However, both additions would break back= wards compatibility if you want to optimize for response size. Great stuff, thanks for documenting the effort. Do you have code, and any c= omparative analysis on response size? As for a proper place, I'd suggest=20 The added functionality of NSEC4 (smaller responses, unhashed names, opt-ou= t) looks like the original opt-in specification: NSEC plus opt-in :-) [1] http://en.wikipedia.org/wiki/Identity_function Warm regards, Roy >=20 > Best regards, >=20 > Miek Gieben, > Matthijs Mekking > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From matthijs@nlnetlabs.nl Wed Jan 4 03:06:06 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE1A21F8623 for ; Wed, 4 Jan 2012 03:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxvCoUa271R1 for ; Wed, 4 Jan 2012 03:06:06 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AB621F860F for ; Wed, 4 Jan 2012 03:06:05 -0800 (PST) Received: from [192.168.178.23] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q04B62Zr051868 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 12:06:03 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4F04329A.6040507@nlnetlabs.nl> Date: Wed, 04 Jan 2012 12:06:02 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: Roy Arends References: <20120104092946.GA4199@miek.nl> <40816163-6712-4FEF-9FE3-324A2A8BCA09@nominet.org.uk> In-Reply-To: <40816163-6712-4FEF-9FE3-324A2A8BCA09@nominet.org.uk> 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.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 04 Jan 2012 12:06:04 +0100 (CET) Cc: dnsext list Subject: Re: [dnsext] NSEC4 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, 04 Jan 2012 11:06:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Roy, Thanks for your kind reaction. First of all, you mentioned that the "no hash" (or "zero hashing") was also discussed during the development of NSEC3. Unfortunately, it is hard (if not impossible) to define it as a new NSEC3 hash function: For "zero hashing" the Next (Hashed) Owner Name field cannot be base32 encoded. Therefore, with our experiment we made the field a Domain Name. Second, I cannot deny that adding unhashed named to NSEC3 looks a lot like adding Opt-In to NSEC. I also think that document writes down a very clever idea:). We have code, adaptations of ldns and NSD on the authoritative side, godns on the resolver side. An analysis on response size is difficult, because it is zone and query specific. In general, all NXDOMAIN and Wildcard NODATA responses will be reduced by one NSECx record and its corresponding signatures. Kind regards, Matthijs On 01/04/2012 11:24 AM, Roy Arends wrote: > On Jan 4, 2012, at 9:29 AM, Miek Gieben wrote: > >> Dear dnsext, >> >> We have written down a little experiment that we have performed, >> called NSEC4. The goal of the experiment was to optimize denial of >> existence records. It is not our intention to standardize this, as >> we are aware of the backwards compatibility issues this has with >> the current DNSSEC family RFCs, and we do not want to discomfort >> the ongoing DNSSEC deployment. >> >> However, we do want to document this to archive the insights we >> have gained by doing this experiment. Therefor, we have submitted >> the following draft: >> >> http://www.ietf.org/id/draft-gieben-nsec4-00.txt >> >> This experiment resolves two things: * Reduces the size of the >> denial of existence response; * Adds Opt-Out to un-hashed names. >> >> We would be grateful if you would like to read this. >> >> Our question is what is the best place to archive this? Re-reading >> RFC 2026, we are considering to put this on the experimental >> non-standards track. >> >> Thoughts? > > Nice! > > During the development of NSEC3 we (nsec3 editors) discussed both > optimizations (no hash, and wildcard bit). We called "no hash" an > identity function [1], and figured out we could always define it as > an NSEC3 hash function later. We called the wildcard bit an asterisk > flag, but figured that wildcard expansions are per record type, not > per full name, and that the proof would be even more different from > nsec than before (and the group seemed to be suffering from NSEC3 > fatigue at the time). Again, we thought we could always define an > additional flag later. However, both additions would break backwards > compatibility if you want to optimize for response size. > > Great stuff, thanks for documenting the effort. Do you have code, and > any comparative analysis on response size? As for a proper place, I'd > suggest > > The added functionality of NSEC4 (smaller responses, unhashed names, > opt-out) looks like the original opt-in specification: NSEC plus > opt-in :-) > > [1] http://en.wikipedia.org/wiki/Identity_function > > Warm regards, > > Roy > > >> >> Best regards, >> >> Miek Gieben, Matthijs Mekking >> _______________________________________________ dnsext mailing >> list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > > _______________________________________________ dnsext mailing list > dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPBDKaAAoJEA8yVCPsQCW5d9MIAKiTz274i59GuJvQDssEV7s3 D8y+iEanQp+LpAd4o7L5uWQZjeenFzKVRffCOVEmoXnq9ATazxzNcMIEcXzZQimP 3Z1YPZLNKvErc4EnypcXoh/NLyZkfX11xLhEYm+4kxe+XKjhWc4UVMxJxfzfbMp6 OU4C35+gnWquXp0PiYULWWqyRXe125IHIkeil3zmloJ7PGBU99zaMz3ADaI4bme9 XmZP3X6y2G/c9SDroLQvgWNKDaSCv15jcVgZxDvJwKpcbbxRONogad9f7BIWJRsB h11O7LNiEMTkDGhXwncRPv1Y/pJkiUaEUVq62xXu+8YBM8MdkMjTWXCUVQS3qjI= =g3JT -----END PGP SIGNATURE----- From benlaurie@gmail.com Wed Jan 4 03:26:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA4421F8685 for ; Wed, 4 Jan 2012 03:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCZNZTIFxftT for ; Wed, 4 Jan 2012 03:26:24 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EC6C721F8670 for ; Wed, 4 Jan 2012 03:26:22 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so13431204vbb.31 for ; Wed, 04 Jan 2012 03:26:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=KGXmxdp771C+JJa90+QebyyN+aNZ0FFhvSzBmq8krik=; b=LTL5sSnJRUhd0zmVPKs2KUb6fXNblPjd6d204/nulz8/w1bC4r+m3j2BFM2DGVedRK bYR2Y+pj1Ca5Qx8kYc3jGDoyXmbo3ARohq2P1MIAvnftzNPbdWHC28ocitz1ImjX+iV4 U/Mb9b/Ei9Ygdp0olRgBsEgNKoFGWLhKoPyzc= MIME-Version: 1.0 Received: by 10.52.91.109 with SMTP id cd13mr26162316vdb.92.1325676382464; Wed, 04 Jan 2012 03:26:22 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.52.28.171 with HTTP; Wed, 4 Jan 2012 03:26:22 -0800 (PST) In-Reply-To: <20120104092946.GA4199@miek.nl> References: <20120104092946.GA4199@miek.nl> Date: Wed, 4 Jan 2012 11:26:22 +0000 X-Google-Sender-Auth: vmXU_1c3Ej12cj_zzeFZMYDVCfM Message-ID: From: Ben Laurie To: dnsext list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] NSEC4 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, 04 Jan 2012 11:26:26 -0000 On Wed, Jan 4, 2012 at 9:29 AM, Miek Gieben wrote: > Dear dnsext, > > We have written down a little experiment that we have performed, called N= SEC4. > The goal of the experiment was to optimize denial of existence records. > It is not our intention to standardize this, as we are aware of the backw= ards > compatibility issues this has with the current DNSSEC family RFCs, and we= do > not want to discomfort the ongoing DNSSEC deployment. > > However, we do want to document this to archive the insights we have gain= ed > by doing this experiment. Therefor, we have submitted the following draft= : > > =A0 =A0http://www.ietf.org/id/draft-gieben-nsec4-00.txt > > This experiment resolves two things: > * Reduces the size of the denial of existence response; > * Adds Opt-Out to un-hashed names. > > We would be grateful if you would like to read this. > > Our question is what is the best place to archive this? Re-reading RFC 20= 26, > we are considering to put this on the experimental non-standards track. > > Thoughts? Cute. One minor quibble: in 3.2 you say that if the hash algorithm is 0, then Salt Length MUST be ignored. Strictly speaking, if it is ignored, then the Salt field cannot be ignored (since you don't know how long it is). :-) On that note, you could save 4 bytes by omitting those fields in this case. A more major observation: when the hash alg is 0 you specify that domain names are sorted in canonical order (6.1. step 7 and presumably elsewhere). Clearly this cannot be required to make the algorithm work, or it would fail when hashing was used. So, either this is suspicious, in that it suggests a weakness in the protocol, or you could make the protocol simpler by always sorting in byte order. Note that the canonical sort is vital to NSEC: it is what keeps the proof down to 2 records instead of 3 (hence the reason this might be suspicious). From ajs@anvilwalrusden.com Wed Jan 4 03:59:04 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C01221F8682 for ; Wed, 4 Jan 2012 03:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OziBXFH6pXS for ; Wed, 4 Jan 2012 03:59:03 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B721421F864E for ; Wed, 4 Jan 2012 03:58:55 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8604B1ECB41C for ; Wed, 4 Jan 2012 11:58:54 +0000 (UTC) Date: Wed, 4 Jan 2012 06:58:51 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120104115851.GD21112@shinkuro.com> References: <20120104092946.GA4199@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120104092946.GA4199@miek.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] NSEC4 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, 04 Jan 2012 11:59:04 -0000 On Wed, Jan 04, 2012 at 10:29:46AM +0100, Miek Gieben wrote: > Our question is what is the best place to archive this? Re-reading RFC 2026, > we are considering to put this on the experimental non-standards track. Given that it's an experiment, that seems like a reasonable thing to do, unless you think the experiment is over. In the latter case, just write an informational document and be done with it. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From matthijs@nlnetlabs.nl Wed Jan 4 04:33:26 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD45E21F8638 for ; Wed, 4 Jan 2012 04:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSoZzb7b8oZ8 for ; Wed, 4 Jan 2012 04:33:26 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC11021F862B for ; Wed, 4 Jan 2012 04:33:25 -0800 (PST) Received: from [192.168.178.23] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q04CXNCL049626 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 13:33:23 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4F044713.8060504@nlnetlabs.nl> Date: Wed, 04 Jan 2012 13:33:23 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: Ben Laurie References: <20120104092946.GA4199@miek.nl> In-Reply-To: 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.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 04 Jan 2012 13:33:23 +0100 (CET) Cc: dnsext list Subject: Re: [dnsext] NSEC4 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, 04 Jan 2012 12:33:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ben, Thanks for your response. On 01/04/2012 12:26 PM, Ben Laurie wrote: > On Wed, Jan 4, 2012 at 9:29 AM, Miek Gieben wrote: >> Dear dnsext, >> >> We have written down a little experiment that we have performed, called NSEC4. >> The goal of the experiment was to optimize denial of existence records. >> It is not our intention to standardize this, as we are aware of the backwards >> compatibility issues this has with the current DNSSEC family RFCs, and we do >> not want to discomfort the ongoing DNSSEC deployment. >> >> However, we do want to document this to archive the insights we have gained >> by doing this experiment. Therefor, we have submitted the following draft: >> >> http://www.ietf.org/id/draft-gieben-nsec4-00.txt >> >> This experiment resolves two things: >> * Reduces the size of the denial of existence response; >> * Adds Opt-Out to un-hashed names. >> >> We would be grateful if you would like to read this. >> >> Our question is what is the best place to archive this? Re-reading RFC 2026, >> we are considering to put this on the experimental non-standards track. >> >> Thoughts? > > Cute. One minor quibble: in 3.2 you say that if the hash algorithm is > 0, then Salt Length MUST be ignored. Strictly speaking, if it is > ignored, then the Salt field cannot be ignored (since you don't know > how long it is). :-) A quibble, but indeed. > On that note, you could save 4 bytes by omitting those fields in this case. > > A more major observation: when the hash alg is 0 you specify that > domain names are sorted in canonical order (6.1. step 7 and presumably > elsewhere). Clearly this cannot be required to make the algorithm > work, or it would fail when hashing was used. So, either this is > suspicious, in that it suggests a weakness in the protocol, or you > could make the protocol simpler by always sorting in byte order. My apologies, I fail to see what the problem is. If "no hash" is used, we can order the NSEC4s in canonical order, just like NSEC. If hashing is used, we order them in hash order, like NSEC3. In both cases you make a usable linked-list. I guess my confusion is about: ... when the hash alg is 0 you ... work, or it would fail when hashing was used. But when hash alg is 0, that implies that hashing cannot be used. Step 7 of the sign algorithm in Section 6.1 says: 7. Sort the set of NSEC4 RRs into hash order or canonical order, depending on the value of the hash algorithm; Maybe we have to clarify that canonical order is only for algorithm number is 0? > Note that the canonical sort is vital to NSEC: it is what keeps the > proof down to 2 records instead of 3 (hence the reason this might be > suspicious). Yes, because you can always the closest encloser from the NSEC RRs. With hashing that is not possible. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPBEcTAAoJEA8yVCPsQCW5+T4H/jRGxj456YibwPfBQL5gsr/F Ty+cP1Xsq2XhfCsshAEm3q8lB1ezSkW53/6XkuXAWXcjy6If854bCkbMx0qepNoV FYhnS8DWgkHQZH/d3SeWkg9fko9e7JLjM74Joa8is3MpJb07J8lmuMNPFzT2eFqQ um1jJIo2JJgDcBv39dS/mIlzDO6gCE0RwkhyQDOYmjL37JaNd+QH1vPBC37/UOzU MmsY2l1IWwWpsgTgxO0elRTlavvHu0xYncn5M/vvsEeC9YvD6pEhJyTZlpp2DFN/ SfITazW1ZrlqZlVozoEBJDAbgfXss6iYdzM05smgoR+KGfJndRRJAlO/toB67mU= =sxGe -----END PGP SIGNATURE----- From benlaurie@gmail.com Wed Jan 4 04:36:35 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A2121F864B for ; Wed, 4 Jan 2012 04:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4KpWD0FAQEw for ; Wed, 4 Jan 2012 04:36:34 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7359521F8638 for ; Wed, 4 Jan 2012 04:36:34 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so14583020vcb.31 for ; Wed, 04 Jan 2012 04:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FM5vx1co8ya7kHkHf8kBr/Y0O2kWAaSTUr1naU+Bx7A=; b=Zlhl1SMrccbQUYcuk4i68CGeJlhWEvRMNh6LpVPJJyOEATz4LYGSyn1D+6iue+Sre9 AJ4gzslHRDB4w6ZNsJ0yo5l3UDwJ2/uvTLuBEaFpbJnmLp0MR55du5pG5DUJ5CvdERVj qCyEoV5mSqppF5zXVYSsCsJZiHlUeAXmwe2SQ= MIME-Version: 1.0 Received: by 10.52.94.148 with SMTP id dc20mr26488083vdb.109.1325680593962; Wed, 04 Jan 2012 04:36:33 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.52.28.171 with HTTP; Wed, 4 Jan 2012 04:36:33 -0800 (PST) In-Reply-To: <4F044713.8060504@nlnetlabs.nl> References: <20120104092946.GA4199@miek.nl> <4F044713.8060504@nlnetlabs.nl> Date: Wed, 4 Jan 2012 12:36:33 +0000 X-Google-Sender-Auth: AwAfjMp9bJP9mTz0KasMsLkAHME Message-ID: From: Ben Laurie To: Matthijs Mekking Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext list Subject: Re: [dnsext] NSEC4 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, 04 Jan 2012 12:36:35 -0000 On Wed, Jan 4, 2012 at 12:33 PM, Matthijs Mekking w= rote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Ben, > > Thanks for your response. > > On 01/04/2012 12:26 PM, Ben Laurie wrote: >> On Wed, Jan 4, 2012 at 9:29 AM, Miek Gieben wrote: >>> Dear dnsext, >>> >>> We have written down a little experiment that we have performed, called= NSEC4. >>> The goal of the experiment was to optimize denial of existence records. >>> It is not our intention to standardize this, as we are aware of the bac= kwards >>> compatibility issues this has with the current DNSSEC family RFCs, and = we do >>> not want to discomfort the ongoing DNSSEC deployment. >>> >>> However, we do want to document this to archive the insights we have ga= ined >>> by doing this experiment. Therefor, we have submitted the following dra= ft: >>> >>> =A0 =A0http://www.ietf.org/id/draft-gieben-nsec4-00.txt >>> >>> This experiment resolves two things: >>> * Reduces the size of the denial of existence response; >>> * Adds Opt-Out to un-hashed names. >>> >>> We would be grateful if you would like to read this. >>> >>> Our question is what is the best place to archive this? Re-reading RFC = 2026, >>> we are considering to put this on the experimental non-standards track. >>> >>> Thoughts? >> >> Cute. One minor quibble: in 3.2 you say that if the hash algorithm is >> 0, then Salt Length MUST be ignored. Strictly speaking, if it is >> ignored, then the Salt field cannot be ignored (since you don't know >> how long it is). :-) > > A quibble, but indeed. > >> On that note, you could save 4 bytes by omitting those fields in this ca= se. >> >> A more major observation: when the hash alg is 0 you specify that >> domain names are sorted in canonical order (6.1. step 7 and presumably >> elsewhere). Clearly this cannot be required to make the algorithm >> work, or it would fail when hashing was used. So, either this is >> suspicious, in that it suggests a weakness in the protocol, or you >> could make the protocol simpler by always sorting in byte order. > > My apologies, I fail to see what the problem is. If "no hash" is used, > we can order the NSEC4s in canonical order, just like NSEC. If hashing > is used, we order them in hash order, like NSEC3. In both cases you make > a usable linked-list. I guess my confusion is about: > > =A0 =A0 ... when the hash alg is 0 you ... > =A0 =A0 work, or it would fail when hashing was used. > > But when hash alg is 0, that implies that hashing cannot be used. Sure. But my point is that the order is arbitrary, therefore you can use the same ordering regardless of whether hashing is used or not. > > Step 7 of the sign algorithm in Section 6.1 says: > > =A07. =A0 Sort the set of NSEC4 RRs into hash order or canonical order, > =A0 =A0 =A0 =A0depending on the value of the hash algorithm; > > Maybe we have to clarify that canonical order is only for algorithm > number is 0? > >> Note that the canonical sort is vital to NSEC: it is what keeps the >> proof down to 2 records instead of 3 (hence the reason this might be >> suspicious). > > Yes, because you can always the closest encloser from the NSEC RRs. With > hashing that is not possible. > > Best regards, > =A0Matthijs > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJPBEcTAAoJEA8yVCPsQCW5+T4H/jRGxj456YibwPfBQL5gsr/F > Ty+cP1Xsq2XhfCsshAEm3q8lB1ezSkW53/6XkuXAWXcjy6If854bCkbMx0qepNoV > FYhnS8DWgkHQZH/d3SeWkg9fko9e7JLjM74Joa8is3MpJb07J8lmuMNPFzT2eFqQ > um1jJIo2JJgDcBv39dS/mIlzDO6gCE0RwkhyQDOYmjL37JaNd+QH1vPBC37/UOzU > MmsY2l1IWwWpsgTgxO0elRTlavvHu0xYncn5M/vvsEeC9YvD6pEhJyTZlpp2DFN/ > SfITazW1ZrlqZlVozoEBJDAbgfXss6iYdzM05smgoR+KGfJndRRJAlO/toB67mU=3D > =3DsxGe > -----END PGP SIGNATURE----- From davidb@verisign.com Wed Jan 4 07:15:14 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA73221F874C for ; Wed, 4 Jan 2012 07:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjRffIxrflOR for ; Wed, 4 Jan 2012 07:15:13 -0800 (PST) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4C521F8746 for ; Wed, 4 Jan 2012 07:15:12 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKTwRs7h0foxf3sotGXqIdZs3bvsETpjn4@postini.com; Wed, 04 Jan 2012 07:15:13 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q04FEpEh021423; Wed, 4 Jan 2012 10:14:53 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 10:14:51 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 10:14:50 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Wed, 4 Jan 2012 10:14:50 -0500 From: "Blacka, David" To: Miek Gieben Thread-Topic: [dnsext] NSEC4 Thread-Index: AQHMysNunBTbR4TQR06J0E1fNIivH5X8pXwA Date: Wed, 4 Jan 2012 15:14:50 +0000 Message-ID: <19C1D806-207B-4096-98F1-D14ACFD45C4D@verisign.com> References: <20120104092946.GA4199@miek.nl> In-Reply-To: <20120104092946.GA4199@miek.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail-28--509461764"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jan 2012 15:14:50.0855 (UTC) FILETIME=[9AB88770:01CCCAF3] Cc: dnsext list Subject: Re: [dnsext] NSEC4 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, 04 Jan 2012 15:15:14 -0000 --Apple-Mail-28--509461764 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 4, 2012, at 4:29 AM, Miek Gieben wrote: > Dear dnsext, >=20 > We have written down a little experiment that we have performed, = called NSEC4. > The goal of the experiment was to optimize denial of existence = records. > It is not our intention to standardize this, as we are aware of the = backwards > compatibility issues this has with the current DNSSEC family RFCs, and = we do > not want to discomfort the ongoing DNSSEC deployment. >=20 > However, we do want to document this to archive the insights we have = gained > by doing this experiment. Therefor, we have submitted the following = draft: >=20 > http://www.ietf.org/id/draft-gieben-nsec4-00.txt >=20 > This experiment resolves two things: > * Reduces the size of the denial of existence response; > * Adds Opt-Out to un-hashed names. >=20 > We would be grateful if you would like to read this. >=20 > Our question is what is the best place to archive this? Re-reading RFC = 2026, > we are considering to put this on the experimental non-standards = track. >=20 > Thoughts? Interesting! As Roy points out, we did consider these ideas while = working on NSEC3, but decided that adding them would make the analysis = of NSEC3 even harder for the working group, so decided to leave them = out. I note that with zero hashing, NSEC4 doesn't look exactly like NSEC, as = you will have NSEC4 records at empty non-terminals. This is the reason = (that is, the ability to find a record for every possible closest = encloser) that the order doesn't have to be DNSSEC canonical name order, = and thus could be byte order as Ben suggests. Since this is an experiment, why not also experiment with a different = type map encoding? I've generally thought that the current encoding = isn't typically space or computationally optimal. -- David Blacka =20 Principal Engineer Verisign Infrastructure Engineering --Apple-Mail-28--509461764 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMpzCCBhow ggUCoAMCAQICEBc0Avppt6vT9KJWAKLsKTAwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDMwMzAwMDAwMFoXDTE5MDMwMjIzNTk1OVowgbAxCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBH MzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZBVVIHbQdG81jb1cp+jOE4D5vUIaST JqKfkRcKNC8Q7l/sEuBplO3NRos9MRwdagtQtfeTiZC8NwQ1IfbPIAtd3BO4u5WRzWdD2G4BRTbK C/nkXDtJYGVgFD2m+OXsS31p4ryXlZo2OhbKQvXZof0qUWI/79smv37sOG9jRsPHUPVeMVtqtuHf YoG0PBNOfyu0Qq2W4a2RzYToKLekE4cJejlMLIsq8fk5J3Vb/hicWuNA9nVS8K5OZJ7dmNVxiqA6 yvWTt5u0lDLCRjYBUWuQ95AIG3yyTnCP8A39k3jlP24fYcIe1r1By2Fk7uzH/L9sOnrSFL8Aq9WS zws+u0UCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMHAGA1Ud IARpMGcwZQYLYIZIAYb4RQEHFwIwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTA3MB0GA1UdDgQWBBTVH5Sm O27W26S0sXCieoiKViFvFTCB8AYDVR0jBIHoMIHloYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IQYXDLSYxfmEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAFTXCpaBB Rq5kc0XwUen7u5EsOzy7iiwvAHrsd7PKLCHg0NSbZKWg4Tzk/Yl5HRl59esmG7e6avTxiEaDG7OV 2+BX5sEfFvKQmtTFyiI3sozDNs+nCFQ+ksSzNVS0msKRSX22qik6AH6diXmQvcb0PIM4QuZadhb+ qwxac5AvA8IKgfPkaXdnIpcotuqtKaqHe60qUw7hnCpN9gamcUoNDVx0Gu1nObq2usSjCVvXWiYY ohDin9MHLkmJ1uYOoRzsQA4WXVAa11UpMXsnd6JotLVKLnrjgZEdK0id0RTBpVbcI9VgxP1LCEaw rYgwfjsT08wUtdampqUUPcljHG4SzDCCBoUwggVtoAMCAQICECvwr+5g4ykMmRdZyEk9APUwDQYJ KoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNz IDIgRW1wbG95ZWUgQ0EgLSBHMzAeFw0xMTA1MTEwMDAwMDBaFw0xMjA1MTAwMDAwMDBaMGsxaTAQ BgNVBAsUCVZDT1JQIFVBUzAUBgNVBAMTDUJsYWNrYSwgRGF2aWQwHQYDVQQKFBZWZXJpU2lnbiBJ bmMuIFZDT1JQVUFTMCAGCSqGSIb3DQEJARYTZGF2aWRiQHZlcmlzaWduLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOFr4D6qtYX78Fwj5I+EKxkemPlg5PON2FAMElOxon6vuLv7 yRUPr7FdNu1RDd0QYni5EMQ/2cNpjQVRSrfrCNqoWkJ9y3iUHnQH+/29uOuafcxjZ11BaUo1AwpB ifMJD4PgPv4aP3kuusxY0lI3rVXJKnezejgRRGO+6n68VYQnbunJ0P0cdJvU+ZNpOkKj9y8eTG0h ynFnBP0UAgQ2f+E0c3u67ie54rHbdDNVMGECvjXjWs5KhXMR68tGCE2K7roer2v27N8VIWq5jrIU q9PLx8zjI6FThbu9ZzQCoToc7UGmeHV/oUiWKheAavj/D4iVupdZ07SPYUEnGGd5wYsCAwEAAaOC At0wggLZMAkGA1UdEwQCMAAwSAYDVR0RBEEwP4ETZGF2aWRiQHZlcmlzaWduLmNvbaAoBgorBgEE AYI3FAIDoBoMGGRhdmlkYkB2Y29ycC5hZC52cnNuLmNvbTAmBgkrBgEEAYI3FQcEGTAXBg9ghkgB hvhFAQ0EiGeB6AUCAWQCAQMwYQYDVR0fBFowWDBWoFSgUoZQaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vY2FfMzBlMmNkOGJhMjkzMDljYTAyMDJkMTVkNGJjZGYzZjAvTGF0ZXN0Q1JMLmNy bAAwggEGBgNVHSMEgf4wgfuAFNUflKY7btbbpLSxcKJ6iIpWIW8VoYHQpIHNMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQFzQC+mm3q9P0olYAouwpMDBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgkqhkiG9w0BCQ8EbjBs MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAHBgUrDgMCGjAKBggqhkiG9w0C AjAKBggqhkiG9w0CBDAKBggqhkiG9w0CBTALBgkqhkiG9w0BAQUwCwYJKoZIhvcNAQEEMA0GCSqG SIb3DQEBBQUAA4IBAQBFpX/mFvxKbdeTruA4rSlIv9JREutn5/MiOpRqhvuuAEnei3ltZ2AdURZ/ 2dvNTfEeQphSCD/l9+rVxbZKEcaKxBYeV3sSAEsOVhsc+ruZKFLnwAzEm7u/rTfkyO+qYV2zWjqA Bq9UoIDTQ9ogjYZ7A0JWnYwj8VpTA2gqBqe6ya+k9/l/GuWyVm2PW/b8OGBzi4VsQYy2WE8KGHr1 nn5znY3KZswuyRQLnzlhSdwowUFDg/yaqolSWgP1HyJGs4Ek1ZL/9DGyH/QmfxCURP2Q7CIJSUYn yDNus5pZbifQbIOBA399fc0ASqM5lKbmIrAln3FQNIoX2P0RB+Hqg1HvMYIEAjCCA/4CAQEwgcUw gbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUg Q0EgLSBHMwIQK/Cv7mDjKQyZF1nIST0A9TAJBgUrDgMCGgUAoIICETAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAxMDQxNTE0NDlaMCMGCSqGSIb3DQEJBDEWBBTr 8NQrIeszoDP8wX8fga7bHF0R+TCB1gYJKwYBBAGCNxAEMYHIMIHFMIGwMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MSowKAYDVQQDEyFWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCECvwr+5g4ykM mRdZyEk9APUwgdgGCyqGSIb3DQEJEAILMYHIoIHFMIGwMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MSowKAYD VQQDEyFWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCECvwr+5g4ykMmRdZyEk9APUw DQYJKoZIhvcNAQEBBQAEggEAPJaGIurGWF4m7SivSgTpfq+8H9aAHg0MfqgLbDRjkT4q0FEZ9SVQ YW4aU5y7DR5+2nUybOvV4dtdmQjq5oFuX/wmCke/zRgkvULiyi2V3ioiTaGfSUwfx2c0vi3rcuoY W+VYM2nrCikpsPNyJ4hAeAo6f7ZdvxAjosfSpCg9Ukg8QYR0hNWQo0ugbJrrp4SSa8+IN0iFkIx+ l2CNHBavKwisvhgO0m9uTx5KwRQNf/7h+M0p0K5vqJlPsoiA5EN1I4E91GIBXmOKFF9JgCYGz+S5 hl/EgOc2FBH5adr6BeGYIjzNoJMV6qqAYnxqa+WEjb03ysldkZXJiK7jNd5/UgAAAAAAAA== --Apple-Mail-28--509461764-- From miekg@atoom.net Wed Jan 4 09:22:54 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3F021F87A5 for ; Wed, 4 Jan 2012 09:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k64mphE6Wtdx for ; Wed, 4 Jan 2012 09:22:53 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 762EE21F874B for ; Wed, 4 Jan 2012 09:22:53 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id CFB973FFFB; Wed, 4 Jan 2012 18:22:48 +0100 (CET) Date: Wed, 4 Jan 2012 18:22:48 +0100 From: Miek Gieben To: dnsext list Message-ID: <20120104172248.GA9711@miek.nl> Mail-Followup-To: dnsext list References: <20120104092946.GA4199@miek.nl> <19C1D806-207B-4096-98F1-D14ACFD45C4D@verisign.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <19C1D806-207B-4096-98F1-D14ACFD45C4D@verisign.com> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] NSEC4 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, 04 Jan 2012 17:22:54 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting at 15:14 on Jan 4 in "Re: [dnsext] NSEC4..= =2E" ] > > This experiment resolves two things: > > * Reduces the size of the denial of existence response; > > * Adds Opt-Out to un-hashed names. > >=20 > > We would be grateful if you would like to read this. > >=20 > > Our question is what is the best place to archive this? Re-reading RFC = 2026, > > we are considering to put this on the experimental non-standards track. > >=20 > > Thoughts? >=20 > Interesting! As Roy points out, we did consider these ideas while workin= g on > NSEC3, but decided that adding them would make the analysis of NSEC3 even > harder for the working group, so decided to leave them out. >=20 > I note that with zero hashing, NSEC4 doesn't look exactly like NSEC, as y= ou > will have NSEC4 records at empty non-terminals. This is the reason (that= is, > the ability to find a record for every possible closest encloser) that the > order doesn't have to be DNSSEC canonical name order, and thus could be b= yte > order as Ben suggests. Ah, I see. Because you eliminate empty non-terminals, the depth of the zone doesn't matter anymore. This would make the algorithm(s) even simpler as you don't have to switch between hash =3D=3D 0 and hash =3D=3D 1. > Since this is an experiment, why not also experiment with a different typ= e map > encoding? I've generally thought that the current encoding isn't typical= ly > space or computationally optimal. What are you thinking about? Other (wild) ideas: * eliminate the salt * use a fixed nr of iterations (100 for instance) Together that would remove the need for an NSEC4PARAM record. grtz, --=20 Miek --J/dobhs11T7y2rNN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8EiugACgkQJYuFzziA0PbemACeLI2HtPMl70yzJeb162h6qE7B SP0An13NGMp0FkEOkw+6+oUJ7eocBhD/ =wLHa -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From alex@alex.org.uk Wed Jan 4 11:43:45 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795B611E80A5 for ; Wed, 4 Jan 2012 11:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyngpFXAZ9Vk for ; Wed, 4 Jan 2012 11:43:45 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by ietfa.amsl.com (Postfix) with ESMTP id DC61D11E808F for ; Wed, 4 Jan 2012 11:43:44 -0800 (PST) Received: from [192.168.100.16] (lemondeh-adsl.demon.co.uk [83.105.105.209]) by mail.avalus.com (Postfix) with ESMTPSA id 3D07AC56126; Wed, 4 Jan 2012 19:43:40 +0000 (GMT) Date: Wed, 04 Jan 2012 19:43:39 +0000 From: Alex Bligh To: Matthijs Mekking , Roy Arends Message-ID: In-Reply-To: <4F04329A.6040507@nlnetlabs.nl> References: <20120104092946.GA4199@miek.nl> <40816163-6712-4FEF-9FE3-324A2A8BCA09@nominet.org.uk> <4F04329A.6040507@nlnetlabs.nl> 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 list Subject: Re: [dnsext] NSEC4 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, 04 Jan 2012 19:43:45 -0000 Matthijs, --On 4 January 2012 12:06:02 +0100 Matthijs Mekking wrote: > First of all, you mentioned that the "no hash" (or "zero hashing") was > also discussed during the development of NSEC3. Unfortunately, it is > hard (if not impossible) to define it as a new NSEC3 hash function: Uggghh. If true, that is a shame. > For > "zero hashing" the Next (Hashed) Owner Name field cannot be base32 > encoded. Therefore, with our experiment we made the field a Domain Name. I /think/ your explanation could be clarified a little. If I understand things correctly, the issue is not that the Next (Hashed) Owner Name cannot be base32 encoded (it isn't - it's in binary - see 3.1.6, 3.1.7 and the last para of 3.2 of the RFC), but that the owner name of the NSEC3 RR needs to be equal to the base32 encoded value of the previous Next (Hashed) Owner Name, and as such cannot be guaranteed to fit in the Owner Name. What we should have done is defined that mapping (base32 encoding here) as part of the hash algorithm. What we also should have done is specified the identity mapping as part of the standard. NSEC3 fatigue as someone said. Unless I'm missing something, the Next (Hashed) Owner Name it seems to me could be base32 encoded, provided that the encoded value does not exceed 255 bytes. I think that allows representation of up to 159 characters, which might be useful to someone. But I seem to remember that hash algorithm support signaling is a minefield anyway. -- Alex Bligh From bert.hubert@netherlabs.nl Wed Jan 4 12:27:10 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4364321F85CD for ; Wed, 4 Jan 2012 12:27:10 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam_report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hd2HA7pZ4A8X for ; Wed, 4 Jan 2012 12:27:09 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id BC35121F85CC for ; Wed, 4 Jan 2012 12:27:09 -0800 (PST) Received: from mail-ee0-f44.google.com ([74.125.83.44]) by xs.powerdns.com with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1RiXQP-0003gw-KH for dnsext@ietf.org; Wed, 04 Jan 2012 21:27:07 +0100 Received: by eekc14 with SMTP id c14so15848573eek.31 for ; Wed, 04 Jan 2012 12:27:05 -0800 (PST) Received: by 10.14.3.200 with SMTP id 48mr22839382eeh.94.1325708825169; Wed, 04 Jan 2012 12:27:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.7.6 with HTTP; Wed, 4 Jan 2012 12:26:44 -0800 (PST) From: bert hubert Date: Wed, 4 Jan 2012 21:26:44 +0100 Message-ID: To: "dnsext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam_report: Spam detection software, running on the system "xs.powerdns.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi everybody, As part of a recent very big PowerDNS deployment as a DNSSEC signer, we've encountered an interesting issue. I'm sharing this here in hopes of hearing your wisdom, plus possibly to warn you about this happening in your code or deployments too. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Subject: [dnsext] duplicate RRs and resulting RRSIG 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, 04 Jan 2012 20:27:10 -0000 Hi everybody, As part of a recent very big PowerDNS deployment as a DNSSEC signer, we've encountered an interesting issue. I'm sharing this here in hopes of hearing your wisdom, plus possibly to warn you about this happening in your code or deployments too. In a zone there are three MX RRs for a name, of which 2 are identical. PowerDNS signs all three records in canonical order when the zone is transferred to BIND (at least I think it is BIND). That server subsequently drops one of the two identical records, and serves only two MX RRs to the world, BUT with the RRSIG that was calculated from all three records. Bad data ensues, and bounced emails, since this is in the country that actually validates. Now, there are at least 3 places where we might call 'bug': 1) the process that put duplicate RRs in the database 2) PowerDNS for signing the 3 RRs or 3) the 'outer' server for silently dropping one of the RRs, in the assumption that the RRSIG will survice this process. RFC 2181, section 5, says that servers should (lower case) 'suppress' duplicate RRSIGs, which would argue that at least PowerDNS is partially to blame, and should've dropped the duplicate record. However, the outer server I think should also not feel free to drop records on an DNSSEC signed zone. What do you think? Bert From suruti94@gmail.com Wed Jan 4 12:39:07 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E04A11E809F for ; Wed, 4 Jan 2012 12:39:07 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNrTybLJ73Uu for ; Wed, 4 Jan 2012 12:39:06 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB70C11E80A6 for ; Wed, 4 Jan 2012 12:39:06 -0800 (PST) Received: by qadb15 with SMTP id b15so10466199qad.10 for ; Wed, 04 Jan 2012 12:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WXvQ1GKixOyNjPpkWr8SQk2sOeMFBtP3OdlU13DaU84=; b=SFMiJmmqMtBPUb9ziWf0HGTuYu6hXIcXdPAVC8+WjVDuWvI01RoQ1SjnAvnFhwiG+0 TKtvQigx6qkJFCeA6SJEker2y/ZDegoDM4XecwfxZTIc4qQrtamCpgF5pqWVyCvFd6MD 9CRWyZnsA+RCL/Q2L3a7EnFt8ttr1egvcwHJA= MIME-Version: 1.0 Received: by 10.224.202.130 with SMTP id fe2mr14143052qab.16.1325709544924; Wed, 04 Jan 2012 12:39:04 -0800 (PST) Received: by 10.229.212.4 with HTTP; Wed, 4 Jan 2012 12:39:04 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Jan 2012 12:39:04 -0800 Message-ID: From: Mohan Parthasarathy To: bert hubert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dnsext@ietf.org" Subject: Re: [dnsext] duplicate RRs and resulting RRSIG 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, 04 Jan 2012 20:39:07 -0000 On Wed, Jan 4, 2012 at 12:26 PM, bert hubert wr= ote: > Hi everybody, > > As part of a recent very big PowerDNS deployment as a DNSSEC signer, > we've encountered an interesting issue. I'm sharing this here in hopes > of hearing your wisdom, plus possibly to warn you about this happening > in your code or deployments too. > > In a zone there are three MX RRs for a name, of which 2 are identical. > PowerDNS signs all three records in canonical order when the zone is > transferred to BIND (at least I think it is BIND). > > That server subsequently drops one of the two identical records, and > serves only two MX RRs to the world, BUT with the RRSIG that was > calculated from all three records. Bad data ensues, and bounced > emails, since this is in the country that actually validates. > > Now, there are at least 3 places where we might call 'bug': 1) the > process that put duplicate RRs in the database 2) PowerDNS for signing > the 3 RRs or 3) the 'outer' server for silently dropping one of the > RRs, in the assumption that the RRSIG will survice this process. > > RFC 2181, section 5, says that servers should (lower case) 'suppress' > duplicate RRSIGs, which would argue that at least PowerDNS is > partially to blame, and should've dropped the duplicate record. > However, the outer server I think should also not feel free to drop > records on an DNSSEC signed zone. > Section 6.3 of RFC 4034 states: 6.3. Canonical RR Ordering within an RRset For the purposes of DNS security, RRs with the same owner name, class, and type are sorted by treating the RDATA portion of the canonical form of each RR as a left-justified unsigned octet sequence in which the absence of an octet sorts before a zero octet. [RFC2181] specifies that an RRset is not allowed to contain duplicate records (multiple RRs with the same owner name, class, type, and RDATA). Therefore, if an implementation detects duplicate RRs when putting the RRset in canonical form, it MUST treat this as a protocol error. If the implementation chooses to handle this protocol error in the spirit of the robustness principle (being liberal in what it accepts), it MUST remove all but one of the duplicate RR(s) for the purposes of calculating the canonical form of the RRset. Going by this, PowerDNS should have removed the duplicate RRs before signi= ng. -mohan > > What do you think? > > =A0 =A0Bert > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From bmanning@karoshi.com Wed Jan 4 12:54:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF94021F8626 for ; Wed, 4 Jan 2012 12:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiNp0nLV0R05 for ; Wed, 4 Jan 2012 12:54:15 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 728CF21F8624 for ; Wed, 4 Jan 2012 12:54:15 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q04KsEJL004039; Wed, 4 Jan 2012 20:54:15 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q04KsEKw004038; Wed, 4 Jan 2012 20:54:14 GMT Date: Wed, 4 Jan 2012 20:54:14 +0000 From: bmanning@vacation.karoshi.com To: bert hubert Message-ID: <20120104205414.GB3917@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "dnsext@ietf.org" Subject: Re: [dnsext] duplicate RRs and resulting RRSIG 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, 04 Jan 2012 20:54:17 -0000 On Wed, Jan 04, 2012 at 09:26:44PM +0100, bert hubert wrote: > Hi everybody, > > As part of a recent very big PowerDNS deployment as a DNSSEC signer, > we've encountered an interesting issue. I'm sharing this here in hopes > of hearing your wisdom, plus possibly to warn you about this happening > in your code or deployments too. > > In a zone there are three MX RRs for a name, of which 2 are identical. > PowerDNS signs all three records in canonical order when the zone is > transferred to BIND (at least I think it is BIND). > > That server subsequently drops one of the two identical records, and > serves only two MX RRs to the world, BUT with the RRSIG that was > calculated from all three records. Bad data ensues, and bounced > emails, since this is in the country that actually validates. > > Now, there are at least 3 places where we might call 'bug': 1) the > process that put duplicate RRs in the database 2) PowerDNS for signing > the 3 RRs or 3) the 'outer' server for silently dropping one of the > RRs, in the assumption that the RRSIG will survice this process. > > RFC 2181, section 5, says that servers should (lower case) 'suppress' > duplicate RRSIGs, which would argue that at least PowerDNS is > partially to blame, and should've dropped the duplicate record. > However, the outer server I think should also not feel free to drop > records on an DNSSEC signed zone. > > What do you think? > > Bert > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext RFC 2181 is DNSSEC oblivious. What you are asserting is that prior to signing, you have two -identical- RRs... which accordingto RFC 2181, would be two identical RRsets (of a single RR each). Once signed however, the RRsets are no longer identical, the NSEC RRs don't match, so you have three unique RRsets. (this may require a more careful reading of the definition of an RRset....) So the bug might be in PowerDNS allowing for identical RRsets when one should be suppressed. Once signed however, the RRsets are different and the external DNS server is ignoring the RRset and extracting just some of the RRs and doing the evaluation... /bill From ahu@xs.powerdns.com Wed Jan 4 12:55:22 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AB521F8643 for ; Wed, 4 Jan 2012 12:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WoZrh-OQTTq for ; Wed, 4 Jan 2012 12:55:21 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id BDFD921F863F for ; Wed, 4 Jan 2012 12:55:21 -0800 (PST) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1RiXrk-0004bX-OD; Wed, 04 Jan 2012 21:55:20 +0100 Date: Wed, 4 Jan 2012 21:55:20 +0100 From: bert hubert To: Mohan Parthasarathy Message-ID: <20120104205520.GA17188@xs.powerdns.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] duplicate RRs and resulting RRSIG 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, 04 Jan 2012 20:55:22 -0000 On Wed, Jan 04, 2012 at 12:39:04PM -0800, Mohan Parthasarathy wrote: > Section 6.3 of RFC 4034 states: Hi Mohan, Thank you very much - and apologies for not searching through the relevant RFCs! Some notes: > 6.3. Canonical RR Ordering within an RRset > [RFC2181] specifies that an RRset is not allowed to contain duplicate > records (multiple RRs with the same owner name, class, type, and > RDATA). Therefore, if an implementation detects duplicate RRs when Well, it sorta says that. > putting the RRset in canonical form, it MUST treat this as a protocol > error. If the implementation chooses to handle this protocol error > in the spirit of the robustness principle (being liberal in what it > accepts), it MUST remove all but one of the duplicate RR(s) for the > purposes of calculating the canonical form of the RRset. This is exciting language - you MUST do A, but if you don't THEN you MUST do B ;-) We'll go for B. > Going by this, PowerDNS should have removed the duplicate RRs before signing. Very clear & will do! Bert From dougb@dougbarton.us Wed Jan 4 13:48:14 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB14211E80BF for ; Wed, 4 Jan 2012 13:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtZluGLDY9L2 for ; Wed, 4 Jan 2012 13:48:14 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 21EB311E80A6 for ; Wed, 4 Jan 2012 13:48:13 -0800 (PST) Received: (qmail 23112 invoked by uid 399); 4 Jan 2012 21:48:12 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 4 Jan 2012 21:48:12 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F04C91A.3040408@dougbarton.us> Date: Wed, 04 Jan 2012 13:48:10 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: bert hubert References: <20120104205520.GA17188@xs.powerdns.com> In-Reply-To: <20120104205520.GA17188@xs.powerdns.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dnsext@ietf.org" Subject: Re: [dnsext] duplicate RRs and resulting RRSIG 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, 04 Jan 2012 21:48:15 -0000 On 01/04/2012 12:55, bert hubert wrote: >> putting the RRset in canonical form, it MUST treat this as a protocol >> > error. If the implementation chooses to handle this protocol error >> > in the spirit of the robustness principle (being liberal in what it >> > accepts), it MUST remove all but one of the duplicate RR(s) for the >> > purposes of calculating the canonical form of the RRset. > > This is exciting language - you MUST do A, but if you don't THEN you MUST do > B ;-) We'll go for B. It's not either/or. You MUST treat this as a protocol error (i.e., you cannot let the data proceed in its current condition). The option is in how you HANDLE the protocol error. You can either kick it back to the user in terms of failing to load the zone, or you can fix it up internally and proceed. Personally, I think it's better to kick it back to the user. Otherwise, how will they learn? Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From sm@resistor.net Wed Jan 4 14:33:51 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3578C21F86F9 for ; Wed, 4 Jan 2012 14:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6ltYznyXFEl for ; Wed, 4 Jan 2012 14:33:49 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D7B21F86E7 for ; Wed, 4 Jan 2012 14:33:49 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q04MXe3j002348; Wed, 4 Jan 2012 14:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1325716425; i=@resistor.net; bh=OwQIXG5TiUKEXXu5pYvCmUeurCQxsL10pDwmcqrIDfs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=P9LNLx7r9mwdp1cZozQfnrEM4ZLv8bLGRhGnooi9VGEtxxSiTaYHNcb5dR8g9SU1j vbzZkTumNHTH6+JJ8lymtlwq2ES0nXcVEnyOsAjB+QKLT2aFQTj6nLdGeKzUI/NnQV jv+J4JO/gfsRUSwStdysaaHkC/f558j+H8scDHqk= Message-Id: <6.2.5.6.2.20120104142203.0a6f6658@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 04 Jan 2012 14:24:42 -0800 To: Doug Barton From: SM In-Reply-To: <4F04C91A.3040408@dougbarton.us> References: <20120104205520.GA17188@xs.powerdns.com> <4F04C91A.3040408@dougbarton.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] duplicate RRs and resulting RRSIG 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, 04 Jan 2012 22:33:51 -0000 Hi Doug, At 13:48 04-01-2012, Doug Barton wrote: >Personally, I think it's better to kick it back to the user. Otherwise, >how will they learn? Other protocols handle such cases more gracefully ( http://www.imc.org/ietf-smtp/mail-archive/msg06633.html ). :-) Regards, -sm From ajs@anvilwalrusden.com Wed Jan 4 14:39:23 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0897111E8089 for ; Wed, 4 Jan 2012 14:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xqVmF6esItE for ; Wed, 4 Jan 2012 14:39:22 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA7111E80B6 for ; Wed, 4 Jan 2012 14:39:22 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 099221ECB41C for ; Wed, 4 Jan 2012 22:39:20 +0000 (UTC) Date: Wed, 4 Jan 2012 17:39:19 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120104223919.GB33087@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] ICANN variant project 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: Wed, 04 Jan 2012 22:39:23 -0000 Dear colleagues, Apologies in advance for duplicate postings. I didn't cross-post because of the difficulty that sometimes causes if people follow up on list to discuss issues. Many of you will be aware that ICANN undertook the IDN Variant Issues Project last year. (Full disclosure: I was involved in the project.) On 23 December 2011 the report was posted for public comment, and I realise that I have been remiss in drawing people's attention to it. This message is to fix that. You can see the public announcement at http://www.icann.org/en/announcements/announcement-2-23dec11-en.htm. That's also a good place to start in order to submit comments if you have them. The pubic comment period closes at the end of January 2012. ICANN is eagerly soliciting comments, and I hope that those of you interested in this topic will take the time to read the report and send your observations. Having been a participant in this particular sausage-making exercise, I will say that I am sure there are things that need improvement, expansion, or more careful statement. I'm aware that the report as it stands is rather long, and I appreciate the difficulty in finding the time to read, digest, and comment on all of it. Given the importance of the topic, however, I think it's worth it. It might be tempting to discuss the document on this list, but I think it would be better to take such discussion either to the project list (which is still, as far as I know, open -- vip@icann.org, list info at https://mm.icann.org/mailman/listinfo/vip) or to use the public-comment links in the announcement to send such comments. That way, ICANN staff are sure to see the comments. Thanks and best regards, Andrew -- Andrew Sullivan From Marco.Davids@sidn.nl Fri Jan 6 00:05:08 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD5721F869E for ; Fri, 6 Jan 2012 00:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnjdMn6lEbdG for ; Fri, 6 Jan 2012 00:05:07 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 346C721F8684 for ; Fri, 6 Jan 2012 00:05:03 -0800 (PST) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id q06851HH028481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Fri, 6 Jan 2012 09:05:01 +0100 Received: from [192.168.129.3] (192.168.129.3) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server id 14.1.323.3; Fri, 6 Jan 2012 09:04:52 +0100 Message-ID: <4F06AB2C.9040408@sidn.nl> Date: Fri, 6 Jan 2012 09:05:00 +0100 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=A99B8609 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.129.3] Subject: Re: [dnsext] duplicate RRs and resulting RRSIG 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 Jan 2012 08:05:08 -0000 Hi Bert, On 01/04/12 21:26, bert hubert wrote: > RFC 2181, section 5, says that servers should (lower case) 'suppress' > duplicate RRSIGs, which would argue that at least PowerDNS is > partially to blame, and should've dropped the duplicate record. > However, the outer server I think should also not feel free to drop > records on an DNSSEC signed zone. What about RFC4034, section 6.3: "if an implementation detects duplicate RRs when putting the RRset in canonical form, it MUST treat this as a protocol error. If the implementation chooses to handle this protocol error in the spirit of the robustness principle (being liberal in what it accepts), it MUST remove all but one of the duplicate RR(s) for the purposes of calculating the canonical form of the RRset." -- Marco From miekg@atoom.net Fri Jan 6 04:52:01 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BE521F8908 for ; Fri, 6 Jan 2012 04:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYPAfwr9ZY3m for ; Fri, 6 Jan 2012 04:52:00 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id BE22E21F8906 for ; Fri, 6 Jan 2012 04:52:00 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id E3EBA4005C; Fri, 6 Jan 2012 13:51:58 +0100 (CET) Date: Fri, 6 Jan 2012 13:51:58 +0100 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20120106125158.GE26463@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <20120104092946.GA4199@miek.nl> <40816163-6712-4FEF-9FE3-324A2A8BCA09@nominet.org.uk> <4F04329A.6040507@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="65ImJOski3p8EhYV" Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] NSEC4 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 Jan 2012 12:52:01 -0000 --65ImJOski3p8EhYV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting at 19:43 on Jan 4 in "Re: [dnsext] NSEC4..." ] > What we should have done is defined that mapping (base32 encoding here) as > part of the hash algorithm. What we also should have done is specified the > identity mapping as part of the standard. NSEC3 fatigue as someone said. Yes and yes. Wrt hash algorithm rollovers in the nsec3 record, we *might* make a rule that if the algorithm of the DNSKEYs supports the hashing algorithm you can also use that in the nsec3 record. But of course there are some issues... grtz, --=20 Miek --65ImJOski3p8EhYV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8G7m4ACgkQJYuFzziA0PabnQCbBkFc5kYiA1DMDrVdqijf9uo9 4x0An1DZL5gVcE3PxXwVdzdGR4UtZKcs =Yzr8 -----END PGP SIGNATURE----- --65ImJOski3p8EhYV-- From fanf2@hermes.cam.ac.uk Fri Jan 6 10:25:57 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FEC21F8841 for ; Fri, 6 Jan 2012 10:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEctQZ+xlp5D for ; Fri, 6 Jan 2012 10:25:56 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4589021F85BD for ; Fri, 6 Jan 2012 10:25:56 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:43339) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1RjEUD-0006q2-Yf (Exim 4.72) (return-path ); Fri, 06 Jan 2012 18:25:53 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RjEUD-0007o1-L9 (Exim 4.67) (return-path ); Fri, 06 Jan 2012 18:25:53 +0000 Date: Fri, 6 Jan 2012 18:25:53 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: bert hubert In-Reply-To: Message-ID: References: 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] duplicate RRs and resulting RRSIG 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 Jan 2012 18:25:57 -0000 bert hubert wrote: > > RFC 2181, section 5, says that servers should (lower case) 'suppress' > duplicate RRSIGs Note that RFC 2181 predates widespread use of MUSTard. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: Southwesterly veering westerly 5 to 7, occasionally gale 8 later. Moderate rough, becoming rough or very rough, occasionally high in north Forties later. Rain then squally showers. Moderate or good. From fanf2@hermes.cam.ac.uk Fri Jan 6 10:29:50 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E692C21F885F for ; Fri, 6 Jan 2012 10:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6aqJwRmfgIH for ; Fri, 6 Jan 2012 10:29:50 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3C06C21F885C for ; Fri, 6 Jan 2012 10:29:50 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35175) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1RjEXz-00005g-Rt (Exim 4.72) (return-path ); Fri, 06 Jan 2012 18:29:47 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RjEXz-0008K5-IF (Exim 4.67) (return-path ); Fri, 06 Jan 2012 18:29:47 +0000 Date: Fri, 6 Jan 2012 18:29:47 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: bmanning@vacation.karoshi.com In-Reply-To: <20120104205414.GB3917@vacation.karoshi.com.> Message-ID: References: <20120104205414.GB3917@vacation.karoshi.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] duplicate RRs and resulting RRSIG 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 Jan 2012 18:29:51 -0000 bmanning@vacation.karoshi.com wrote: > > What you are asserting is that prior to signing, you have two -identical- RRs... > which accordingto RFC 2181, would be two identical RRsets (of a single RR each). You have misunderstood RFC 2181's definition of RRset. Identical RRs have the same owner, type, and class, so are part of the same RRset. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: Southwesterly veering westerly 5 to 7, occasionally gale 8 later. Moderate rough, becoming rough or very rough, occasionally high in north Forties later. Rain then squally showers. Moderate or good. From ajs@anvilwalrusden.com Mon Jan 9 14:29:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B01C11E80B1 for ; Mon, 9 Jan 2012 14:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrNihtvVqeKa for ; Mon, 9 Jan 2012 14:29:11 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6F41011E8075 for ; Mon, 9 Jan 2012 14:29:09 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5CAAB1ECB41D for ; Mon, 9 Jan 2012 22:29:08 +0000 (UTC) Date: Mon, 9 Jan 2012 17:29:06 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120109222905.GW1820@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] Follow up on draft-ietf-dnsext-dnssec-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: Mon, 09 Jan 2012 22:29:11 -0000 Dear colleagues, Some time ago, we sent draft-ietf-dnsext-dnssec-registry-fixes-08 to the IESG. The consensus on that draft was pretty rough anyway, but when it got to the IESG there was some very strong opposition. You may recall that the point of the draft was twofold: to update the current regstry, and to find one place in which to indicate what algorithms need to be implemented to maximise interoperability. (This was all due to advice we got at one of the IETF meetings some time ago.) Objections centred on using a registry to reflect the latter sort of data, because one cannot conform to a registry but only an RFC. While the registry did not actually specify conformance data, readers pointed out that merely including such in the registry seemed to head down that road. The solution to this has been to break the document in two and treat the two problems separately. To that end, Scott Rose (whose patience with this I must commend) has produced draft-srose-dnssec-registry-update-00 and draft-srose-dnssec-algo-imp-status-00. I would like to ask the WG to review those documents. I would especially like to ask those who objected to draft-ietf-dnsext-dnssec-registry-fixes-08 to review those documents. If we receive adequate review and, in particular, if we receive reviews from those previous objectors saying that these new documents meet their previous objections, then we'll send these along to the IESG in fulfullment of the charter item, "DNSKEY Registry fixes and allocation procedure advanced to IESG" (which is marked as done but which was undone by the rejection of the document). Thanks, and many happy returns for 2012. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Jan 10 06:56:47 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D255521F8737 for ; Tue, 10 Jan 2012 06:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WcGibMKDpLK for ; Tue, 10 Jan 2012 06:56:42 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 061FC21F85C2 for ; Tue, 10 Jan 2012 06:56:42 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 13C541ECB41D for ; Tue, 10 Jan 2012 14:56:41 +0000 (UTC) Date: Tue, 10 Jan 2012 09:56:41 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120110145640.GC6201@crankycanuck.ca> References: <4ED94590.3090902@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] disposition of draft-eastlake-dnsext-xnamercode-05 (was: DNSEXT closing down soon) 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 Jan 2012 14:56:47 -0000 Dear colleagues, On Sun, Dec 04, 2011 at 11:08:54PM -0500, Donald Eastlake wrote: > If I recall correctly, there was significant support for > draft-eastlake-dnsext-xnamercode > In fact, looking back, there was a WG Last Call issued on this draft > on April 13th of this year with favorable responses. > > Can this be advanced? I was remiss in not following up after that WGLC, and I apologise. I am unhappy to say that the WGLC did not achieve the required 5 reviews. I find only four reviews (all of them positive) during the period. Moreover, I do not find other reviews, outside the period of the WGLC, that supported the draft either. Therefore, the draft will not advance as a product of the working group. Speaking only personally, I will state that I think this is a shame: I believe the draft is useful, I believe what it says ought to be uncontroversial, and I believe it ought to be published as an RFC. But with a chair hat on, I cannot in good conscience report to the IESG that we have WG consensus when we can't even get five people to read nine pages of text, four of which are boilerplate, and say that they support it. I thank Donald for producing the draft, and those who contributed their reviews. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From ogud@ogud.com Tue Jan 10 14:08:18 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE1A21F8616 for ; Tue, 10 Jan 2012 14:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zFBQJqyrwaw for ; Tue, 10 Jan 2012 14:08:17 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0AE21F85F8 for ; Tue, 10 Jan 2012 14:08:15 -0800 (PST) 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 q0AM8CJd028740 for ; Tue, 10 Jan 2012 17:08:13 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F0CB6CC.8030106@ogud.com> Date: Tue, 10 Jan 2012 17:08:12 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120103161501.30861.31418.idtracker@ietfa.amsl.com> In-Reply-To: <20120103161501.30861.31418.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] I-D ACTION:draft-ietf-dnsext-rfc2671bis-edns0-06.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 22:08:18 -0000 As far as editors and chair can assert this version addresses all issues raised in the WGLC. I plan to advance this document to the IESG on Tuesday Jan 17'th unless someone speaks up. Olafur On 03/01/2012 11:15, Internet-Drafts@ietf.org 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 : Extension Mechanisms for DNS (EDNS0) > Author(s) : J. Damas, et al > Filename : draft-ietf-dnsext-rfc2671bis-edns0-06.txt > Pages : 13 > Date : 2012-01-03 > > The Domain Name System's wire protocol includes a number of fixed > fields whose range has been or soon will be exhausted and does not > allow requestors to advertise their capabilities to responders. This > document describes backward compatible mechanisms for allowing the > protocol to grow. > > This document updates the EDNS0 specification [RFC2671] based on > feedback from deployment experience in several implementations. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-06.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. > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From ajs@anvilwalrusden.com Wed Jan 11 08:21:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786FD21F87EF for ; Wed, 11 Jan 2012 08:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn-vgFYrWzYD for ; Wed, 11 Jan 2012 08:21:20 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7AC21F8734 for ; Wed, 11 Jan 2012 08:21:15 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3B6CA1ECB41D for ; Wed, 11 Jan 2012 16:21:14 +0000 (UTC) Date: Wed, 11 Jan 2012 11:21:12 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120111162112.GD1334@mail.yitter.info> References: <4ED94590.3090902@ogud.com> <20120110145640.GC6201@crankycanuck.ca> <6BC842FB-FC81-4B1A-8EFF-735314D77141@hopcount.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6BC842FB-FC81-4B1A-8EFF-735314D77141@hopcount.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] disposition of draft-eastlake-dnsext-xnamercode-05 (was: DNSEXT closing down soon) 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 Jan 2012 16:21:24 -0000 On Tue, Jan 10, 2012 at 10:01:19PM -0800, Joe Abley wrote: > > I have just reviewed this document, and I support it advancing for publication as-is. > > Does that help? I see no reason to be bureaucratic and hide-bound: sure it helps. I'll start on the write up. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Wed Jan 11 12:14:06 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E884F21F85E4 for ; Wed, 11 Jan 2012 12:14:06 -0800 (PST) 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.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6RJA+u+3GcB for ; Wed, 11 Jan 2012 12:14:06 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2D921F84AA for ; Wed, 11 Jan 2012 12:14:06 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 11 Jan 2012 12:13:58 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 11 Jan 2012 12:14:05 -0800 From: "Murray S. Kucherawy" To: "dnsext@ietf.org" Date: Wed, 11 Jan 2012 12:14:04 -0800 Thread-Topic: [dnsext] disposition of draft-eastlake-dnsext-xnamercode-05 (was: DNSEXT closing down soon) Thread-Index: AczQfRPZICPsOCveSwef9uMrKqNMfAAIBHdQ Message-ID: References: <4ED94590.3090902@ogud.com> <20120110145640.GC6201@crankycanuck.ca> <6BC842FB-FC81-4B1A-8EFF-735314D77141@hopcount.ca> <20120111162112.GD1334@mail.yitter.info> In-Reply-To: <20120111162112.GD1334@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SM Subject: Re: [dnsext] disposition of draft-eastlake-dnsext-xnamercode-05 (was: DNSEXT closing down soon) 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 Jan 2012 20:14:07 -0000 > -----Original Message----- > From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Wednesday, January 11, 2012 8:21 AM > To: dnsext@ietf.org > Subject: Re: [dnsext] disposition of draft-eastlake-dnsext-xnamercode-05 = (was: DNSEXT closing down soon) >=20 > On Tue, Jan 10, 2012 at 10:01:19PM -0800, Joe Abley wrote: > > I have just reviewed this document, and I support it advancing for > > publication as-is. > > > > Does that help? >=20 > I see no reason to be bureaucratic and hide-bound: sure it helps. > I'll start on the write up. I've read it and I support its publication as well. I have some edits to p= ropose, which I can contribute as part of a formal AppsDir review if you li= ke since they are not major. Are you planning to make this a WG document or send it through under its cu= rrent name? -MSK From ajs@anvilwalrusden.com Wed Jan 11 12:34:38 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C1E1F0C4B for ; Wed, 11 Jan 2012 12:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7o0j-gwIZF89 for ; Wed, 11 Jan 2012 12:34:37 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 834651F0C46 for ; Wed, 11 Jan 2012 12:34:37 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9D8D71ECB41D for ; Wed, 11 Jan 2012 20:34:36 +0000 (UTC) Date: Wed, 11 Jan 2012 15:34:34 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120111203434.GH2024@mail.yitter.info> References: <4ED94590.3090902@ogud.com> <20120110145640.GC6201@crankycanuck.ca> <6BC842FB-FC81-4B1A-8EFF-735314D77141@hopcount.ca> <20120111162112.GD1334@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] disposition of draft-eastlake-dnsext-xnamercode-05 (was: DNSEXT closing down soon) 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 Jan 2012 20:34:38 -0000 On Wed, Jan 11, 2012 at 12:14:04PM -0800, Murray S. Kucherawy wrote: > I've read it and I support its publication as well. I have some > edits to propose, which I can contribute as part of a formal AppsDir > review if you like since they are not major. I think it's as well to send this as part of that review, if you don't mind, just so that we can get this document moving. > Are you planning to make this a WG document or send it through under > its current name? I was going to ship it as is as the product of the WG, but your remark made me realise that there's a bureaucratic snafu that results in that case. So it'll have to get a name change. Sigh. I'll get Donald to submit it with the changed name, but it will otherwise be exactly the same as passed WGLC. Thanks for tweaking me on this, it was a silly mistake to make. A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Wed Jan 11 12:46:21 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54E421F854E for ; Wed, 11 Jan 2012 12:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fTZAh+EJ2-z for ; Wed, 11 Jan 2012 12:46:21 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8356911E8073 for ; Wed, 11 Jan 2012 12:46:21 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 11 Jan 2012 12:46:10 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 11 Jan 2012 12:46:17 -0800 From: "Murray S. Kucherawy" To: "dnsext@ietf.org" Date: Wed, 11 Jan 2012 12:46:15 -0800 Thread-Topic: [dnsext] disposition of draft-eastlake-dnsext-xnamercode-05 (was: DNSEXT closing down soon) Thread-Index: AczQoHLnZ20d063nS+W8+FaVcpeoEwAAX5Uw Message-ID: References: <4ED94590.3090902@ogud.com> <20120110145640.GC6201@crankycanuck.ca> <6BC842FB-FC81-4B1A-8EFF-735314D77141@hopcount.ca> <20120111162112.GD1334@mail.yitter.info> <20120111203434.GH2024@mail.yitter.info> In-Reply-To: <20120111203434.GH2024@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SM Subject: Re: [dnsext] disposition of draft-eastlake-dnsext-xnamercode-05 (was: DNSEXT closing down soon) 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 Jan 2012 20:46:22 -0000 > -----Original Message----- > From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Wednesday, January 11, 2012 12:35 PM > To: dnsext@ietf.org > Subject: Re: [dnsext] disposition of draft-eastlake-dnsext-xnamercode-05 = (was: DNSEXT closing down soon) >=20 > > I've read it and I support its publication as well. I have some > > edits to propose, which I can contribute as part of a formal AppsDir > > review if you like since they are not major. >=20 > I think it's as well to send this as part of that review, if you don't > mind, just so that we can get this document moving. >=20 > > Are you planning to make this a WG document or send it through under > > its current name? >=20 > I was going to ship it as is as the product of the WG, but your remark > made me realise that there's a bureaucratic snafu that results in that > case. So it'll have to get a name change. Sigh. I'll get Donald to > submit it with the changed name, but it will otherwise be exactly the > same as passed WGLC. OK, I'll watch for the WG version and do a review based on it. (Cc'ing SM so he can schedule the AppsDir assignment accordingly.) -MSK From internet-drafts@ietf.org Wed Jan 11 16:00:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E1811E809F; Wed, 11 Jan 2012 16:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uE9ebaf8RFkN; Wed, 11 Jan 2012 16:00:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7FF21F84DE; Wed, 11 Jan 2012 16:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120112000002.18893.22420.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2012 16:00:02 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-xnamercode-00.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, 12 Jan 2012 00:00:03 -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 : xNAME RCODE and Status Bits Clarification Author(s) : Donald E. Eastlake 3rd Filename : draft-ietf-dnsext-xnamercode-00.txt Pages : 9 Date : 2012-01-11 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-xnamercode-00.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-xnamercode-00.txt From Ed.Lewis@neustar.biz Thu Jan 12 08:47:54 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C3021F8527 for ; Thu, 12 Jan 2012 08:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMlqcuFmqFS5 for ; Thu, 12 Jan 2012 08:47:53 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 409D721F8504 for ; Thu, 12 Jan 2012 08:47:53 -0800 (PST) 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 q0CGlouM044169; Thu, 12 Jan 2012 11:47:51 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.174] by Work-Laptop-2.local (PGP Universal service); Thu, 12 Jan 2012 11:47:53 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 12 Jan 2012 11:47:53 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20120109222905.GW1820@crankycanuck.ca> References: <20120109222905.GW1820@crankycanuck.ca> Date: Thu, 12 Jan 2012 11:47:48 -0500 To: dnsext@ietf.org From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [dnsext] Comments on draft-srose-dnssec-registry-update-00 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 Jan 2012 16:47:54 -0000 Source: http://tools.ietf.org/html/draft-srose-dnssec-registry-update-00 Some contents are formatting, one is about content. # Trans- # Zone action # Number Description Mnemonic Sign Sign Reference # ------ ----------- ------ ---- ----- --------- # 0 Reserved [RFC4034] # [RFC4398] # 1 RSA/MD5 RSAMD5 N Y [RFC3110] # # 2 Diffie-Hellman DH N Y [RFC2539] # 3 DSA/SHA-1 DSASHA1 Y Y [RFC2536] # 4 Reserved # 5 RSA/SHA-1 RSASHA1 Y Y [RFC3110] # # 6 DSA-NSEC3-SHA1 DSA-NSEC3 Y Y [RFC5155] # -SHA1 # 7 RSASHA1-NSEC3 RSASHA1- Y Y [RFC5155] # -SHA1 NSEC3- # SHA1 # 8 RSA/SHA-256 RSASHA256 Y * [RFC5702] # # 9 Reserved # 10 RSA/SHA-512 RSASHA512 Y * [RFC5702] # # 11 Reserved # 12 GOST R GOST-ECC Y * [RFC5933] # 34.10-2001 # 13-122 Unassigned # 123-251 Reserved [RFC6014] # 252 Reserved for INDIRECT N N [RFC4034] # Indirect keys # 253 private PRIVATE Y Y [RFC4034] # algorithm # 254 private PRIVATEOID Y Y [RFC4034] # algorithm OID # 255 Reserved Content - There is no reference for 4,9,11. I would nominate the RFC [that this draft may become] be the reference entry. And for 13-122 & 123-251, the reference should be the document that defines how they are assigned. 255 - should this be RFC 4034 too? (In order from kind of an issue to would be nicer if...) Formatting - the use of blank lines is inconsistent. (After 1, there's a totally blank line, not after 0,2,3,... Formatting - the Numbers column doesn't line up. Formatting - If the table was wider, could we avoid the wrapping? (Perhaps whitespace issues are IANA's.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Vote for the word of the day: "Papa"razzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate "red tape" From msk@cloudmark.com Thu Jan 12 10:35:05 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FD021F84D7; Thu, 12 Jan 2012 10:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlsmHeY0CtDB; Thu, 12 Jan 2012 10:35:03 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8E25521F84D6; Thu, 12 Jan 2012 10:35:03 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 12 Jan 2012 10:34:55 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 12 Jan 2012 10:35:02 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" , "draft-ietf-dnsext-xnamercode.all@tools.ietf.org" Date: Thu, 12 Jan 2012 10:35:00 -0800 Thread-Topic: AppsDir Review of draft-ietf-dnsext-xnamercode Thread-Index: AczRWOSb3T5cxrYTTDKTQq7fMmXudQ== Message-ID: 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_F5833273385BB34F99288B3648C4F06F19C6C15851EXCHC2corpclo_" MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode 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 Jan 2012 18:35:05 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C15851EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/a= rea/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-ietf-dnsext-xnamercode Title: xNAME RCODE and Status Bits Clarification Reviewer: Murray S. Kucherawy Review Date: January 12, 2012 IETF Last Call Date: N/A IESG Telechat Date: N/A The draft clarifies prior ambiguities with respect to how a resolver is sup= posed to report answer meta-data when resolving a name where the first answ= er returned in a potential series of query-responses is actually a pointer = to another record. It is precise and concise. Summary: This draft is almost ready for publication as a Standards Track RF= C but has a couple of issues that should be addressed before publication. Major Issues: Given that this is a potentially important clarification with interoperabil= ity considerations, I believe this document should say it updates at least = RFC1035 (since its ambiguity is specifically called out), and possibly RFC2= 672 and RFC2308. Make sure the Abstract also says this explicitly. Minor Issues: In Section 1, "There is a proposal for another redirection RR." Is it appr= opriate to make reference to that here? I don't know to which one you're r= eferring or what status it has, so the answer might be "no"; just checking. Section 2 identifies two status bits as part of this clarification document= . However, it also says explicitly that their definitions are unchanged fr= om the documents that introduced them. I'm curious then as to why they are= included in this document at all; that is, what clarification is being pro= vided? Unlike Section 3, any ambiguity about their use has not been identi= fied here. If in fact there isn't any, I think this section can be removed= . If you like, you can introduce references to and overviews of their defi= nitions in a new subsection of Section 1, since you do talk about them in S= ection 4. Nits: In Section 3, the exclamation mark legitimately relays bewilderment here, b= ut unfortunately I think it should just be a period. Even better would be = to end the sentence with "says that some servers are implemented differentl= y" or suchlike. In Section 4, the clause "if the following apply" should be amended by addi= ng "all of" or "one of" or something more specific. --_000_F5833273385BB34F99288B3648C4F06F19C6C15851EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have been selected as the Applic= ations Area Directorate reviewer for this draft (for background on appsdir,= please see  = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAre= aDirectorate).

Please resolve these comments along wi= th any other Last Call comments you may receive. Please wait for direction = from your document shepherd or AD before posting a new version of the draft= .

Document: draft-ietf-dnsext-xnamercode
Title: xNAME R= CODE and Status Bits Clarification
Reviewer: Murray S. Kucherawy
Revi= ew Date: January 12, 2012
IETF Last Call Date: N/A
IESG Telechat Date= : N/A

The draft clarifies prior ambiguities with respect t= o how a resolver is supposed to report answer meta-data when resolving a na= me where the first answer returned in a potential series of query-responses= is actually a pointer to another record.  It is precise and concise.<= o:p>

Summary: This draft is almost ready for publication as a S= tandards Track RFC but has a couple of issues that should be addressed befo= re publication.

Major Issues:

Given tha= t this is a potentially important clarification with interoperability consi= derations, I believe this document should say it updates at least RFC1035 (= since its ambiguity is specifically called out), and possibly RFC2672 and R= FC2308.  Make sure the Abstract also says this explicitly.<= /p>

Minor Issues:

In Section 1, “There is a propos= al for another redirection RR.”  Is it appropriate to make refer= ence to that here?  I don’t know to which one you’re refer= ring or what status it has, so the answer might be “no”; just c= hecking.

Section 2 identifies two status bits as part of t= his clarification document.  However, it also says explicitly that the= ir definitions are unchanged from the documents that introduced them. = I’m curious then as to why they are included in this document at all= ; that is, what clarification is being provided?  Unlike Section 3, an= y ambiguity about their use has not been identified here.  If in fact = there isn’t any, I think this section can be removed.  If you li= ke, you can introduce references to and overviews of their definitions in a= new subsection of Section 1, since you do talk about them in Section 4.

Nits:

In Section 3, the exclamation mark le= gitimately relays bewilderment here, but unfortunately I think it should ju= st be a period.  Even better would be to end the sentence with “= says that some servers are implemented differently” or suchlike.=

In Section 4, the clause “if the following apply” = should be amended by adding “all of” or “one of” or= something more specific.

= --_000_F5833273385BB34F99288B3648C4F06F19C6C15851EXCHC2corpclo_-- From yaojk@cnnic.cn Thu Jan 12 17:18:20 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D6B11E8099 for ; Thu, 12 Jan 2012 17:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.545 X-Spam-Level: X-Spam-Status: No, score=-99.545 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HML+jlE+Fhtd for ; Thu, 12 Jan 2012 17:18:19 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 1D9C711E8091 for ; Thu, 12 Jan 2012 17:18:18 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 13 Jan 2012 09:18:12 +0800 Message-ID: <47C8025504E444A98A500373ADE7683B@LENOVO47E041CF> From: "Jiankang YAO" To: Date: Fri, 13 Jan 2012 09:18:12 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0425_01CCD1D4.45E047A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: [dnsext] any interest to move bname forward before dnsext closing down 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 Jan 2012 01:18:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0425_01CCD1D4.45E047A0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCiAgY25hbWUgbWFwcyBoaW1zZWxmLiBkbmFtZSBtYXBzIGhpcyBjaGlsZHJl bi4gYm5hbWUgbWFwcyBib3RoIGhpbXNlbGYgYW5kIGhpcyBjaGlsZHJlbi4NCiAgSSBzdWdnZXN0 IGJuYW1lIGFzIGEgZ2VuZXJhbCB0b29sIHRvIG1hcCBib3RoIGhpbXNlbGYgYW5kIGhpcyBjaGls ZHJlbiwgbm90IGFpbWluZyBhdCBzb2x2aW5nIGlkbiBhbGlhcyBwcm9ibGVtLiBJRE4gdXNlcnMg bWF5IG9yIG1heSBub3QgY2hvb3NlIGl0IHRvIHNvbHZlIHRoZWlyIHByb2JsZW0uDQogIEkgdGhp bmsgdGhhdCBibmFtZSBpcyBhIHVzZWZ1bCB0b29sIHRvIG1hcCBkb21haW4gQSB0byBkb21haW4g Qi4NCg0KICBJcyB0aGVyZSBhbnkgaW50ZXJlc3QgdG8gbW92ZSBibmFtZSBmb3J3YXJkIGJlZm9y ZSBkbnNleHQgY2xvc2luZyBkb3duDQoNCg0KSmlhbmthbmcgWWFv ------=_NextPart_000_0425_01CCD1D4.45E047A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE5MTcwIj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jY2NlOGNmPg0KPERJVj48Rk9OVCBzaXplPTI+RGVhciBhbGwsPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+Jm5ic3A7IGNuYW1lIG1hcHMgaGltc2VsZi4gZG5hbWUgbWFwcyBoaXMgY2hpbGRy ZW4uIGJuYW1lIG1hcHMgDQpib3RoIGhpbXNlbGYgYW5kIGhpcyBjaGlsZHJlbi48L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsgSSBzdWdnZXN0IGJuYW1lIGFzIGEgZ2VuZXJh bCB0b29sIHRvIG1hcCBib3RoIGhpbXNlbGYgDQphbmQgaGlzIGNoaWxkcmVuLCBub3QgYWltaW5n IGF0IHNvbHZpbmcgaWRuIGFsaWFzIHByb2JsZW0uIElETiB1c2VycyBtYXkgb3IgbWF5IA0Kbm90 IGNob29zZSBpdCB0byBzb2x2ZSB0aGVpciBwcm9ibGVtLjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPiZuYnNwOyZuYnNwO0kgdGhpbmsgdGhhdCBibmFtZSBpcyBhIHVzZWZ1bCB0b29s IHRvIG1hcCBkb21haW4gDQpBIHRvIGRvbWFpbiBCLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyBJcyB0 aGVyZSBhbnkgaW50ZXJlc3QgdG8gbW92ZSBibmFtZSBmb3J3YXJkIGJlZm9yZSANCmRuc2V4dCBj bG9zaW5nIGRvd248L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj5KaWFua2FuZyBZYW88L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0425_01CCD1D4.45E047A0-- From weiler@watson.org Thu Jan 12 20:12:00 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085DA21F85EE for ; Thu, 12 Jan 2012 20:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYSC5zQzWScG for ; Thu, 12 Jan 2012 20:11:59 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7C57F21F854A for ; Thu, 12 Jan 2012 20:11:59 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q0D4BtYP073081; Thu, 12 Jan 2012 23:11:55 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q0D4Bt8d073077; Thu, 12 Jan 2012 23:11:55 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 12 Jan 2012 23:11:55 -0500 (EST) From: Samuel Weiler To: Andrew Sullivan In-Reply-To: <20120109222905.GW1820@crankycanuck.ca> Message-ID: References: <20120109222905.GW1820@crankycanuck.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 12 Jan 2012 23:11:55 -0500 (EST) Cc: dnsext@ietf.org Subject: Re: [dnsext] Follow up on draft-ietf-dnsext-dnssec-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: Fri, 13 Jan 2012 04:12:00 -0000 Looking just at draft-srose-dnssec-registry-update-00: 1) the propsoed replacement registry no longer mentions that algorithm 1 has been deprecated (as currently indicated in the IANA registry). If that flag is to be removed, perhaps that should be called out in section 2.1 as a change. 2) The original IANA registry contains some trailing data re: DH primes. It might be worth explaining/mentioning that. 3) Three algorithms continue to have asterisks in the transaction security column (here renamed to Transaction Sign), with a footnote (originally from RFC5702) saying "There has been no determination of standardization of the use of this algorithm with Transaction Security." Can we say anything more re: these three algorithms' usefulness for SIG(0) or TSIG? If not, we at least need to leave that footnote expansion in the registry. From weiler@watson.org Thu Jan 12 20:20:16 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C83121F8484 for ; Thu, 12 Jan 2012 20:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP9A2gVYpI2A for ; Thu, 12 Jan 2012 20:20:15 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9899821F847E for ; Thu, 12 Jan 2012 20:20:15 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q0D4KFA7074960 for ; Thu, 12 Jan 2012 23:20:15 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q0D4KFPt074956 for ; Thu, 12 Jan 2012 23:20:15 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 12 Jan 2012 23:20:14 -0500 (EST) From: Samuel Weiler To: dnsext@ietf.org In-Reply-To: Message-ID: References: <20111012144101.205a61dff9fc1684c258b274662bb912.3f5e55ecf1.wbe@email00.se cureserver.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-321806595-1326428289=:86374" Content-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 12 Jan 2012 23:20:15 -0500 (EST) Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14) 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 Jan 2012 04:20:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-321806595-1326428289=:86374 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: I don't recall seeing much discussion of the below. As doc editor, I would like to hear an extra voice or three chime in before I fix this. As I understand Ed's message, the (signer) name in an RRSIG does need to be downcased. The next name in a NSEC RR does NOT need to be downcased. Is that right? On Thu, 13 Oct 2011, Edward Lewis wrote: > In this section of the still-a-draft update to the DNSSEC definition of RFC 4033-4035 an issue has arisen that needs to be addressed. > > # http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-14 > # > #5.1.  Errors in Canonical Form Type Code List > # > #   When canonicalizing DNS names, DNS names in the RDATA section of NSEC > #   and RRSIG resource records are not downcased. > # > #   [RFC4034] Section 6.2 item 3 has a list of resource record types for > #   which DNS names in the RDATA are downcased for purposes of DNSSEC > #   canonical form (for both ordering and signing).  That list > #   erroneously contains NSEC and RRSIG.  According to [RFC3755], DNS > #   names in the RDATA of NSEC and RRSIG should not be downcased. > # > #   The same section also erroneously lists HINFO, and twice at that. > #   Since HINFO records contain no domain names, they are not subject to > #   downcasing. > > For the purposes of this email a "major implementation" refers to a widely distributed general purpose implementation of DNS.  It's become apparent > that two major implementations of validators have differed on downcaseing the RRSIG. > > We've been trying to determine why this problem hasn't surfaced in a real-world outage.  It seems that all major implementations of signers down case > the RRSIG before signing. > > Treat this as a suggestion.  Unexcuse RRSIG from the list of names that avoid downcasing.  (NSEC is not a problem.)  Any thoughts? > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis              > NeuStar                    You can leave a voice message at +1-571-434-5468 > > Vote for the word of the day: > "Papa"razzi - father that constantly takes photos of the baby > Corpureaucracy - The institution of corporate "red tape" > > --621616949-321806595-1326428289=:86374-- From richard@highwayman.com Fri Jan 13 03:35:22 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A2C21F8505 for ; Fri, 13 Jan 2012 03:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoOFSK4xzlRG for ; Fri, 13 Jan 2012 03:35:21 -0800 (PST) Received: from anchor-post-1.mail.demon.net (anchor-post-1.mail.demon.net [195.173.77.132]) by ietfa.amsl.com (Postfix) with ESMTP id C851121F8517 for ; Fri, 13 Jan 2012 03:35:20 -0800 (PST) Received: from happyday.demon.co.uk ([80.177.121.10] helo=happyday.al.cl.cam.ac.uk) by anchor-post-1.mail.demon.net with esmtp (Exim 4.69) id 1RlfPj-0005Ls-gJ for dnsext@ietf.org; Fri, 13 Jan 2012 11:35:19 +0000 Message-ID: <6lgt$$J8ZBEPFAi2@highwayman.com> Date: Fri, 13 Jan 2012 11:33:16 +0000 To: dnsext@ietf.org From: Richard Clayton MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Turnpike Integrated Version 5.03 M Subject: [dnsext] Call for Papers: Securing and Trusting Internet Names, SATIN 2012 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Richard Clayton List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 11:35:22 -0000 The usual apologies if you see multiple copies of this CFP, but the inhabitants of this mailing list are more likely than most to wish to submit papers! Call for Papers: Securing and Trusting Internet Names, SATIN 2012 =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=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 When: Thu/Fri 22/23 March 2012 NB: ** NEW ** we are expecting to run the Spring DNS-OARC meeting on Wed 21 March Also note that IETF 83 is in Paris, France the following week Where: National Physical Laboratory (NPL) Teddington, London, UK Timetable: Submissions due: Sun 23 Jan 2011, 11:59 PST Notification of Acceptance: Wed 23 Feb 2011 Final Papers Due: Mon 15 Mar 2011 ** NEW ** Requests for a short (7 day) extension to the submission deadline will be entertained by the Program Chair. However, title, authors and abstract MUST be submitted to the website by the original 23 Jan deadline ** NEW ** Workshop Organizers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Program Chair Richard Clayton NPL and University of Cambridge Program Committee Nevil Brownlee University of Auckland Ben Laurie Google Anne-Marie Eklund L=F6winder .SE (The Internet Infrastructure Foundation) Dan Massey Colorado State University Douglas Maughan Department of Homeland Security Andrew W Moore University of Cambridge Jose Nazario Arbor Networks Roberto Perdisci University of Georgia Dave Piscitello ICANN Paul Vixie ISC Nicholas Weaver ICSI & UC Berkeley Jonathan Williams NPL Overview =3D=3D=3D=3D=3D=3D=3D=3D The domain name system, on which the Internet entirely relies, has always been inherently insecure. Spoofing of IP source addresses means that any wide area UDP protocol (such as DNS) can be forged. Cache poisoning attacks can be made less likely but not prevented altogether. ISPs, or others who can intercept traffic, can redirect end users to sites of their choosing. Users can choose (or have forced upon them) DNS services that suppress access to sites for policy reasons. DNSSEC, which addresses some of these issues, has been under development for years - but is finally ready for use; although some of the finer details are still being worked out. However, even at the current scale of deployment, implementation issues are creating unexpected levels of traffic, and that is before the bad guys make any contribution. Meanwhile DNSCURVE is being promoted as a lightweight method of securing the links to and between name servers, which addresses some, but by no means all, of the security issues. DNSSEC is also being seen by some as a distributed, secure, key distribution system, which could support new applications, or replace existing mechanisms for establishing trust in the identity of endpoints. The IETF's DANE working group is already addressing these issues. Others merely see DNSSEC as a way of defeating marketers who want to inject targeted advertising into browser sessions. But how effective will these ideas be if we continue with our existing APIs and stub resolvers? There are significant issues with DNS besides just its integrity. DNS services can be used to amplify denial-of-service attacks to create very substantial traffic flows. Malware has also been using the DNS for rendezvous arrangements, and has avoided countermeasures by exploiting the DNS system through "fluxing" and other techniques. There are also signs of a "tragedy of the commons" as legitimate companies fill the DNS with large numbers of names, or set low TTLs, to give a performance "edge". Meanwhile, some applications pre-fetch DNS answers, with little heed to the impact on the infrastructure. This latter technique raises privacy issues, as indeed does the proposal to 'leak' partial identities of requestors who contact recursive resolvers, with the aim of providing different answers to machines in different blocks of address space. All of this makes DNS, once amongst the most boring of topics, into one of the more exciting. The first running of this workshop in April 2011 was a big success, and this second event will be equally significant. Topics =3D=3D=3D=3D=3D=3D SATIN aims to provide a forum for academic work on the security of the DNS alongside industry presentations on practical experiences in providing name services. This workshop will expose the academics to the real problems that industry is encountering, and show industry what academia has to offer them. To improve the flow of information (and as was most successful at the first SATIN workshop) presentations will be restricted to 15 minutes with 15 minutes of general discussion to follow. Submissions must be made under either an "academic" or "industry" label (relating entirely to the content rather than the affiliations of any author), because the two types will be judged by different standards. Academic work will be viewed as an "extended abstract" and should aim to meet the general standard for acceptance into normal conferences in the field. However, since this is a workshop, early results and initial ideas are welcomed. Industry submissions should be relevant, insightful, and technical, and should provide information that cannot be gleaned from reading sales brochures or manuals. In all cases, real-world operational, implementation, and experimental results will be preferred, and these results should inform the DNS protocol development process wherever relevant or possible. Topics of interest include but are not limited to: Attacks on naming services DNSSEC DNSCURVE Alternative methods of securing name services APIs for DNS resolvers Using DNS as a platform for other applications Denial of service and the DNS Malware and the DNS DNS caching on the modern Internet Privacy and the DNS Application behaviour and the DNS Security economics of naming services Passive DNS Operational experience Measurement studies New threats and challenges Questions regarding whether a topic would be suitable are welcome and should be sent to the program chair, richard.clayton AT npl.co.uk Submissions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All submissions must be in IEEE two column format and no longer than eight (8) 8.5'' x 11'' pages, including figures, tables, and references. That means that the text must be set in two columns in 10 point type on 12 point (single-spaced) leading, with the text block being no more than 7.2'' wide by 9.6'' deep. Author names and affiliations should appear on the title page. The use of LaTeX and the IEEEtrans.cls file to create submissions is very strongly encouraged: http://conferences.npl.co.uk/satin/format.html Submissions must be submitted in PDF format via the SATIN 2012 website: http://conferences.npl.co.uk/satin/submit.html Simultaneous submission of the same work to multiple venues, submission of previously published work, or plagiarism, is dishonest and/or fraudulent and action may be taken if this occurs. Note, however, that we expect that many papers accepted for SATIN will eventually be extended as full papers suitable for presentation at other conferences. About the National Physical Laboratory =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=3D The National Physical Laboratory (NPL) is one of the UK's leading science and research facilities. It is a world-leading centre of excellence in developing and applying the most accurate standards, science and technology available. NPL occupies a unique position as the UK's National Measurement Institute and sits at the intersection between scientific discovery and real world application. Its expertise and original research have underpinned quality of life, innovation and competitiveness for UK citizens and business for more than a century. NPL is collaborating with the University of Cambridge in a three year programme to develop robust and accurate measurements of Internet security mechanisms. Measuring and understanding the deployment of DNSSEC and other trust mechanisms for Internet names is a key part of this ongoing programme. More at: http://conferences.npl.co.uk/satin/ --=20 Dr Richard Clayton tel: +44 1223 763570, mobile: +44 7887 794090 Computer Laboratory, University of Cambridge, CB3 0FD National Physical Laboratory, Hampton Road, Teddington, TW11 0LW From weiler@watson.org Fri Jan 13 03:55:48 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423C021F8522 for ; Fri, 13 Jan 2012 03:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAt5NsLMbr1z for ; Fri, 13 Jan 2012 03:55:47 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id B414921F850C for ; Fri, 13 Jan 2012 03:55:47 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q0DBtiXV012207; Fri, 13 Jan 2012 06:55:44 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q0DBthr3012200; Fri, 13 Jan 2012 06:55:43 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 13 Jan 2012 06:55:43 -0500 (EST) From: Samuel Weiler To: Andrew Sullivan In-Reply-To: <20120109222905.GW1820@crankycanuck.ca> Message-ID: References: <20120109222905.GW1820@crankycanuck.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 13 Jan 2012 06:55:44 -0500 (EST) Cc: dnsext@ietf.org Subject: [dnsext] draft-srose-dnssec-algo-imp-status-00 (was: Re: Follow up on draft-ietf-dnsext-dnssec-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: Fri, 13 Jan 2012 11:55:48 -0000 I generally support the idea behind this draft (putting current recommendation state in an RFC), but I have some minor concerns about the specific content: "The status of RSASHA1-NSEC3-SHA1 is set to RECOMMENDED TO IMPLEMENT. This is due to the fact that RSA/SHA-1 is a MUST IMPLEMENT." I don't follow the logic in the above. Why does A follow from B? "Adding a newly specified algorithm to the registry with a compliance status SHALL entail obsolescing this document and replacing the registry table (with the new algorithm entry)." I suggest: "Adding...with an implementation status other than OPTIONAL SHALL....and publishing a new document with a new complete registry table." Throughout this document, "implementation status", "compliance status", and "implementations compliance status" appear. I don't understand the difference between the three. If there is none, pick one and stick to it. In security considerations: "This document replaces the Domain Name System (DNS) Security Algorithm Numbers registry." I don't think you intended to write that in this document. -- Sam From steve@shinkuro.com Fri Jan 13 04:23:38 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C2A21F8606 for ; Fri, 13 Jan 2012 04:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLkoLqKlsQWm for ; Fri, 13 Jan 2012 04:23:37 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 61CC121F8653 for ; Fri, 13 Jan 2012 04:23:36 -0800 (PST) Received: from [69.143.222.58] (HELO [10.0.1.5]) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 20189073; Fri, 13 Jan 2012 12:28:03 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Steve Crocker In-Reply-To: Date: Fri, 13 Jan 2012 07:23:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120109222905.GW1820@crankycanuck.ca> To: Samuel Weiler X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-srose-dnssec-algo-imp-status-00 (was: Re: Follow up on draft-ietf-dnsext-dnssec-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: Fri, 13 Jan 2012 12:23:38 -0000 Sam, Thanks for your comments. Scott and I will work on these. Steve On Jan 13, 2012, at 6:55 AM, Samuel Weiler wrote: > I generally support the idea behind this draft (putting current = recommendation state in an RFC), but I have some minor concerns about = the specific content: >=20 > "The status of RSASHA1-NSEC3-SHA1 is set to RECOMMENDED TO IMPLEMENT. = This is due to the fact that RSA/SHA-1 is a MUST IMPLEMENT." >=20 > I don't follow the logic in the above. Why does A follow from B? >=20 > "Adding a newly specified algorithm to the registry with a compliance = status SHALL entail obsolescing this document and replacing the registry = table (with the new algorithm entry)." >=20 > I suggest: "Adding...with an implementation status other than OPTIONAL = SHALL....and publishing a new document with a new complete registry = table." >=20 > Throughout this document, "implementation status", "compliance = status", and "implementations compliance status" appear. I don't = understand the difference between the three. If there is none, pick one = and stick to it. >=20 > In security considerations: "This document replaces the Domain Name = System (DNS) Security Algorithm Numbers registry." I don't think you = intended to write that in this document. >=20 > -- Sam >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From ogud@ogud.com Fri Jan 13 07:34:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B839821F859F for ; Fri, 13 Jan 2012 07:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tBW7+bOzVtz for ; Fri, 13 Jan 2012 07:34:02 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id EE66D21F85AE for ; Fri, 13 Jan 2012 07:34:01 -0800 (PST) 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 q0DFY0xG052923 for ; Fri, 13 Jan 2012 10:34:00 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F104EE6.30806@ogud.com> Date: Fri, 13 Jan 2012 10:33:58 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <47C8025504E444A98A500373ADE7683B@LENOVO47E041CF> In-Reply-To: <47C8025504E444A98A500373ADE7683B@LENOVO47E041CF> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] any interest to move bname forward before dnsext closing down 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 Jan 2012 15:34:02 -0000 On 14:59, Andrew Sullivan wrote: > Dear colleagues, > > On Fri, Jan 13, 2012 at 09:18:12AM +0800, Jiankang YAO wrote: >> >> Is there any interest to move bname forward before dnsext closing down > > Regardless of the interest, we can't do it in this working group. Our > charter said we would complete the study of aliasing before doing > that, and we haven't completed it. This is not true, our charter does not say that, our policy was to wait for aliasing study before proceeding. We can at any time change our policy, if the WG ask us to do that. > Even if we ignored that, our AD > asked us to be ready to shut down in the spring, and there is zero > hope that BNAME could be ready for publication by then, since it would > be necessary to figure out how to make BNAME deployable given the fact > of deployed DNSSEC and existing validators on the net (the draft as it > stood at expiration had no answer for this -- it effectively said that > all the DNSSEC infrastructure on the Internet had to be upgraded > first). This is true but to tone is more negative than I like so here is reword: Even if the WG decided to take up this work today, considering that we are closing down in about 3 months there is little chance that we can finalize the protocol spec and do interop testing in order to be able to advance this work. The reason we need interop testing is that this work requires most DNS resolvers and servers to be updated before BNAME is useful on its own. We also need to make sure there are no negative side effects of the deployment hacks to support early BNAME deployment. > Unless I missed it, I've never seen a suggestion on how that > could be solved apart from "online signing", which doesn't seem to me > to be a real answer. > Drop the above, too inflammatory. > If there were a clear and careful needs analysis (and I believe the > case could be made without talking about IDN -- website redirection is > another example), and there were evidence of work being done, I'd s/I'd/chairs can/ > argue to the AD that the WG was still labouring over this topic and s/labouring/laboring/ > that it would complete the work. But in fact, the aliasing > requirements draft expired, and very little discussion of it took > place prior to that expiry. > I conclude that there may be interest in > that work, but not in this working group, so we should stop pretending > we're going to work on it. > Replace by: We do not see much evidence of interest in this work in the WG, unless there is interest there is no reason to make commitment to work on this protocol extension. Olafur & Andrew > Best regards, > > Andrew > From ogud@ogud.com Fri Jan 13 07:44:49 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C251621F860B for ; Fri, 13 Jan 2012 07:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4OXh2YXR1rw for ; Fri, 13 Jan 2012 07:44:49 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 08D5021F859B for ; Fri, 13 Jan 2012 07:44:48 -0800 (PST) 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 q0DFilfw053027 for ; Fri, 13 Jan 2012 10:44:47 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F10516E.205@ogud.com> Date: Fri, 13 Jan 2012 10:44:46 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <20111012144101.205a61dff9fc1684c258b274662bb912.3f5e55ecf1.wbe@email00.se cureserver.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14) 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 Jan 2012 15:44:49 -0000 WG, Please help our editor to close this issue by either sending +1 to the resolution below or explain why not. Chairs would like to see this issue closed in the next few days. Olafur On 12/01/2012 23:20, Samuel Weiler wrote: > I don't recall seeing much discussion of the below. As doc editor, I > would like to hear an extra voice or three chime in before I fix this. > > As I understand Ed's message, the (signer) name in an RRSIG does need to > be downcased. The next name in a NSEC RR does NOT need to be downcased. > Is that right? > > On Thu, 13 Oct 2011, Edward Lewis wrote: > >> In this section of the still-a-draft update to the DNSSEC definition >> of RFC 4033-4035 an issue has arisen that needs to be addressed. >> >> # http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-14 >> # >> #5.1. Errors in Canonical Form Type Code List >> # >> # When canonicalizing DNS names, DNS names in the RDATA section of NSEC >> # and RRSIG resource records are not downcased. >> # >> # [RFC4034] Section 6.2 item 3 has a list of resource record types for >> # which DNS names in the RDATA are downcased for purposes of DNSSEC >> # canonical form (for both ordering and signing). That list >> # erroneously contains NSEC and RRSIG. According to [RFC3755], DNS >> # names in the RDATA of NSEC and RRSIG should not be downcased. >> # >> # The same section also erroneously lists HINFO, and twice at that. >> # Since HINFO records contain no domain names, they are not subject to >> # downcasing. >> >> For the purposes of this email a "major implementation" refers to a >> widely distributed general purpose implementation of DNS. It's become >> apparent >> that two major implementations of validators have differed on >> downcaseing the RRSIG. >> >> We've been trying to determine why this problem hasn't surfaced in a >> real-world outage. It seems that all major implementations of signers >> down case >> the RRSIG before signing. >> >> Treat this as a suggestion. Unexcuse RRSIG from the list of names >> that avoid downcasing. (NSEC is not a problem.) Any thoughts? >> >> -- >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> >> Edward Lewis >> NeuStar You can leave a voice message at >> +1-571-434-5468 >> >> Vote for the word of the day: >> "Papa"razzi - father that constantly takes photos of the baby >> Corpureaucracy - The institution of corporate "red tape" >> >> > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From ogud@ogud.com Fri Jan 13 07:47:07 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E0121F8581 for ; Fri, 13 Jan 2012 07:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww9oMug2pV9j for ; Fri, 13 Jan 2012 07:47:06 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id A910021F857D for ; Fri, 13 Jan 2012 07:47:06 -0800 (PST) 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 q0DFl5U1053055 for ; Fri, 13 Jan 2012 10:47:05 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F1051F7.8020509@ogud.com> Date: Fri, 13 Jan 2012 10:47:03 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <47C8025504E444A98A500373ADE7683B@LENOVO47E041CF> <4F104EE6.30806@ogud.com> In-Reply-To: <4F104EE6.30806@ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] any interest to move bname forward before dnsext closing down 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 Jan 2012 15:47:07 -0000 Sorry I sent this to the mailing list instead of to andrew. Please ignore once, andrew and I agree on a statement we will post an official answer. This is totally my mistake. Olafur On 13/01/2012 10:33, Olafur Gudmundsson wrote: > On 14:59, Andrew Sullivan wrote: >> Dear colleagues, >> >> On Fri, Jan 13, 2012 at 09:18:12AM +0800, Jiankang YAO wrote: >>> >>> Is there any interest to move bname forward before dnsext closing down >> >> Regardless of the interest, we can't do it in this working group. Our >> charter said we would complete the study of aliasing before doing >> that, and we haven't completed it. > > This is not true, our charter does not say that, our policy was to wait > for aliasing study before proceeding. > We can at any time change our policy, if the WG ask us to do that. > > >> Even if we ignored that, our AD >> asked us to be ready to shut down in the spring, and there is zero >> hope that BNAME could be ready for publication by then, since it would >> be necessary to figure out how to make BNAME deployable given the fact >> of deployed DNSSEC and existing validators on the net (the draft as it >> stood at expiration had no answer for this -- it effectively said that >> all the DNSSEC infrastructure on the Internet had to be upgraded >> first). > > This is true but to tone is more negative than I like so here is reword: > Even if the WG decided to take up this work today, considering that we > are closing down in about 3 months there is little chance that we can > finalize the protocol spec and do interop testing in order to be able to > advance this work. The reason we need interop testing is that this work > requires most DNS resolvers and servers to be updated before > BNAME is useful on its own. We also need to make sure there are no > negative side effects of the deployment hacks to support early BNAME > deployment. > > >> Unless I missed it, I've never seen a suggestion on how that >> could be solved apart from "online signing", which doesn't seem to me >> to be a real answer. >> > > Drop the above, too inflammatory. > >> If there were a clear and careful needs analysis (and I believe the >> case could be made without talking about IDN -- website redirection is >> another example), and there were evidence of work being done, I'd > > s/I'd/chairs can/ > >> argue to the AD that the WG was still labouring over this topic and > > s/labouring/laboring/ > >> that it would complete the work. But in fact, the aliasing >> requirements draft expired, and very little discussion of it took >> place prior to that expiry. > > > I conclude that there may be interest in >> that work, but not in this working group, so we should stop pretending >> we're going to work on it. >> > > Replace by: > We do not see much evidence of interest in this work in the WG, > unless there is interest there is no reason to make commitment to work > on this protocol extension. > > Olafur & Andrew > >> Best regards, >> >> Andrew >> > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > > From ebw@abenaki.wabanaki.net Fri Jan 13 08:40:49 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB0321F8539 for ; Fri, 13 Jan 2012 08:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31zEFLR76tsv for ; Fri, 13 Jan 2012 08:40:49 -0800 (PST) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id D492121F8514 for ; Fri, 13 Jan 2012 08:40:47 -0800 (PST) Received: from limpet.local (cpe-67-255-2-48.twcny.res.rr.com [67.255.2.48]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q0DE3Wup093855 for ; Fri, 13 Jan 2012 09:03:33 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4F105E89.9090706@abenaki.wabanaki.net> Date: Fri, 13 Jan 2012 11:40:41 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <47C8025504E444A98A500373ADE7683B@LENOVO47E041CF> In-Reply-To: <47C8025504E444A98A500373ADE7683B@LENOVO47E041CF> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] any interest to move bname forward before dnsext closing down X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 16:40:49 -0000 I'm of the same view now as I was previously. A general means to map X to Y is useful. The aliasing issue is either orthogonal, or consumer domain specific. In either case, it is not necessary, though it was by it self, sufficient to motivate a nominally similar attempt. So I am willing to work on bname. Eric From internet-drafts@ietf.org Fri Jan 13 09:55:07 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A286E21F85CC; Fri, 13 Jan 2012 09:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY45fw5wVflo; Fri, 13 Jan 2012 09:55:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573C521F8591; Fri, 13 Jan 2012 09:54:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120113175454.10874.59415.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2012 09:54:54 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-bis-updates-15.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, 13 Jan 2012 17:55:07 -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 : Clarifications and Implementation Notes for DNSSECbis Author(s) : Samuel Weiler David Blacka Filename : draft-ietf-dnsext-dnssec-bis-updates-15.txt Pages : 20 Date : 2012-01-13 This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata. This document updates the core DNSSECbis documents (RFC4033, RFC4034, and RFC4035) as well as the NSEC3 specification (RFC5155). It also defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-15= .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-bis-updates-15.= txt From suruti94@gmail.com Fri Jan 13 10:33:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85AB21F8540 for ; Fri, 13 Jan 2012 10:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abC4L-zMGmOq for ; Fri, 13 Jan 2012 10:33:15 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6177921F852B for ; Fri, 13 Jan 2012 10:33:14 -0800 (PST) Received: by obcwo10 with SMTP id wo10so3148726obc.31 for ; Fri, 13 Jan 2012 10:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jMiqVCLM+RbGTHYpE7pr2efvCZMp27wDyipBKjxIVuw=; b=P4h5RrpK69w+vJCzr9Iy2NJmn4eGQ0DJc9XvgDXUBNq4fPGvxGiBWh4kgYqx+zb2JP R/Nz5dM7/4DctFgO+aeEr3Vz18ANhveA/2YVrwgDdabF+oV0+YJMN2mdVwjxcZXlBhl1 Nw0kt9NaxHTrKZ8SjxNwM7XiTHsCTAv99wvMc= MIME-Version: 1.0 Received: by 10.182.40.66 with SMTP id v2mr1807730obk.15.1326479593862; Fri, 13 Jan 2012 10:33:13 -0800 (PST) Received: by 10.182.147.105 with HTTP; Fri, 13 Jan 2012 10:33:13 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Jan 2012 10:33:13 -0800 Message-ID: From: Mohan Parthasarathy To: Samuel Weiler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14) 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 Jan 2012 18:33:16 -0000 On Thu, Jan 12, 2012 at 8:20 PM, Samuel Weiler wrote: > I don't recall seeing much discussion of the below. =A0As doc editor, I w= ould > like to hear an extra voice or three chime in before I fix this. > > As I understand Ed's message, the (signer) name in an RRSIG does need to = be > downcased. =A0The next name in a NSEC RR does NOT need to be downcased. = =A0Is > that right? +1. Sometime back there was an email thread (which I can't locate now) where the signature verification failed if you don't downcase for something in .US zone. -mohan > > > On Thu, 13 Oct 2011, Edward Lewis wrote: > >> In this section of the still-a-draft update to the DNSSEC definition of >> RFC 4033-4035 an issue has arisen that needs to be addressed. >> >> # http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-14 >> # >> #5.1.=A0 Errors in Canonical Form Type Code List >> # >> #=A0=A0 When canonicalizing DNS names, DNS names in the RDATA section of= NSEC >> #=A0=A0 and RRSIG resource records are not downcased. >> # >> #=A0=A0 [RFC4034] Section 6.2 item 3 has a list of resource record types= for >> #=A0=A0 which DNS names in the RDATA are downcased for purposes of DNSSE= C >> #=A0=A0 canonical form (for both ordering and signing).=A0 That list >> #=A0=A0 erroneously contains NSEC and RRSIG.=A0 According to [RFC3755], = DNS >> #=A0=A0 names in the RDATA of NSEC and RRSIG should not be downcased. >> # >> #=A0=A0 The same section also erroneously lists HINFO, and twice at that= . >> #=A0=A0 Since HINFO records contain no domain names, they are not subjec= t to >> #=A0=A0 downcasing. >> >> For the purposes of this email a "major implementation" refers to a wide= ly >> distributed general purpose implementation of DNS.=A0 It's become appare= nt >> that two major implementations of validators have differed on downcasein= g >> the RRSIG. >> >> We've been trying to determine why this problem hasn't surfaced in a >> real-world outage.=A0 It seems that all major implementations of signers= down >> case >> the RRSIG before signing. >> >> Treat this as a suggestion.=A0 Unexcuse RRSIG from the list of names tha= t >> avoid downcasing.=A0 (NSEC is not a problem.)=A0 Any thoughts? >> >> -- >> >> -=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=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 You can= leave a voice message at >> +1-571-434-5468 >> >> Vote for the word of the day: >> "Papa"razzi - father that constantly takes photos of the baby >> Corpureaucracy - The institution of corporate "red tape" >> > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From marka@isc.org Fri Jan 13 14:33:46 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A8621F85EC for ; Fri, 13 Jan 2012 14:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyTyGTMeYpNU for ; Fri, 13 Jan 2012 14:33:45 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B363921F85E4 for ; Fri, 13 Jan 2012 14:33:45 -0800 (PST) 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 ACF60C9465; Fri, 13 Jan 2012 22:33:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:1065:29aa:23b5:a4e6]) (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 5E1E9216C6A; Fri, 13 Jan 2012 22:33:31 +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 C8D621B12F44; Sat, 14 Jan 2012 09:33:28 +1100 (EST) To: ebw@abenaki.wabanaki.net From: Mark Andrews References: <47C8025504E444A98A500373ADE7683B@LENOVO47E041CF> <4F105E89.9090706@abenaki.wabanaki.net> In-reply-to: Your message of "Fri, 13 Jan 2012 11:40:41 CDT." <4F105E89.9090706@abenaki.wabanaki.net> Date: Sat, 14 Jan 2012 09:33:28 +1100 Message-Id: <20120113223328.C8D621B12F44@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] any interest to move bname forward before dnsext closing down 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 Jan 2012 22:33:46 -0000 In message <4F105E89.9090706@abenaki.wabanaki.net>, Eric Brunner-Williams write s: > I'm of the same view now as I was previously. > > A general means to map X to Y is useful. > > The aliasing issue is either orthogonal, or consumer domain specific. > In either case, it is not necessary, though it was by it self, > sufficient to motivate a nominally similar attempt. > > So I am willing to work on bname. As am I. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Fri Jan 13 14:50:32 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27CF21F846E for ; Fri, 13 Jan 2012 14:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8t6Z79Ji-oJ for ; Fri, 13 Jan 2012 14:50:32 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 217E821F8466 for ; Fri, 13 Jan 2012 14:50:32 -0800 (PST) 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 60D86C9484; Fri, 13 Jan 2012 22:50:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:1065:29aa:23b5:a4e6]) (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 1E1A3216C6B; Fri, 13 Jan 2012 22:50:16 +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 642F21B13171; Sat, 14 Jan 2012 09:50:13 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: In-reply-to: Your message of "Fri, 13 Jan 2012 10:33:13 -0800." Date: Sat, 14 Jan 2012 09:50:13 +1100 Message-Id: <20120113225013.642F21B13171@drugs.dv.isc.org> Cc: Samuel Weiler , dnsext@ietf.org Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14) 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 Jan 2012 22:50:32 -0000 In message , Mohan Parthasarathy writes: > On Thu, Jan 12, 2012 at 8:20 PM, Samuel Weiler wrote: > > I don't recall seeing much discussion of the below. =A0As doc editor, I w= > ould > > like to hear an extra voice or three chime in before I fix this. > > > > As I understand Ed's message, the (signer) name in an RRSIG does need to = > be > > downcased. =A0The next name in a NSEC RR does NOT need to be downcased. = > =A0Is > > that right? > +1. Sometime back there was an email thread (which I can't locate now) > where the signature verification failed if you don't downcase for > something in .US zone. > > -mohan named downcases the RRSIG's Signer's Name named does not downcase NSEC's Next Domain Name. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From warren@kumari.net Fri Jan 13 17:54:26 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589CF21F8505 for ; Fri, 13 Jan 2012 17:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+SGWLP9AoOK for ; Fri, 13 Jan 2012 17:54:25 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C3AF521F8503 for ; Fri, 13 Jan 2012 17:54:25 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 5DAB91B40BCB; Fri, 13 Jan 2012 20:54:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <20120113223328.C8D621B12F44@drugs.dv.isc.org> Date: Fri, 13 Jan 2012 20:54:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47C8025504E444A98A500373ADE7683B@LENOVO47E041CF> <4F105E89.9090706@abenaki.wabanaki.net> <20120113223328.C8D621B12F44@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] any interest to move bname forward before dnsext closing down 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 Jan 2012 01:54:26 -0000 On Jan 13, 2012, at 5:33 PM, Mark Andrews wrote: >=20 > In message <4F105E89.9090706@abenaki.wabanaki.net>, Eric = Brunner-Williams write > s: >> I'm of the same view now as I was previously. >>=20 >> A general means to map X to Y is useful. >>=20 >> The aliasing issue is either orthogonal, or consumer domain specific. >> In either case, it is not necessary, though it was by it self, >> sufficient to motivate a nominally similar attempt. >>=20 >> So I am willing to work on bname. >=20 > As am I. Hey! Me too! W >=20 > --=20 > 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 >=20 --- Don't be impressed with unintelligible stuff said condescendingly . -- Radia Perlman. Warren Kumari warren@kumari.net From internet-drafts@ietf.org Sat Jan 14 03:49:43 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF5B21F85EA; Sat, 14 Jan 2012 03:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsEDS-Xf-2zB; Sat, 14 Jan 2012 03:49:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45BE21F8568; Sat, 14 Jan 2012 03:49:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120114114942.12760.75083.idtracker@ietfa.amsl.com> Date: Sat, 14 Jan 2012 03:49:42 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-bis-updates-16.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: Sat, 14 Jan 2012 11:49:43 -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 : Clarifications and Implementation Notes for DNSSECbis Author(s) : Samuel Weiler David Blacka Filename : draft-ietf-dnsext-dnssec-bis-updates-16.txt Pages : 20 Date : 2012-01-13 This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata. This document updates the core DNSSECbis documents (RFC4033, RFC4034, and RFC4035) as well as the NSEC3 specification (RFC5155). It also defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-16= .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-bis-updates-16.= txt From d3e3e3@gmail.com Sat Jan 14 15:53:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A005221F84D9; Sat, 14 Jan 2012 15:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.358 X-Spam-Level: X-Spam-Status: No, score=-104.358 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sG8zTbZ4Nuwl; Sat, 14 Jan 2012 15:53:24 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 459EC21F84D8; Sat, 14 Jan 2012 15:53:23 -0800 (PST) Received: by lagv3 with SMTP id v3so1113849lag.31 for ; Sat, 14 Jan 2012 15:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=9NXP+55R/rk3aHjHLdCS9KBXJ4Jkm17rnKnfNsMWHgM=; b=YvqNdOWCsE+FTDKG/Kr/UO552T9NtunYb29Eqd7XGgrznfiHQzwzY/D30pO4aoTOtg PncHku+yZIP0dtgo6zC7ayHuCRfvWC9YESlo91JteNtHwIkrrjtytwPaWlSuS0KQQSo+ RWc3XADtiePpilfTi02k1maPedc1j/PkgLXH0= Received: by 10.152.113.131 with SMTP id iy3mr3148865lab.39.1326585202280; Sat, 14 Jan 2012 15:53:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.12.9 with HTTP; Sat, 14 Jan 2012 15:53:01 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Sat, 14 Jan 2012 18:53:01 -0500 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "dnsext@ietf.org" , "apps-discuss@ietf.org" , "draft-ietf-dnsext-xnamercode.all@tools.ietf.org" Subject: Re: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode 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 Jan 2012 23:53:24 -0000 Hi Murray, Thanks for the review, see responses below... On Thu, Jan 12, 2012 at 1:35 PM, Murray S. Kucherawy wr= ote: > I have been selected as the Applications Area Directorate reviewer for th= is > draft (for background on appsdir, please see > =A0http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirector= ate). > > Please resolve these comments along with any other Last Call comments you > may receive. Please wait for direction from your document shepherd or AD > before posting a new version of the draft. > > Document: draft-ietf-dnsext-xnamercode > Title: xNAME RCODE and Status Bits Clarification > Reviewer: Murray S. Kucherawy > Review Date: January 12, 2012 > IETF Last Call Date: N/A > IESG Telechat Date: N/A > > The draft clarifies prior ambiguities with respect to how a resolver is > supposed to report answer meta-data when resolving a name where the first > answer returned in a potential series of query-responses is actually a > pointer to another record.=A0 It is precise and concise. > > Summary: This draft is almost ready for publication as a Standards Track = RFC > but has a couple of issues that should be addressed before publication. > > Major Issues: > > Given that this is a potentially important clarification with > interoperability considerations, I believe this document should say it > updates at least RFC1035 (since its ambiguity is specifically called out)= , > and possibly RFC2672 and RFC2308.=A0 Make sure the Abstract also says thi= s > explicitly. No problem with me to make that addition for these three RFCs. > Minor Issues: > > In Section 1, =93There is a proposal for another redirection RR.=94=A0 Is= it > appropriate to make reference to that here?=A0 I don=92t know to which on= e > you=92re referring or what status it has, so the answer might be =93no=94= ; just > checking. This is right at the beginning of Section 1 as motivation for clarifying the situation and to make it clear that this document is intended to apply to future redirection RRs (unless, of course, the document specifying them says otherwise). I could make this a bit more definite by saying "There has been a proposal for another redirection RR that would combine the effects of both CNAME and DNAME." In fact, there is a renewed effort to start work on such an RR just in the past few days. > Section 2 identifies two status bits as part of this clarification > document.=A0 However, it also says explicitly that their definitions are > unchanged from the documents that introduced them.=A0 I=92m curious then = as to > why they are included in this document at all; that is, what clarificatio= n > is being provided?=A0 Unlike Section 3, any ambiguity about their use has= not > been identified here.=A0 If in fact there isn=92t any, I think this secti= on can > be removed.=A0 If you like, you can introduce references to and overviews= of > their definitions in a new subsection of Section 1, since you do talk abo= ut > them in Section 4. Well, the name of the document is "xNAME RCODE and Status Bits Clarification". I'm not sure why it would make that much difference to move Section 2 on status bits to a new subpart of Section 1. As you say, they are further discussed in Section 4. It seems to me that something can "clarify" with making any change. Given no objections in the DNSEXT WG to this material, I am inclined to leave it in. > Nits: > > In Section 3, the exclamation mark legitimately relays bewilderment here, > but unfortunately I think it should just be a period.=A0 Even better woul= d be > to end the sentence with =93says that some servers are implemented > differently=94 or suchlike. I kind of like it the way it is!!! But I'm OK with changing it to a period. > In Section 4, the clause =93if the following apply=94 should be amended b= y > adding =93all of=94 or =93one of=94 or something more specific. Sure, should be "all of". 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 From msk@cloudmark.com Sat Jan 14 20:39:07 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CB321F848B; Sat, 14 Jan 2012 20:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es-lq0UJYN1n; Sat, 14 Jan 2012 20:39:06 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 58B8A21F8486; Sat, 14 Jan 2012 20:39:02 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 14 Jan 2012 20:38:54 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 14 Jan 2012 20:39:01 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" , "draft-ietf-dnsext-xnamercode.all@tools.ietf.org" , "dnsext@ietf.org" Date: Sat, 14 Jan 2012 20:39:03 -0800 Thread-Topic: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode Thread-Index: AczTF7h+C89jFOt7SQi7vDe/yejG+gAJy4UA 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 04:39:07 -0000 Hi Donald, > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Saturday, January 14, 2012 3:53 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org; draft-ietf-dnsext-xnamercode.all@tools.ietf.or= g; dnsext@ietf.org > Subject: Re: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode >=20 > > Section 2 identifies two status bits as part of this clarification > > document.=A0 However, it also says explicitly that their definitions ar= e > > unchanged from the documents that introduced them.=A0 I'm curious then > > as to why they are included in this document at all; that is, what > > clarification is being provided?=A0 Unlike Section 3, any ambiguity > > about their use has not been identified here.=A0 If in fact there isn't > > any, I think this section can be removed.=A0 If you like, you can > > introduce references to and overviews of their definitions in a new > > subsection of Section 1, since you do talk about them in Section 4. >=20 > Well, the name of the document is "xNAME RCODE and Status Bits > Clarification". I'm not sure why it would make that much difference to > move Section 2 on status bits to a new subpart of Section 1. As you > say, they are further discussed in Section 4. It seems to me that > something can "clarify" with making any change. Given no objections in > the DNSEXT WG to this material, I am inclined to leave it in. My point is not so much the position of the text as its purpose. You're ri= ght of course about the title, but it's not clear to me what is being clari= fied with respect to the status bits, since you explicitly say they are unc= hanged from their definitions. That is, it seems to me deleting Section 2 = entirely wouldn't remove anything from the document. If the purpose is merely to restate their definitions or refer to them so t= he Section 4 text is more meaningful, then informative references to the pl= aces where those are when you talk about them in Section 4 seems simpler th= an what's there now. -MSK From internet-drafts@ietf.org Sun Jan 15 14:45:10 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9D421F84D8; Sun, 15 Jan 2012 14:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJgpNkFr3mfz; Sun, 15 Jan 2012 14:45:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128BE21F8487; Sun, 15 Jan 2012 14:44:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120115224456.18979.37392.idtracker@ietfa.amsl.com> Date: Sun, 15 Jan 2012 14:44:56 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-ecdsa-03.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: Sun, 15 Jan 2012 22:45:10 -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 : Elliptic Curve DSA for DNSSEC Author(s) : Paul Hoffman Wouter Wijngaards Filename : draft-ietf-dnsext-ecdsa-03.txt Pages : 8 Date : 2012-01-15 This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-03.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-ecdsa-03.txt From wouter@nlnetlabs.nl Mon Jan 16 01:47:00 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1FF21F858F for ; Mon, 16 Jan 2012 01:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kB1M0gNYtja0 for ; Mon, 16 Jan 2012 01:46:59 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB3021F858E for ; Mon, 16 Jan 2012 01:46:59 -0800 (PST) Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q0G9kmPP058012 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 16 Jan 2012 10:46:57 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1326707218; bh=k9HdKrZc4JhrZ+1YmWIwVlphQcnT57ebJEJ/U4SjNE8=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gSM1OQ9TSKhap7KMwhHlsn605D+qJnhERAaGVaEJu13q1vXPYGOmJ8lbgO8wMKaqP 8jZ+yR4bGHUh14ZYKFOBzsjljx4o8fQZSDpooakV5c45NFf0JuvrD6JI9MkudgBR4v R8MktjRNZDvvtZrsvQxaaTmwsGd6SQJnLXX1mFaI= Message-ID: <4F13F208.8010908@nlnetlabs.nl> Date: Mon, 16 Jan 2012 10:46:48 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120113225013.642F21B13171@drugs.dv.isc.org> In-Reply-To: <20120113225013.642F21B13171@drugs.dv.isc.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 16 Jan 2012 10:46:57 +0100 (CET) Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14) 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 Jan 2012 09:47:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, On 01/13/2012 11:50 PM, Mark Andrews wrote: >>> I don't recall seeing much discussion of the below. =A0As doc >>> editor, I w= >> ould >>> like to hear an extra voice or three chime in before I fix >>> this. >>> >>> As I understand Ed's message, the (signer) name in an RRSIG >>> does need to = >> be >>> downcased. =A0The next name in a NSEC RR does NOT need to be >>> downcased. = >> =A0Is >>> that right? >> +1. Sometime back there was an email thread (which I can't locate >> now) where the signature verification failed if you don't >> downcase for something in .US zone. > > named downcases the RRSIG's Signer's Name named does not downcase > NSEC's Next Domain Name. unbound does not downcase RRSIG signername and does not downcase NSEC nextdomain name for DNSSEC validation. ldns rr canonicalisation does not downcase RRSIG signername and NSEC nextdomain. So, this is for ldns-signzone and verify. opendnssec produces lowercase signernames in its RRSIGs, and thus it does not matter if they are downcased or not (for the RRSIGs produced by the opendnssec signer). It started with HINFO, where, today, the rdata is not downcased by unbound, ldns. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPE/IDAAoJEJ9vHC1+BF+NVLIP/jnbdomYSCqaBF6tIuxofYDr 7oXI88Yb1yzrmW25rWmCQzZYQUknzGAvgxKzFzD3deZPiNyPKl9I+H42872U36k0 9pjsyqQ0QEwipUdl5ty+ieQrgZUGlsjLLevANeC2nB1Ic8jXsZ4w2KH74NRgDqNC j+Y1vKUz8D1S8SvqoAPgScRsLTehR51JQ78Hb7UnBZ4e2qwrBygwaVOGrMM2n0aY sYH4pI+3/VaB4JnSgxwp5SrLKRm8G09af1Rav6P/lMslAmS3Hksi21N8fNAG32n0 JwvhEZl9rT/oSjkF0FpxcN1+//yOFVNHNJxWFi7PxykNsGPfDaj6xWuN/xTj6r05 sIyT5idFS59asPXpORTK1AYLbLNWE6WMDHmTX/VWEF1dU/9VJCiBckUzOLl68+vs fX7BAot5oEHX+s/Tk2md3AAM8XOXtntaZm1E8sZJ19hcBriquy675VEs76JD20QM zoRqk+tAhviYwFb3t4aQJonP1WwnnebEMzc4nuZFFwnIeNJJy9TZU5u4oaMt/PQT NsjKcHfjSmInyOmg0Jnd6lJp6p2flht66S0JnSb2ed+KZGG3w0IPKTN/9nS5AoaD pAPoUyNrC1biw5vRy+kr5FO9ll+pIbJgLvKH93HYi7hSccxGlYdz0hFq5XEanFf7 Qrdx5BWFPHgaS17ciHr7 =TrdF -----END PGP SIGNATURE----- From wouter@nlnetlabs.nl Mon Jan 16 06:35:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F87021F85F3 for ; Mon, 16 Jan 2012 06:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3O6TIhdpkVJ for ; Mon, 16 Jan 2012 06:35:14 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BCF21F85F1 for ; Mon, 16 Jan 2012 06:35:13 -0800 (PST) Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q0GEZBxN014405 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 16 Jan 2012 15:35:11 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1326724512; bh=13lSyqPmfX+JU2QKBF9zo6GEkAhDtFk18v0ce8GwZm0=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HkkIET8RzUxC4LaKEf9SiHwlsA2vhla2t5gHqiQPI5Ryl/xyBRa3nNxtcFEIhNOo3 fuD73dhh3tD1tbV81e5cYGPIOjtJWL90Qug/kBELnkM2C+8wcspSQ82N2eQZjulLOg CDXd+xRVu3n+KiZoaAl62VoqecKwBVo0HEkk9OTQ= Message-ID: <4F14359F.8050206@nlnetlabs.nl> Date: Mon, 16 Jan 2012 15:35:11 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120113225013.642F21B13171@drugs.dv.isc.org> <4F13F208.8010908@nlnetlabs.nl> In-Reply-To: <4F13F208.8010908@nlnetlabs.nl> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 16 Jan 2012 15:35:11 +0100 (CET) Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14) 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 Jan 2012 14:35:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Sam, Just to clarify my previous mail: what we implement is RFC3755. This states no downcasing in the rdata of NSEC and RRSIG. To see how we came to this implementation I searched through mail from 2007. I found that the reason for this is that we first implemented RFC4034, but that typecodelist in 4034 contained errors (double HINFO, includes NSEC and RRSIG in a copy-paste-rename-mistake from RFC2535 or something like that). This brought to light differences in implementations from before RFC4034 and after RFC4034. Because of this we changed to implement RFC3755 and in dnssec-bis-updates-06 it is then listed this as something to fix in RFC4034, and it states the RFC3755 rules. This is there until -16 (last week) where it changes. Downcasing is not necessary in NSEC and RRSIG, downcase before signature verify and create is only needed in case dname-compression-and-decompression has removed upper-lowercase differences. The domain names in the rdata of NSEC and RRSIG are not compressed, and thus case is preserved. So, a downcase operation is not needed (in principle). So, currently we stay with RFC3755, because we want to implement standards RFCs, and not drafts if possible. RFC3755 is obsoleted by RFC4034, but as already discussed on namedroppers, its typecodelist was erroneous. And therefore we ignored that list in RFC4034. Thus our implementation matches the dnssec-bis-updates draft versions -06 to -15 in this respect. Regardless of the outcome of this interoperability problem, we will implement RFCs and thus the RFC that comes out of dnssec-bis-updates, whether that downcases both(4034), neither(3755) or something else(draft-16). Best regards, Wouter On 01/16/2012 10:46 AM, W.C.A. Wijngaards wrote: > Hi Mark, > > On 01/13/2012 11:50 PM, Mark Andrews wrote: >>>> I don't recall seeing much discussion of the below. =A0As >>>> doc editor, I w= >>> ould >>>> like to hear an extra voice or three chime in before I fix >>>> this. >>>> >>>> As I understand Ed's message, the (signer) name in an RRSIG >>>> does need to = >>> be >>>> downcased. =A0The next name in a NSEC RR does NOT need to be >>>> downcased. = >>> =A0Is >>>> that right? >>> +1. Sometime back there was an email thread (which I can't >>> locate now) where the signature verification failed if you >>> don't downcase for something in .US zone. > >> named downcases the RRSIG's Signer's Name named does not >> downcase NSEC's Next Domain Name. > > unbound does not downcase RRSIG signername and does not downcase > NSEC nextdomain name for DNSSEC validation. > > ldns rr canonicalisation does not downcase RRSIG signername and > NSEC nextdomain. So, this is for ldns-signzone and verify. > > opendnssec produces lowercase signernames in its RRSIGs, and thus > it does not matter if they are downcased or not (for the RRSIGs > produced by the opendnssec signer). > > It started with HINFO, where, today, the rdata is not downcased by > unbound, ldns. > > Best regards, Wouter > _______________________________________________ dnsext mailing > list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPFDWfAAoJEJ9vHC1+BF+NZL4P/Rrs1hl9q02hlU8c83M1BgxT v3KPpVQ2369LpY5Vr/0SOUu5W8l8J76pcpkkameKg4PKfW2nzrdUVKD7i/KBmC3h 9C9pDzLyamXofG7oxCFAFXOYYJkJ4tXjr31SHfhxsb0YxfvuZE80ZZiOk5+3IhJF kWQnUOoIMQMXttCLW6ecHk/i7JhE6gn/7+P8uw3ElunKXqZSleZ42cKIx5WHK+Wg 0VNOd3SctuHw41HrtN9O0na7HN/FQr38Gq3tE5+UtFxv1h7hLs+nH2X1Zk2gM9bx 5LXpOdMyvuDlHr7jvyPf4v6JSP2XhbRENe3DNonixK41TQ4laDlHbmbWsFQyjZYD +CN8vO+w4Mh0TeB6QLEfQAO922l4mR7ts8FwgDYCl0nejoNUU99bb1VVY/6Laa22 jd8CwcCYqI/pvxcuuTf/kaqOryizyJ5oBFgDSlaKr42AHqmG6vVtXZoamr1Zi248 UjHDe2bYnY+uf3OpfVvI3Smbs6vFoBY0Xkj4RMAlupPpNvEXeJwtx+k1TQ/E9f7n Yh/QMz32Q86TTXR33/9HDIJvF6e7b2WLMGkOUZVTMMzqI3EZiPg2mDbzAhcs1j1G tgIweyfpSwYWhykPIIYL0FHCxHsqF2dm59wFn2Bo0B9fdTdoVB0D2iW+9ctnrZbl g/mH7UFd4xsNImX2ZNEG =n3EK -----END PGP SIGNATURE----- From weiler@watson.org Mon Jan 16 07:04:53 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29EF21F8679 for ; Mon, 16 Jan 2012 07:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nfr86lYBgKbw for ; Mon, 16 Jan 2012 07:04:52 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 75D6721F8613 for ; Mon, 16 Jan 2012 07:04:52 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q0GF4pAp094095; Mon, 16 Jan 2012 10:04:51 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q0GF4piQ094090; Mon, 16 Jan 2012 10:04:51 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 16 Jan 2012 10:04:51 -0500 (EST) From: Samuel Weiler To: "W.C.A. Wijngaards" In-Reply-To: <4F14359F.8050206@nlnetlabs.nl> Message-ID: References: <20120113225013.642F21B13171@drugs.dv.isc.org> <4F13F208.8010908@nlnetlabs.nl> <4F14359F.8050206@nlnetlabs.nl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 16 Jan 2012 10:04:51 -0500 (EST) Cc: dnsext@ietf.org Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14) 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 Jan 2012 15:04:53 -0000 Thank you for the history. Going forward, what's the best thing to do in the interest of interoperability? It may be worth asking not only what signers do but also what existing validators do. If we've only seen problems with this in the wild once (perhaps?) then there may be an ugly but interoperable answer we can document for the future. -- Sam On Mon, 16 Jan 2012, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Sam, > > Just to clarify my previous mail: what we implement is RFC3755. This > states no downcasing in the rdata of NSEC and RRSIG. > > To see how we came to this implementation I searched through mail from > 2007. I found that the reason for this is that we first implemented > RFC4034, but that typecodelist in 4034 contained errors (double HINFO, > includes NSEC and RRSIG in a copy-paste-rename-mistake from RFC2535 or > something like that). This brought to light differences in > implementations from before RFC4034 and after RFC4034. Because of > this we changed to implement RFC3755 and in dnssec-bis-updates-06 it > is then listed this as something to fix in RFC4034, and it states the > RFC3755 rules. This is there until -16 (last week) where it changes. > > Downcasing is not necessary in NSEC and RRSIG, downcase before > signature verify and create is only needed in case > dname-compression-and-decompression has removed upper-lowercase > differences. The domain names in the rdata of NSEC and RRSIG are not > compressed, and thus case is preserved. So, a downcase operation is > not needed (in principle). > > So, currently we stay with RFC3755, because we want to implement > standards RFCs, and not drafts if possible. RFC3755 is obsoleted by > RFC4034, but as already discussed on namedroppers, its typecodelist > was erroneous. And therefore we ignored that list in RFC4034. Thus > our implementation matches the dnssec-bis-updates draft versions -06 > to -15 in this respect. Regardless of the outcome of this > interoperability problem, we will implement RFCs and thus the RFC that > comes out of dnssec-bis-updates, whether that downcases both(4034), > neither(3755) or something else(draft-16). > > Best regards, > Wouter > > On 01/16/2012 10:46 AM, W.C.A. Wijngaards wrote: >> Hi Mark, >> >> On 01/13/2012 11:50 PM, Mark Andrews wrote: >>>>> I don't recall seeing much discussion of the below. =A0As >>>>> doc editor, I w= >>>> ould >>>>> like to hear an extra voice or three chime in before I fix >>>>> this. >>>>> >>>>> As I understand Ed's message, the (signer) name in an RRSIG >>>>> does need to = >>>> be >>>>> downcased. =A0The next name in a NSEC RR does NOT need to be >>>>> downcased. = >>>> =A0Is >>>>> that right? >>>> +1. Sometime back there was an email thread (which I can't >>>> locate now) where the signature verification failed if you >>>> don't downcase for something in .US zone. >> >>> named downcases the RRSIG's Signer's Name named does not >>> downcase NSEC's Next Domain Name. >> >> unbound does not downcase RRSIG signername and does not downcase >> NSEC nextdomain name for DNSSEC validation. >> >> ldns rr canonicalisation does not downcase RRSIG signername and >> NSEC nextdomain. So, this is for ldns-signzone and verify. >> >> opendnssec produces lowercase signernames in its RRSIGs, and thus >> it does not matter if they are downcased or not (for the RRSIGs >> produced by the opendnssec signer). >> >> It started with HINFO, where, today, the rdata is not downcased by >> unbound, ldns. >> >> Best regards, Wouter >> _______________________________________________ dnsext mailing >> list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPFDWfAAoJEJ9vHC1+BF+NZL4P/Rrs1hl9q02hlU8c83M1BgxT > v3KPpVQ2369LpY5Vr/0SOUu5W8l8J76pcpkkameKg4PKfW2nzrdUVKD7i/KBmC3h > 9C9pDzLyamXofG7oxCFAFXOYYJkJ4tXjr31SHfhxsb0YxfvuZE80ZZiOk5+3IhJF > kWQnUOoIMQMXttCLW6ecHk/i7JhE6gn/7+P8uw3ElunKXqZSleZ42cKIx5WHK+Wg > 0VNOd3SctuHw41HrtN9O0na7HN/FQr38Gq3tE5+UtFxv1h7hLs+nH2X1Zk2gM9bx > 5LXpOdMyvuDlHr7jvyPf4v6JSP2XhbRENe3DNonixK41TQ4laDlHbmbWsFQyjZYD > +CN8vO+w4Mh0TeB6QLEfQAO922l4mR7ts8FwgDYCl0nejoNUU99bb1VVY/6Laa22 > jd8CwcCYqI/pvxcuuTf/kaqOryizyJ5oBFgDSlaKr42AHqmG6vVtXZoamr1Zi248 > UjHDe2bYnY+uf3OpfVvI3Smbs6vFoBY0Xkj4RMAlupPpNvEXeJwtx+k1TQ/E9f7n > Yh/QMz32Q86TTXR33/9HDIJvF6e7b2WLMGkOUZVTMMzqI3EZiPg2mDbzAhcs1j1G > tgIweyfpSwYWhykPIIYL0FHCxHsqF2dm59wFn2Bo0B9fdTdoVB0D2iW+9ctnrZbl > g/mH7UFd4xsNImX2ZNEG > =n3EK > -----END PGP SIGNATURE----- > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From marka@isc.org Mon Jan 16 14:57:17 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC7821F867A for ; Mon, 16 Jan 2012 14:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+ZhbZxS8D3D for ; Mon, 16 Jan 2012 14:57:16 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D21FA21F8605 for ; Mon, 16 Jan 2012 14:57:15 -0800 (PST) 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 492135F98A2; Mon, 16 Jan 2012 22:56:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7db4:152d:79c6:de25]) (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 46C2B216C6D; Mon, 16 Jan 2012 22:56:51 +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 C09331B780C2; Tue, 17 Jan 2012 09:56:48 +1100 (EST) To: Samuel Weiler From: Mark Andrews References: <20120113225013.642F21B13171@drugs.dv.isc.org> <4F13F208.8010908@nlnetlabs.nl> <4F14359F.8050206@nlnetlabs.nl> In-reply-to: Your message of "Mon, 16 Jan 2012 10:04:51 CDT." Date: Tue, 17 Jan 2012 09:56:48 +1100 Message-Id: <20120116225648.C09331B780C2@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14) 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 Jan 2012 22:57:17 -0000 In message , Samuel Weil er writes: > Thank you for the history. Going forward, what's the best thing to do > in the interest of interoperability? > > It may be worth asking not only what signers do but also what existing > validators do. If we've only seen problems with this in the wild once > (perhaps?) then there may be an ugly but interoperable answer we can > document for the future. > > -- Sam If we emit downcased "Signer Name"s then it does not matter what the validator does. To the best of my knowledge no one uses domain name compression on these names so as long as the signer only uses and emits a downcased version of the name it will interoperate regardless of what the validator does. i.e. Build the RRSIG with a downcased signer name rather than downcasing signer name when adding it to the digest. If you are signing with "MiXeD.ExAmPlE" then the signer name in the RRSIG is "mixed.example". Unfortunately I missed removing the downcase step for RRSIGs when I did the type code roll fixes years ago. > On Mon, 16 Jan 2012, W.C.A. Wijngaards wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi Sam, > > > > Just to clarify my previous mail: what we implement is RFC3755. This > > states no downcasing in the rdata of NSEC and RRSIG. > > > > To see how we came to this implementation I searched through mail from > > 2007. I found that the reason for this is that we first implemented > > RFC4034, but that typecodelist in 4034 contained errors (double HINFO, > > includes NSEC and RRSIG in a copy-paste-rename-mistake from RFC2535 or > > something like that). This brought to light differences in > > implementations from before RFC4034 and after RFC4034. Because of > > this we changed to implement RFC3755 and in dnssec-bis-updates-06 it > > is then listed this as something to fix in RFC4034, and it states the > > RFC3755 rules. This is there until -16 (last week) where it changes. > > > > Downcasing is not necessary in NSEC and RRSIG, downcase before > > signature verify and create is only needed in case > > dname-compression-and-decompression has removed upper-lowercase > > differences. The domain names in the rdata of NSEC and RRSIG are not > > compressed, and thus case is preserved. So, a downcase operation is > > not needed (in principle). > > > > So, currently we stay with RFC3755, because we want to implement > > standards RFCs, and not drafts if possible. RFC3755 is obsoleted by > > RFC4034, but as already discussed on namedroppers, its typecodelist > > was erroneous. And therefore we ignored that list in RFC4034. Thus > > our implementation matches the dnssec-bis-updates draft versions -06 > > to -15 in this respect. Regardless of the outcome of this > > interoperability problem, we will implement RFCs and thus the RFC that > > comes out of dnssec-bis-updates, whether that downcases both(4034), > > neither(3755) or something else(draft-16). > > > > Best regards, > > Wouter > > > > On 01/16/2012 10:46 AM, W.C.A. Wijngaards wrote: > >> Hi Mark, > >> > >> On 01/13/2012 11:50 PM, Mark Andrews wrote: > >>>>> I don't recall seeing much discussion of the below. =A0As > >>>>> doc editor, I w= > >>>> ould > >>>>> like to hear an extra voice or three chime in before I fix > >>>>> this. > >>>>> > >>>>> As I understand Ed's message, the (signer) name in an RRSIG > >>>>> does need to = > >>>> be > >>>>> downcased. =A0The next name in a NSEC RR does NOT need to be > >>>>> downcased. = > >>>> =A0Is > >>>>> that right? > >>>> +1. Sometime back there was an email thread (which I can't > >>>> locate now) where the signature verification failed if you > >>>> don't downcase for something in .US zone. > >> > >>> named downcases the RRSIG's Signer's Name named does not > >>> downcase NSEC's Next Domain Name. > >> > >> unbound does not downcase RRSIG signername and does not downcase > >> NSEC nextdomain name for DNSSEC validation. > >> > >> ldns rr canonicalisation does not downcase RRSIG signername and > >> NSEC nextdomain. So, this is for ldns-signzone and verify. > >> > >> opendnssec produces lowercase signernames in its RRSIGs, and thus > >> it does not matter if they are downcased or not (for the RRSIGs > >> produced by the opendnssec signer). > >> > >> It started with HINFO, where, today, the rdata is not downcased by > >> unbound, ldns. > >> > >> Best regards, Wouter > >> _______________________________________________ dnsext mailing > >> list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.11 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > iQIcBAEBAgAGBQJPFDWfAAoJEJ9vHC1+BF+NZL4P/Rrs1hl9q02hlU8c83M1BgxT > > v3KPpVQ2369LpY5Vr/0SOUu5W8l8J76pcpkkameKg4PKfW2nzrdUVKD7i/KBmC3h > > 9C9pDzLyamXofG7oxCFAFXOYYJkJ4tXjr31SHfhxsb0YxfvuZE80ZZiOk5+3IhJF > > kWQnUOoIMQMXttCLW6ecHk/i7JhE6gn/7+P8uw3ElunKXqZSleZ42cKIx5WHK+Wg > > 0VNOd3SctuHw41HrtN9O0na7HN/FQr38Gq3tE5+UtFxv1h7hLs+nH2X1Zk2gM9bx > > 5LXpOdMyvuDlHr7jvyPf4v6JSP2XhbRENe3DNonixK41TQ4laDlHbmbWsFQyjZYD > > +CN8vO+w4Mh0TeB6QLEfQAO922l4mR7ts8FwgDYCl0nejoNUU99bb1VVY/6Laa22 > > jd8CwcCYqI/pvxcuuTf/kaqOryizyJ5oBFgDSlaKr42AHqmG6vVtXZoamr1Zi248 > > UjHDe2bYnY+uf3OpfVvI3Smbs6vFoBY0Xkj4RMAlupPpNvEXeJwtx+k1TQ/E9f7n > > Yh/QMz32Q86TTXR33/9HDIJvF6e7b2WLMGkOUZVTMMzqI3EZiPg2mDbzAhcs1j1G > > tgIweyfpSwYWhykPIIYL0FHCxHsqF2dm59wFn2Bo0B9fdTdoVB0D2iW+9ctnrZbl > > g/mH7UFd4xsNImX2ZNEG > > =n3EK > > -----END PGP SIGNATURE----- > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Jan 16 20:06:41 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D09E1F0C38 for ; Mon, 16 Jan 2012 20:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fmGV5bApuAd for ; Mon, 16 Jan 2012 20:06:41 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A4D321F0C35 for ; Mon, 16 Jan 2012 20:06:40 -0800 (PST) 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 83378C9463; Tue, 17 Jan 2012 04:06:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7db4:152d:79c6:de25]) (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 3EA00216C6A; Tue, 17 Jan 2012 04:06:24 +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 CB9B01B7B433; Tue, 17 Jan 2012 15:06:18 +1100 (EST) To: "W.C.A. Wijngaards" From: Mark Andrews References: <20120113225013.642F21B13171@drugs.dv.isc.org> <4F13F208.8010908@nlnetlabs.nl> In-reply-to: Your message of "Mon, 16 Jan 2012 10:46:48 BST." <4F13F208.8010908@nlnetlabs.nl> Date: Tue, 17 Jan 2012 15:06:18 +1100 Message-Id: <20120117040618.CB9B01B7B433@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14) 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 Jan 2012 04:06:41 -0000 In message <4F13F208.8010908@nlnetlabs.nl>, "W.C.A. Wijngaards" writes: > Hi Mark, > > On 01/13/2012 11:50 PM, Mark Andrews wrote: > >>> I don't recall seeing much discussion of the below. =A0As doc > >>> editor, I would > >>> like to hear an extra voice or three chime in before I fix > >>> this. > >>> > >>> As I understand Ed's message, the (signer) name in an RRSIG > >>> does need to be downcased. > >>> The next name in a NSEC RR does NOT need to be downcased. Is > >>> that right? > >> +1. Sometime back there was an email thread (which I can't locate > >> now) where the signature verification failed if you don't > >> downcase for something in .US zone. > > > > named downcases the RRSIG's Signer's Name named does not downcase > > NSEC's Next Domain Name. > > unbound does not downcase RRSIG signername and does not downcase NSEC > nextdomain name for DNSSEC validation. Then how does it validate .US, .CO and .BIZ as the signer in the RRSIG is in upper case? If I disable down casing I get validation failures. 17-Jan-2012 14:48:21.099 validating @0x101101c00: US DNSKEY: no valid signature found 17-Jan-2012 14:48:22.062 error (insecurity proof failed) resolving 'US/DNSKEY/IN': 156.154.127.70#53 17-Jan-2012 14:48:22.430 validating @0x101101c00: US DNSKEY: no valid signature found 17-Jan-2012 14:48:22.430 error (no valid RRSIG) resolving 'US/DNSKEY/IN': 156.154.126.70#53 17-Jan-2012 14:48:22.735 validating @0x101101c00: US DNSKEY: no valid signature found 17-Jan-2012 14:48:22.735 error (no valid RRSIG) resolving 'US/DNSKEY/IN': 209.173.58.70#53 17-Jan-2012 14:48:23.963 validating @0x101112e00: US DNSKEY: no valid signature found 17-Jan-2012 14:48:23.963 error (no valid RRSIG) resolving 'US/DNSKEY/IN': 156.154.125.70#53 17-Jan-2012 14:48:24.273 validating @0x101112e00: US DNSKEY: no valid signature found 17-Jan-2012 14:48:24.273 error (no valid RRSIG) resolving 'US/DNSKEY/IN': 156.154.124.70#53 17-Jan-2012 14:48:25.502 validating @0x101100c00: US DNSKEY: no valid signature found 17-Jan-2012 14:48:25.502 error (no valid RRSIG) resolving 'US/DNSKEY/IN': 156.154.128.70#53 > ldns rr canonicalisation does not downcase RRSIG signername and NSEC > nextdomain. So, this is for ldns-signzone and verify. > > opendnssec produces lowercase signernames in its RRSIGs, and thus it > does not matter if they are downcased or not (for the RRSIGs produced > by the opendnssec signer). > > It started with HINFO, where, today, the rdata is not downcased by > unbound, ldns. > > Best regards, > Wouter It would be easy enough to have the validation routines try "as is" then "lowercase" for backwards compatibility with the expectation that we can look to removing backwards compatibility hacks Jan 1, 2020. Similarly we would lowercase the signer when generating the RRSIG and stop doing that around 2020. That's 8 years to remove the old validators. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From wouter@nlnetlabs.nl Tue Jan 17 01:04:00 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5021C21F85D5 for ; Tue, 17 Jan 2012 01:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIpnj-nxWE+w for ; Tue, 17 Jan 2012 01:03:54 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA0621F85C0 for ; Tue, 17 Jan 2012 01:03:54 -0800 (PST) Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q0H93pPt018652 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 17 Jan 2012 10:03:52 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1326791033; bh=iA4K/tq01wiTU7ondxnXwjtkfsmR/XRRBdNUOWgQBR4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=VhPfgQJNIzK7xK9xoDzai/9zsAspo4G02FyY9h7S8D4fBzHj3hJn3nRtl+jwMFpyv 0pMmOB/LZU+k+0hoBs35Bd7oIRz9dkBn6rD/zVI9dTLzceixUgJYepzmA3Xi4EGkCu 2VWy0mzfpWKzJaBIBy2AsFryua9nms7yeMDQTwjY= Message-ID: <4F153977.8080906@nlnetlabs.nl> Date: Tue, 17 Jan 2012 10:03:51 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Mark Andrews References: <20120113225013.642F21B13171@drugs.dv.isc.org> <4F13F208.8010908@nlnetlabs.nl> <20120117040618.CB9B01B7B433@drugs.dv.isc.org> In-Reply-To: <20120117040618.CB9B01B7B433@drugs.dv.isc.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 17 Jan 2012 10:03:52 +0100 (CET) Cc: dnsext@ietf.org Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14) 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 Jan 2012 09:04:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, On 01/17/2012 05:06 AM, Mark Andrews wrote: >>> named downcases the RRSIG's Signer's Name named does not >>> downcase NSEC's Next Domain Name. >> >> unbound does not downcase RRSIG signername and does not downcase >> NSEC nextdomain name for DNSSEC validation. > > Then how does it validate .US, .CO and .BIZ as the signer in the > RRSIG is in upper case? If I disable down casing I get validation > failures. I was wrong! Looked into the wrong code (there is a (mostly harmless) bug). Unbound downcases the RRSIG rdata. Unbound does not downcase the NSEC rdata. So, the deployed Unbound implements -16, and is compatible with BIND. Given this is the deployed code, the other arguments are perhaps moot. Hence that US, CO and BIZ verify. Thanks for that test. > It would be easy enough to have the validation routines try "as > is" then "lowercase" for backwards compatibility with the > expectation that we can look to removing backwards compatibility > hacks Jan 1, 2020. My apologies for wrong information - unbound contains a bug on this topic - but unbound indeed downcases the RRSIG signer name. Hence very strong workarounds are not necessary. > Similarly we would lowercase the signer when generating the RRSIG > and stop doing that around 2020. That's 8 years to remove the old > validators. lowercase the signer when generating the RRSIG is a bit on the strict generation of data perhaps. Otherwise US. seems to work in practice. So, in this situation I would recommend keeping -16 as is, and not changing the situation because of deployed code and signed zones (US, CO, BIZ). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPFTl3AAoJEJ9vHC1+BF+NVZAQAJ0rVoG3RIpT6HCFOCw1Humh ALOb5eGRAgGzTJw4p62/oZfKcM5Qm+gm4Y4y+X9AeP/N7yinmTtmmhXCoMLTGiN7 jV0cbK7/W1ZMKiEiRTFdne33SCufIz/madkM3S8/X8dX9zQ39qMfTlj63EUJXUah dMCKEG00QwKmu6KQbaifsYARzArJpo/8Ia1dVlcuPRUqx2p6xkjJ3GHSSahPREs2 6E/WzdzXviws+EOcswdbweROAL1OS3BnD/RdNyfFIFbwKu6SRE4MMi/4HwZJ0H55 PfmQCa05enmV700tnN258t3RBKpLjroApzF12PBMM5g2HDm9Xdo+2QYqc909iPle GfEEM1w3Xbt+eH01kyij4GhZOejmq6lvvED25a8dcdt6ECvfCmU06chrX/RvpKhu UYluYF62URJaxjxIOz2gAqK9nbG9n0rfQ+DMJedGvqIIbmm87RyFKC1WM4dTBQ4/ XQJ9y2lVaIDtZyuQRREtUCrMI4RUOhuce0LEBfdcKskfzvNWMCEM2NturbiaPVBy YlaEWa7krgJeEJ3aYobv4gBAJ/+nv+IV02e/nH2KSjruTrts2h327XRKqlE7IG/P 8D3mGJLUwQCjcxcJ1KmTFi1rSIMsC+EXW1vRSZfqroyqU9qso48Ujf3pZnqlt+Ts MaQTmg2JYRo0QuZ4R49U =at3P -----END PGP SIGNATURE----- From d3e3e3@gmail.com Tue Jan 17 05:44:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B4B21F86B2; Tue, 17 Jan 2012 05:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.357 X-Spam-Level: X-Spam-Status: No, score=-104.357 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ohZqBpOGl7B; Tue, 17 Jan 2012 05:44:02 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F59E21F86AF; Tue, 17 Jan 2012 05:44:01 -0800 (PST) Received: by lagv3 with SMTP id v3so2616910lag.31 for ; Tue, 17 Jan 2012 05:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=UeGN0S82pyweof8Nwo4Sq863ukPKZ9wbqOCPv+o4dNc=; b=m6FlbMZ3mIYnItINSCldGqFUvvB8NKlVm5aaDFSIxWK0jKkEsIbizIZsHpQj7qrsLL sHXvpBVfrOfU+6VWP6i0CzntlIUhB8A4QLdgOZcbJoXhXNNANOoeTbI7iBfJHACRO6ge HStf6hZqr0WDkuXRiMz+tb4GAwFYBU1nI7WvU= Received: by 10.112.48.193 with SMTP id o1mr4240087lbn.1.1326807840372; Tue, 17 Jan 2012 05:44:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.100.131 with HTTP; Tue, 17 Jan 2012 05:43:39 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Tue, 17 Jan 2012 08:43:39 -0500 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dnsext@ietf.org" , "apps-discuss@ietf.org" , "draft-ietf-dnsext-xnamercode.all@tools.ietf.org" Subject: Re: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode 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 Jan 2012 13:44:02 -0000 Hi, On Sat, Jan 14, 2012 at 11:39 PM, Murray S. Kucherawy w= rote: > Hi Donald, > >> -----Original Message----- >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] >> Sent: Saturday, January 14, 2012 3:53 PM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org; draft-ietf-dnsext-xnamercode.all@tools.ietf.o= rg; dnsext@ietf.org >> Subject: Re: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode >> >> > Section 2 identifies two status bits as part of this clarification >> > document.=A0 However, it also says explicitly that their definitions a= re >> > unchanged from the documents that introduced them.=A0 I'm curious then >> > as to why they are included in this document at all; that is, what >> > clarification is being provided?=A0 Unlike Section 3, any ambiguity >> > about their use has not been identified here.=A0 If in fact there isn'= t >> > any, I think this section can be removed.=A0 If you like, you can >> > introduce references to and overviews of their definitions in a new >> > subsection of Section 1, since you do talk about them in Section 4. >> >> Well, the name of the document is "xNAME RCODE and Status Bits >> Clarification". I'm not sure why it would make that much difference to >> move Section 2 on status bits to a new subpart of Section 1. As you >> say, they are further discussed in Section 4. It seems to me that >> something can "clarify" with making any change. Given no objections in >> the DNSEXT WG to this material, I am inclined to leave it in. > > My point is not so much the position of the text as its purpose. =A0You'r= e right of course about the title, but it's not clear to me what is being c= larified with respect to the status bits, since you explicitly say they are= unchanged from their definitions. =A0That is, it seems to me deleting Sect= ion 2 entirely wouldn't remove anything from the document. > > If the purpose is merely to restate their definitions or refer to them so= the Section 4 text is more meaningful, then informative references to the = places where those are when you talk about them in Section 4 seems simpler = than what's there now. The purpose is to clarify as the title says. I do not accept your position that text which does not change something therefore cannot be a clarification. 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 > -MSK From Ed.Lewis@neustar.biz Tue Jan 17 07:06:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6ED521F851B for ; Tue, 17 Jan 2012 07:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.092 X-Spam-Level: X-Spam-Status: No, score=-104.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3J9YphpyOCZ for ; Tue, 17 Jan 2012 07:06:11 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1409E21F851A for ; Tue, 17 Jan 2012 07:06:10 -0800 (PST) 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 q0HF5s2p085747; Tue, 17 Jan 2012 10:06:06 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.137] by Work-Laptop-2.local (PGP Universal service); Tue, 17 Jan 2012 10:06:09 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 17 Jan 2012 10:06:09 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120113225013.642F21B13171@drugs.dv.isc.org> <4F13F208.8010908@nlnetlabs.nl> <4F14359F.8050206@nlnetlabs.nl> Date: Tue, 17 Jan 2012 10:02:29 -0500 To: Samuel Weiler From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14) 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 Jan 2012 15:06:11 -0000 At 10:04 -0500 1/16/12, Samuel Weiler wrote: >Thank you for the history. Going forward, what's the best thing to >do in the interest of interoperability? > >It may be worth asking not only what signers do but also what >existing validators do. If we've only seen problems with this in >the wild once (perhaps?) then there may be an ugly but interoperable >answer we can document for the future. > (Adding to some off-list messages, a shortened version of what I've written:) Downcase RRSIG, not NSEC. That includes publishing the RRSIG with the downcased name in the RDATA. From what I've seen, all known signers do that, regardless of what any spec says, hence no validators are tripped up by it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Vote for the word of the day: "Papa"razzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate "red tape" From ogud@ogud.com Tue Jan 17 10:44:22 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68A111E8089 for ; Tue, 17 Jan 2012 10:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6gv1QbxzHhu for ; Tue, 17 Jan 2012 10:44:22 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 548B011E8073 for ; Tue, 17 Jan 2012 10:44:22 -0800 (PST) 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 q0HIiLTr087527 for ; Tue, 17 Jan 2012 13:44:21 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F15C183.2090001@ogud.com> Date: Tue, 17 Jan 2012 13:44:19 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 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.72 on 10.20.30.4 Subject: [dnsext] DNSEXT at IETF@83 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 Jan 2012 18:44:23 -0000 We have requested a short session at the Paris meeting. Current Agenda, a) WG status, b) Resolving any Existing Document issues ? c-y) other items ? z) Toast the universal deployment of DNSSEC and closure of DNSEXT if you have requests for agenda items, send that request to dnsext-chairs@tools.ietf.org Olafur & Andrew From marka@isc.org Tue Jan 17 15:06:36 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2093621F847F for ; Tue, 17 Jan 2012 15:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s5G3BoSR4Xh for ; Tue, 17 Jan 2012 15:06:35 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 9642D21F843F for ; Tue, 17 Jan 2012 15:06:35 -0800 (PST) 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 3802CC94D0; Tue, 17 Jan 2012 23:06:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7034:c5d9:cda5:d5c0]) (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 D175C216C6A; Tue, 17 Jan 2012 23:06:24 +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 5F37B1B88FBB; Wed, 18 Jan 2012 10:06:22 +1100 (EST) To: Edward Lewis From: Mark Andrews References: <20120113225013.642F21B13171@drugs.dv.isc.org> <4F13F208.8010908@nlnetlabs.nl> <4F14359F.8050206@nlnetlabs.nl> In-reply-to: Your message of "Tue, 17 Jan 2012 10:02:29 CDT." Date: Wed, 18 Jan 2012 10:06:22 +1100 Message-Id: <20120117230622.5F37B1B88FBB@drugs.dv.isc.org> Cc: Samuel Weiler , dnsext@ietf.org Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14) 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 Jan 2012 23:06:36 -0000 In message , Edward Lewis writes: > At 10:04 -0500 1/16/12, Samuel Weiler wrote: > >Thank you for the history. Going forward, what's the best thing to > >do in the interest of interoperability? > > > >It may be worth asking not only what signers do but also what > >existing validators do. If we've only seen problems with this in > >the wild once (perhaps?) then there may be an ugly but interoperable > >answer we can document for the future. > > > > (Adding to some off-list messages, a shortened version of what I've written:) > > Downcase RRSIG, not NSEC. That includes publishing the RRSIG with > the downcased name in the RDATA. > > From what I've seen, all known signers do that, regardless of what > any spec says, hence no validators are tripped up by it. Named preserves the signer's case when publishing. US, CO and BIZ publish RRSIGs with the signer field in upper case. Mark % dnssec-keygen EX Generating key pair...++++++ .............................++++++ Kex.+005+57567 % dnssec-keygen -f KSK EX Generating key pair...........+++ .....................................................................................+++ Kex.+005+38353 % dnssec-signzone -S -o EX ex Fetching KSK 38353/RSASHA1 from key repository. Fetching ZSK 57567/RSASHA1 from key repository. Verifying the zone using the following algorithms: RSASHA1. Zone signing complete: Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked ex.signed % grep 2012 ex.signed ; File written on Wed Jan 18 09:59:29 2012 0 RRSIG SOA 5 1 0 20120216215928 ( 20120117215928 57567 EX. 0 RRSIG NS 5 1 0 20120216215928 ( 20120117215928 57567 EX. 0 RRSIG NSEC 5 1 0 20120216215928 ( 20120117215928 57567 EX. 0 RRSIG DNSKEY 5 1 0 20120216215928 ( 20120117215928 38353 EX. 0 RRSIG DNSKEY 5 1 0 20120216215928 ( 20120117215928 57567 EX. % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From segred@ics.forth.gr Wed Jan 18 02:52:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECA321F87DF for ; Wed, 18 Jan 2012 02:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcCm52qRP0HL for ; Wed, 18 Jan 2012 02:52:31 -0800 (PST) Received: from mailgate-4.ics.forth.gr (mailgate-4.ics.forth.gr [139.91.1.7]) by ietfa.amsl.com (Postfix) with ESMTP id C716621F858B for ; Wed, 18 Jan 2012 02:52:30 -0800 (PST) Received: from av1.ics.forth.gr (smtp-out.ics.forth.gr. [139.91.1.71]) by mailgate-4.ics.forth.gr (8.14.5/ICS-FORTH/V10-1.9-GATE-OUT) with ESMTP id q0IAqPnT031261; Wed, 18 Jan 2012 12:52:27 +0200 (EET) X-AuditID: 8b5b9d47-b7f946d000000b6c-34-4f16a4691b03 Received: from enigma.ics.forth.gr ( [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id 46.D1.02924.964A61F4; Wed, 18 Jan 2012 12:52:25 +0200 (EET) Received: from THANATOS (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id q0IAqKfI029740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Jan 2012 12:52:24 +0200 X-ICS-AUTH-INFO: Authenticated user: segred at ics.forth.gr From: "Vaggelis Segredakis" To: "'Warren Kumari'" , "'Mark Andrews'" References: <47C8025504E444A98A500373ADE7683B@LENOVO47E041CF> <4F105E89.9090706@abenaki.wabanaki.net> <20120113223328.C8D621B12F44@drugs.dv.isc.org> In-Reply-To: Date: Wed, 18 Jan 2012 12:52:20 +0200 Message-ID: <000c01ccd5cf$436a5390$ca3efab0$@ics.forth.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDwMqddD6hnOJVzecqFIgFILYi+HgHAUF5SAizs2kUCIY8VfJeawl5A Content-Language: el X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsXSHc0op5u5RMzf4PpnDYvdTY9YLa68uM9i cfjYZSYHZo8lS34yeTx4/I7Z4/aNP+wBzFFcNimpOZllqUX6dglcGWtvqBV8463Y+PMnawPj ZO4uRk4OCQETieZ9zWwQtpjEhXvrgWwuDiGBDYwSFw9uY4Jw5jBJzD18irWLkQOoylpixpMg kAY2AUOJz1c3sYPYIgLeEhdfnGcBsZkFRCV+3H0NNlRI4BijxMol5iA2p4CdxKwz18BqhAWC JRZ9WMUKYrMIqEp0HvnNAjKeV8BK4uuxeJAwr4CgxMmZT8DCzAJ6Em0bGSGmy0tsfzuHGeJk BYkdZ18zQlzgJrG4/zMTRI2IREvzB9YJjMKzkEyahTBpFpJJs5B0LGBkWcUokFhmqJeZXKyX ll9UkqGXXrSJERz4c913MB6foXaIUYCDUYmH16tDzF+INbGsuDL3EKMkB5OSKC/XYqAQX1J+ SmVGYnFGfFFpTmrxIUYJDmYlEd4EM6Acb0piZVVqUT5MSoaDQ0mC9zhIm2BRanpqRVpmDjC+ YdJMHJwg7TxA7fsXgbQXFyTmFmemQ+RPMSpKifOuBWkWAElklObB9YKSS/3///9fMYoDHSvM uw2kigeYmOC6XwENZgIa7NEENrgkESEl1cAY5PFSYP9p/e4S3rPzBGJWfHjL83L9nPrZGgp6 MxcXKzBN502foW7Cv//MMW6LwzxZB1bOvb1aeolLfJLBqpJ2j0OhDDK+uc3PzvImP0+V2n2P cc2aiuCcXYFLJgWsnzvtxMuEBj2hFqG2FT1RC9WdEtg/q3zRYvvxmflKtd7uRM9V5y6u2H5Q iaU4I9FQi7moOBEAkdfMKgkDAAA= Cc: dnsext@ietf.org Subject: Re: [dnsext] any interest to move bname forward before dnsext closing down 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 Jan 2012 10:52:31 -0000 Hi, I am interested as well in this proposal. Happy to work for it. Kind Regards, Vaggelis Segredakis ----------------------------------------------------------------------- Administrator of the .GR Top Level Domain Institute of Computer Science Foundation for Research and Technology - Hellas Tel. +30-281-0391450 Fax +30-281-0391451 Email segred@ics.forth.gr -----Original Message----- From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Saturday, January 14, 2012 3:54 AM To: Mark Andrews Cc: dnsext@ietf.org Subject: Re: [dnsext] any interest to move bname forward before dnsext closing down On Jan 13, 2012, at 5:33 PM, Mark Andrews wrote: > > In message <4F105E89.9090706@abenaki.wabanaki.net>, Eric > Brunner-Williams write > s: >> I'm of the same view now as I was previously. >> >> A general means to map X to Y is useful. >> >> The aliasing issue is either orthogonal, or consumer domain specific. >> In either case, it is not necessary, though it was by it self, >> sufficient to motivate a nominally similar attempt. >> >> So I am willing to work on bname. > > As am I. Hey! Me too! W > > -- > 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 > --- Don't be impressed with unintelligible stuff said condescendingly . -- Radia Perlman. Warren Kumari warren@kumari.net _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From internet-drafts@ietf.org Wed Jan 18 05:17:22 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C7921F8627; Wed, 18 Jan 2012 05:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xn1rgj0Oi9XC; Wed, 18 Jan 2012 05:17:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE94021F876E; Wed, 18 Jan 2012 05:17:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120118131709.15637.24063.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2012 05:17:09 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 13:17:22 -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 : Extension Mechanisms for DNS (EDNS0) Author(s) : Joao Damas Michael Graff Paul Vixie Filename : draft-ietf-dnsext-rfc2671bis-edns0-07.txt Pages : 14 Date : 2012-01-18 The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward compatible mechanisms for allowing the protocol to grow. This document updates the EDNS0 specification [RFC2671] based on feedback from deployment experience in several implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-07.t= xt 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-rfc2671bis-edns0-07.txt From internet-drafts@ietf.org Thu Jan 19 09:42:32 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71CB21F86AD; Thu, 19 Jan 2012 09:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldcdwAALNEhj; Thu, 19 Jan 2012 09:42:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F50A21F8682; Thu, 19 Jan 2012 09:42:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120119174213.3614.43184.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2012 09:42:13 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-ecdsa-04.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, 19 Jan 2012 17:42:33 -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 : Elliptic Curve DSA for DNSSEC Author(s) : Paul Hoffman Wouter Wijngaards Filename : draft-ietf-dnsext-ecdsa-04.txt Pages : 8 Date : 2012-01-19 This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-04.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-ecdsa-04.txt From ogud@ogud.com Thu Jan 19 09:57:18 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DADC21F85CC for ; Thu, 19 Jan 2012 09:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.404 X-Spam-Level: X-Spam-Status: No, score=-106.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTzVxmu-E+7S for ; Thu, 19 Jan 2012 09:57:17 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 76D7B21F85C7 for ; Thu, 19 Jan 2012 09:57:17 -0800 (PST) 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 q0JHvFxO006279 for ; Thu, 19 Jan 2012 12:57:16 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F185979.1060105@ogud.com> Date: Thu, 19 Jan 2012 12:57:13 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 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.72 on 10.20.30.4 Subject: [dnsext] Summary WGLC: draft-ietf-dnsext-ecdsa 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 Jan 2012 17:57:18 -0000 Dear colleagues, This working group last call has completed, during the last call we had enough support and reviews to meet the WG requirements. During the last call a few suggestions about how to improve the text were made, the editors have applied these to the latest version. During the last call a suggestion was made to optimize the binary formats, that proposal did not receive any support. I will be submitting this document in the next few days to the IESG. Olafur From rstruik.ext@gmail.com Thu Jan 19 10:42:23 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3353521F85E7 for ; Thu, 19 Jan 2012 10:42:23 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qk11f03jKaMG for ; Thu, 19 Jan 2012 10:42:22 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6601921F847C for ; Thu, 19 Jan 2012 10:42:20 -0800 (PST) Received: by yenm3 with SMTP id m3so182203yen.31 for ; Thu, 19 Jan 2012 10:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=AgUDq7g5oKZPJpRge/m67P0QaApWDpxJzzZmqzBtDqk=; b=sf6VZlaCQIjhKWCX6o+f0zDSexSSdmE01X+3+r0Ywly8Yz0InvZJqTzan4b9qzSh2P 97sxYxTEpkg7P8iKein3dWBVQdQhEv3XR5mK/kbRIlqeGTevNyeBSqFR3Mz+rixdt9EP SaGVApuD2L7No22WPxTQjonmprn0hAY4kYBFk= Received: by 10.236.141.37 with SMTP id f25mr41979321yhj.3.1326998540068; Thu, 19 Jan 2012 10:42:20 -0800 (PST) Received: from [172.16.13.151] ([12.52.73.66]) by mx.google.com with ESMTPS id r68sm366984yhm.18.2012.01.19.10.42.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 10:42:19 -0800 (PST) Message-ID: <4F186400.8010604@gmail.com> Date: Thu, 19 Jan 2012 13:42:08 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Olafur Gudmundsson References: <4F185979.1060105@ogud.com> In-Reply-To: <4F185979.1060105@ogud.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Summary WGLC: draft-ietf-dnsext-ecdsa 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 Jan 2012 18:42:23 -0000 Hi Olafur: I may have missed this, but I never saw an announcement for WG last call. More importantly, though, the last versions do not really seem to have addressed my comments sent prior to the July 2011 meeting in Quebec. Rene On 19/01/2012 12:57 PM, Olafur Gudmundsson wrote: > > Dear colleagues, > > This working group last call has completed, during the last call we > had enough support and reviews to meet the WG requirements. > > During the last call a few suggestions about how to improve the text > were made, the editors have applied these to the latest version. > During the last call a suggestion was made to optimize the binary > formats, that proposal did not receive any support. > > I will be submitting this document in the next few days to the IESG. > > Olafur > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From rstruik.ext@gmail.com Thu Jan 19 10:53:39 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A035621F84B9 for ; Thu, 19 Jan 2012 10:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l51tg9N3jWUB for ; Thu, 19 Jan 2012 10:53:37 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFFDC21F845C for ; Thu, 19 Jan 2012 10:53:36 -0800 (PST) Received: by ghrr16 with SMTP id r16so206080ghr.31 for ; Thu, 19 Jan 2012 10:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=OQZqlI/wXX5sR/g80D0zmenkZw0BahBJ42vJs9KbnY4=; b=hj2sTExmxVG85qk5OZHkpTik7s7qfkbBnnRp2qfLzjGydWWuSlsdH56OCTg+jlfj11 mdTBIh982WU/nGLXt/tmWvAUpQQ2B8ONYgqeARJ/z3tm+MbBEmRiyunHfGklmojeWyll GlTFUY/4Ru1kBLOVE1gLWcdvBJzmorS7J5xdU= Received: by 10.236.185.72 with SMTP id t48mr9958781yhm.22.1326999216526; Thu, 19 Jan 2012 10:53:36 -0800 (PST) Received: from [172.16.13.151] ([12.52.73.66]) by mx.google.com with ESMTPS id j16sm634155anm.9.2012.01.19.10.53.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 10:53:35 -0800 (PST) Message-ID: <4F1866A4.5040509@gmail.com> Date: Thu, 19 Jan 2012 13:53:24 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Olafur Gudmundsson References: <4F185979.1060105@ogud.com> <4F186400.8010604@gmail.com> In-Reply-To: <4F186400.8010604@gmail.com> X-Enigmail-Version: 1.3.4 Content-Type: multipart/alternative; boundary="------------050807020400060809070308" Cc: dnsext@ietf.org Subject: Re: [dnsext] Summary WGLC: draft-ietf-dnsext-ecdsa 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 Jan 2012 18:53:39 -0000 This is a multi-part message in MIME format. --------------050807020400060809070308 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Olafur: My comments on the earlier draft were sent July 21, 2011 (with apparently an update just sent out ealry January, during the Xmas break). I would appreciate if the authors indicate for each of the comments below that they did not wish to accommodate their rationale. Best regards, Rene http://www.ietf.org/mail-archive/web/dnsext/current/msg11483.html Re: [dnsext] WGLC: Elliptic Curve DSA ------------------------------------------------------------------------ * /From/: Rene Struik > * /To/: Olafur Gudmundsson > * /Cc/: dnsext at ietf.org * /Date/: Thu, 21 Jul 2011 19:01:07 -0400 * /In-reply-to/: <4E14D100.5010705 at ogud.com > * /References/: <4E14D100.5010705 at ogud.com > * /List-id/: DNS Extensions working group discussion list ------------------------------------------------------------------------ Dear colleagues: Please find below my editorial and technical comments on draft-ietf-dnsext-ecdsa-01. Best regards, Rene == Summary of the draft: The draft specifies two two elliptic curve signature algorithms for use with DNSSEC that were heretoforth not defined, viz. ECDSA with suite B curves and hash functions at 128-bit and 192-bit crypto bit strength). As pointed out, the main rationale for doing so are that use of ECDSA and ECDSA public keys (a) allows smaller size data fields; (b) may allow computational savings; (c) introduces algorithms with crypto primitives of equivalent cryptographic bit strength. == Summary of comments: 1) Editorial: The draft would benefit from tightening up some of the language, especially since this may lower the chance of confusing noncryptographic people. 2) Technical: The draft results in data fields of size 4n octets, where n is the octet-length of the underlying curve. In fact, one can do better and use data fields of size 3n octets, without loss of functionality. == Detailed comments: -- I. Editorial and semi-editorial comments: (E-a) p.2, Clause 1, first para: With RSA, "key" should read "modulus" (e.g., "using 1024 or 2048 bit moduli"). The same remark applies to interchanges of keys and moduli with RSA, e.g., third para ("3072-bit keys"). (E-b) p.2, Clause 1, second para: I suggest adding the following references: (1) for P-256 and P-384, xref FIPS Pub 186-3; (2) for ECDSA, xref FIPS Pub 186-3 (esp. necessary, so as to specify how to map hash output (bit string) to an integer in Zn); (3) SHA-256 and SHA-384, xref FIPS Pub 180-3. {Note RS: With the availability of RFC 6090 "Fundamentals of ECC", should one refer that RFC as well, besides FIPS Pub 186-3?} (E-c) p.2, Clause 1, second para: Replace DS RR by delegating signer resource record (DS RR). (E-d) p.2, Clause 1, third para: This para suggests that public keys on the curve P-256 have size 256 bits, but this conflicts the representation in Clause 4, first para, where their (affine) representation is 512 bits. {BTW - I strongly suggest using "octet" units, rather than "bits", since this seems to better align with other crypto-related IETF documents, and non-IETF documents (ANSI, SECG, etc.).} (E-e) p.2, Clause 1, third para: This para attemts to quantify comparisons of the size of RSA and ECDSA public keys, but does omit this for RSA signatures and ECDSA signatures. Suggest to correct (for 128-bit crypto bit strength). (E-f ) p.2, Clause 1, fourth para, l.2: The term "matching" is somewhat unfortunate: why not state that the curve and the hash function are picked with the same cryptographic bit design strength? (E-g) p.2, Clause 1, fourth para, l.6: Unkeyed hash functions do not have a key, so please replace "...is half the length of the key" by "... is half the output size (in bits)". {Note RS: please note the "(in bits)" phrase, which should also be added to the corresponding statement on cryptographic bit strength for public keys (cf. same para, l.4-5: change to "...is half the bit-length of the key"). (E-h) p.2, Clause 1, fourth para, l.6: Replace "using matched strength" by "using the same cryptographic bit strength". (E-i) p.2, Clause 1, fourth para, l.7: The notion of "weaker half" of a signature algorithm is somewhat confusing, since, e.g., with ECDSA, while the strength is not entirely proven (to my knowledge), it depends on at least three factors, including (1) underlying hash function; (2) underlying ECDHP; (3) ECDSA peculiarities. Changing "choosing the weaker half of" by "choosing the weaker cryptographic primitive [or: component] of the signature algorithm. (E-j) p.2, Clause 1, fourth para, l.7-10: The RSA example would be clearer if one would state that RSA with 2048 modulus is believed to have 112 bit cryptographic bit strength, since then the discussion about equivalent bit strength becomes simply an exercise in comparing this with the presumed strength of SHA-256 (half the output size or 128-256/2). (E-k) p.2, Clause 1, fifth para: Performance of cryptographic operations is highly platform-dependent, so absolute numbers should be avoided at almost all cost. Moreover, it is (of course) dependent on the crypto primitive in question -- something that is not mentioned (e.g., is the factor 5x computational advantage ECDSA signing compared to RSA signing for P-256 vs. RSA-3072, or for something else?). I would suggest to replace "Signing with ECDSA is" by "signing with ECDSA may be" and adopt the corresponding absolute language for the verification numbers accordingly as well. Moreover, please pick a curve for which these numbers apply. {Note RS: as a side note: to illustrate that one has to be careful here, please cf. to Slide 48 of http://www.ietf.org/proceedings/78/slides/saag-7.pdf, which suggests that for some platforms, both signing and verification for ECDSA is faster than with RSA (and not just signing, as in this draft).} (E-l) p.3, Clause 1, sixth para, l.4: Perhaps, replace "is copied liberally from" by "borrows heavily from"? (E-m) p.3, Clause 2, l.2: Replace "the implementation of SHA-384 in DNSSEC" by "the use of SHA-256 in DNSSEC" (after all, now it seems one discusses the implementations of SHA-256 and SHA-384 themselves [at least, to me, as nonnative speaker]). (E-n) p.3, Clause 3: This clause discusses the need for corresponding parties to have access to the same system-wide parameters, in casu for ECDSA. However, the remainder of this clause only talks about the elliptic curve domain parameters (P-256, resp. P-384), but does not mention the hash function (SHA-x, etc.) underlying ECDSA, the encoding rules (bit/octet order, etc.) for messages to be signed, etc. This is confusing. (E-o) p.3, Clause 4, first para: The x- and y-coordinates of public key Q should be properly introduced. Of course, crypto people know that this corresponds to the affine representation of points on the corresponding prime curve, but this should be left less as guess work. In fact, I would strongly urge to use the same representation convention for public keys as used elsewhere, such as, e.g., wiht RFC 3279 (Clause 2.3.5, ECPoint), with ANSI X9.62-1999 (4.3.6), or with SEC1 or RFC5480. This format nicely allows unique representation of the point of infinity (0x00), affine points (0x04 | x | y), and compressed points (PC=0x02 or 0x03 | x). Thus, one can represent Q as (0x04 | x | y). (E-p) p.3, Clause 4, second para: The signature components r and s are integers, but r | s is an octet string. Please add the following text a the end of the paragraph: "where "r" and "s" are represented each as octet string, with size the octet size of the (prime) order of the underlying prime curve. (E-q) p.4, Clause 4, third para: The two bulletized items should also refer to the underlying ECDSA specification (FIPS Pub 186-3) as well. (E-r) p.4, Clause 4, fourth para, l.1: It seems that one cannot state "MUST support" and then offer an "and/or" option. Suggest to change this to support for both signing *and* verification (so as to avoid ambiguities here). (E-s) p.4, Clause 5, second para, l.3: Not sure why one would not just refer to SHA-1 (which is Algorithm 1, as defined in Clause 11 of RFC 5155). If one somehow does not wish to admit to using SHA-1, it would really help to add clause numbers, so as to help the reader find all this (some IETF specifications are extremely large and making life easier should be explicit goal of writing). (E-t) p.4, Clause 6, second para: The picks for TBA-1, TBA-2, and TBA-3 are really obscure; this is much clearer once one disects the examples in Clause 6.1 ff. Also here, why not make life easier on the reader and change the last sentence to "The examples use the following algorithm codes: Code 4 for ECDSAP256SHA256 (TBA-1), ...", etc? (E-u) p.6, Clause 8, l.2: Again, please change "half the size of the key" to "half the bit-size of the underlying curve". (Considering the pick in Clause 4 for Q, half of the key would be the bit-size of the curve, rather than half the bit-size). (E-v) pp.3-4, Clause 4 (or, perhaps, more general remark): Currently, the clause does not make for easy reading, since it just defines the signature format and the public key format and does not even hint at the clauses in the corresponding base line documentation (RFC 4033,4034, 4035) where all this "falls into place". I would strongly suggest adding more clues, so as to make this for less esoteric reading. Why not include some text that captures the following (here, mentioned for 128-bit crypto strength): The DNSKEY Resource Record is defined in RFC 4034, Clause 2.1. -the algorithm field (RFC4034, 2.1.3) is set to ECDSAP256SHA256 {TBA-1}; -the public key is set to the representation for the public key introduced in Clause 4; etc. Note RS: RFC 4034 already includes Algorithm Type 4 for ECC (cf. Annex A.1), but currently this is undefined. -- II. Technical comments: (T-a) p.3, Clause 4, first para: In this para, the ECDSA signature is 2n octet field, as is the public key Q, where n is the octet size of the order of the underlying curve. Since the size of the public key Q is important (cf., also Clause 1, third para, last sentence), why not be somewhat more economical here and represent Q by its x-coordinate only? This does not seem to lead to any loss of functionality, whereas shaving off 25% of the data field overhead, from 4n octets to 3n octets. Some details follow: Underlying motivation: (1) The point of sending the public key Q along seems to be that one has an identifier for the public signature verification key that one also has in a white list on the verifier's machine? (If one does not have a white list check on the verifier, the authentication procedure is completely broken, since then anyone can produce valid signatures.) This assertion seems to be validated by Clause 5.3.1 of RFC 4035 (which discusses authentication). (2) To identify a public key Q residing on a verifier's machine, one does not need the entire public key; the x-coordinate suffices: after all, no two public signature verification keys belonging to valid signers will have the same x-coordinate (for otherwise, one knows the private key of the other). Suggested improvement: The above assertions lead to the following 33% size improvement, with following (very modest) changes required: 1) Signing side: -Clause 4, first para: Represent the public key Q by its x-coordinate, rather than by the pair x-coordinate and y-coordinate (here, we denote the result by Q'); -Data to be signed: hash data with Q' included, rather than Q (this has no security implications at all, as one can easily see). 2) When verifying an ECDSA signature, "decompress" first: - Use Q' as index to recover the key Q at verifier's machine; - Use Q to veerify the ECDSA signature by computing R'=(1/s) (eG +rQ), where e= h(m,Q') and checking that f(R')=r (mathematical short-cut notation for ECDSA signature verification). Final notes RS: 1) If one wishes, one could send either Q'=x-coordinate of Q or Q itself (in case one somehow feels that one needs options (should not be necessary, though)). In that case, the "normal" representation of elliptic curve points -- affine representation of Q = (0x04, x, y); new x-coordinate only representation Q' = (0x01, x) would do. This does (a) not conflict any ECPoint representations already in use; (b) this does allow different representations of the public key in the DNSKEY RR (RFC 4034, Clause 2.1.4), so doing away with need to define new algorithm id (RFC 4034, Clause 2.1.3). 2) RFC 4035, Clause 5.1.3 (authentication procedure) already caters for the scenario that one may have "more than one match", so - if one really wishes one could compute both Q and -Q from Q' (i.e., compute both (x,y) and (x,-y) given x-coordinate Q') and run the authentication algorithm as already specified. 2) Security is exactly the same as with original construct. 3) There are no nontechnical considerations to be concerned about (note that Q' does not provide any insight on the y-coordinate of Q). Best regards, Rene On 06/07/2011 5:17 PM, Olafur Gudmundsson wrote: > Dear Colleagues > > This message starts a Working Group Last Call for > "Elliptic Curve DSA for DNSSEC" located at > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-01.txt > This document is on Standards track. > > This WGLC will conclude on midnight on July 21'th UTC. > > Please review the document and sent a statement that you reviewed the > document. If the review raises any issues, please note what they are. > Remember that we need a minimum of 5 reviewers. > On 19/01/2012 1:42 PM, Rene Struik wrote: > Hi Olafur: > > I may have missed this, but I never saw an announcement for WG last call. > > More importantly, though, the last versions do not really seem to have > addressed my comments sent prior to the July 2011 meeting in Quebec. > > Rene > > > On 19/01/2012 12:57 PM, Olafur Gudmundsson wrote: >> Dear colleagues, >> >> This working group last call has completed, during the last call we >> had enough support and reviews to meet the WG requirements. >> >> During the last call a few suggestions about how to improve the text >> were made, the editors have applied these to the latest version. >> During the last call a suggestion was made to optimize the binary >> formats, that proposal did not receive any support. >> >> I will be submitting this document in the next few days to the IESG. >> >> Olafur >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 --------------050807020400060809070308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Olafur:

My comments on the earlier draft were sent July 21, 2011 (with apparently an update just sent out ealry January, during the Xmas break).

I would appreciate if the authors indicate for each of the comments below that they did not wish to accommodate their rationale.

Best regards, Rene

http://www.ietf.org/mail-archive/web/dnsext/current/msg11483.html

Re: [dnsext] WGLC: Elliptic Curve DSA

Dear colleagues:

Please find below my editorial and technical comments on draft-ietf-dnsext-ecdsa-01.

Best regards, Rene

==

Summary of the draft:
The draft specifies two two elliptic curve signature algorithms for use with DNSSEC that were heretoforth not defined,
viz. ECDSA with suite B curves and hash functions at 128-bit and 192-bit crypto bit strength). As pointed out, the main 
rationale for doing so are that use of ECDSA and ECDSA public keys (a) allows smaller size data fields; (b) may allow
computational savings; (c) introduces algorithms with crypto primitives of equivalent cryptographic bit strength.

==

Summary of comments:

1) Editorial:
The draft would benefit from tightening up some of the language, especially since this may lower the chance of confusing 
noncryptographic people.

2) Technical:
The draft results in data fields of size 4n octets, where n is the octet-length of the underlying curve. In fact, one can 
do better and use data fields of size 3n octets, without loss of functionality.

==

Detailed comments:

--

I. Editorial and semi-editorial comments:

(E-a) p.2, Clause 1, first para: 
With RSA, "key" should read "modulus" (e.g., "using 1024 or 2048 bit moduli"). The same remark applies to interchanges 
of keys and moduli with RSA, e.g., third para ("3072-bit keys").

(E-b) p.2, Clause 1, second para:
I suggest adding the following references: 
(1) for P-256 and P-384, xref FIPS Pub 186-3; 
(2) for ECDSA, xref FIPS Pub 186-3 (esp. necessary, so as to specify how to map hash output (bit string) to an integer in Zn); 
(3) SHA-256 and SHA-384, xref FIPS Pub 180-3.
{Note RS: With the availability of RFC 6090 "Fundamentals of ECC", should one refer that RFC as well, besides FIPS Pub 186-3?}

(E-c) p.2, Clause 1, second para:
Replace DS RR by delegating signer resource record (DS RR).

(E-d) p.2, Clause 1, third para:
This para suggests that public keys on the curve P-256 have size 256 bits, but this conflicts the representation in Clause 4, 
first para, where their (affine) representation is 512 bits.
{BTW - I strongly suggest using "octet" units, rather than "bits", since this seems to better align with other crypto-related 
IETF documents, and non-IETF documents (ANSI, SECG, etc.).}

(E-e) p.2, Clause 1, third para:
This para attemts to quantify comparisons of the size of RSA and ECDSA public keys, but does omit this for RSA signatures and ECDSA
signatures. Suggest to correct (for 128-bit crypto bit strength).

(E-f) p.2, Clause 1, fourth para, l.2:
The term "matching" is somewhat unfortunate: why not state that the curve and the hash function are picked with the same cryptographic
bit design strength?

(E-g) p.2, Clause 1, fourth para, l.6:
Unkeyed hash functions do not have a key, so please replace "...is half the length of the key" by "... is half the output size (in bits)".
{Note RS: please note the "(in bits)" phrase, which should also be added to the corresponding statement on cryptographic bit strength for 
public keys (cf. same para, l.4-5: change to "...is half the bit-length of the key"). 

(E-h) p.2, Clause 1, fourth para, l.6:
Replace "using matched strength" by "using the same cryptographic bit strength".

(E-i) p.2, Clause 1, fourth para, l.7:
The notion of "weaker half" of a signature algorithm is somewhat confusing, since, e.g., with ECDSA, while the strength is not entirely 
proven (to my knowledge), it depends on at least three factors, including (1) underlying hash function; (2) underlying ECDHP; 
(3) ECDSA peculiarities. Changing "choosing the weaker half of" by "choosing the weaker cryptographic primitive [or: component] of the 
signature algorithm.

(E-j) p.2, Clause 1, fourth para, l.7-10:
The RSA example would be clearer if one would state that RSA with 2048 modulus is believed to have 112 bit cryptographic bit strength,
since then the discussion about equivalent bit strength becomes simply an exercise in comparing this with the presumed strength of
SHA-256 (half the output size or 128-256/2).

(E-k) p.2, Clause 1, fifth para:
Performance of cryptographic operations is highly platform-dependent, so absolute numbers should be avoided at almost all cost. Moreover, it
is (of course) dependent on the crypto primitive in question -- something that is not mentioned (e.g., is the factor 5x computational advantage
ECDSA signing compared to RSA signing for P-256 vs. RSA-3072, or for something else?). I would suggest to replace "Signing with ECDSA is" by 
"signing with ECDSA may be" and adopt the corresponding absolute language for the verification numbers accordingly as well. Moreover, please 
pick a curve for which these numbers apply. 
{Note RS: as a side note: to illustrate that one has to be careful here, please cf. to Slide 48 of
http://www.ietf.org/proceedings/78/slides/saag-7.pdf, which suggests that for some platforms, both signing and verification for ECDSA is faster
than with RSA (and not just signing, as in this draft).}

(E-l) p.3, Clause 1, sixth para, l.4:
Perhaps, replace "is copied liberally from" by "borrows heavily from"?

(E-m) p.3, Clause 2, l.2:
Replace "the implementation of SHA-384 in DNSSEC" by "the use of SHA-256 in DNSSEC" (after all, now it seems one discusses the implementations 
of SHA-256 and SHA-384 themselves [at least, to me, as nonnative speaker]).

(E-n) p.3, Clause 3:
This clause discusses the need for corresponding parties to have access to the same system-wide parameters, in casu for ECDSA. 
However, the remainder of this clause only talks about the elliptic curve domain parameters (P-256, resp. P-384), but does not mention the 
hash function (SHA-x, etc.) underlying ECDSA, the encoding rules (bit/octet order, etc.) for messages to be signed, etc. This is confusing.

(E-o) p.3, Clause 4, first para:
The x- and y-coordinates of public key Q should be properly introduced. Of course, crypto people know that this corresponds to the affine
representation of points on the corresponding prime curve, but this should be left less as guess work.
In fact, I would strongly urge to use the same representation convention for public keys as used elsewhere, such as, e.g., wiht RFC 3279 
(Clause 2.3.5, ECPoint), with ANSI X9.62-1999 (4.3.6), or with SEC1 or RFC5480. This format nicely allows unique representation of the point
of infinity (0x00), affine points (0x04 | x | y), and compressed points (PC=0x02 or 0x03 | x). Thus, one can represent Q as (0x04 | x | y).

(E-p) p.3, Clause 4, second para:
The signature components r and s are integers, but r | s is an octet string. Please add the following text a the end of the paragraph:
"where "r" and "s" are represented each as octet string, with size the octet size of the (prime) order of the underlying prime curve.

(E-q) p.4, Clause 4, third para:
The two bulletized items should also refer to the underlying ECDSA specification (FIPS Pub 186-3) as well.

(E-r) p.4, Clause 4, fourth para, l.1:
It seems that one cannot state "MUST support" and then offer an "and/or" option. Suggest to change this to support for both signing *and* 
verification (so as to avoid ambiguities here).

(E-s) p.4, Clause 5, second para, l.3:
Not sure why one would not just refer to SHA-1 (which is Algorithm 1, as defined in Clause 11 of RFC 5155). If one somehow does not wish
to admit to using SHA-1, it would really help to add clause numbers, so as to help the reader find all this (some IETF specifications are 
extremely large and making life easier should be explicit goal of writing).

(E-t) p.4, Clause 6, second para:
The picks for TBA-1, TBA-2, and TBA-3 are really obscure; this is much clearer once one disects the examples in Clause 6.1 ff. Also here, 
why not make life easier on the reader and change the last sentence to "The examples use the following algorithm codes:
Code 4 for ECDSAP256SHA256 (TBA-1), ...", etc?

(E-u) p.6, Clause 8, l.2:
Again, please change "half the size of the key" to "half the bit-size of the underlying curve". (Considering the pick in Clause 4 for Q, half 
of the key would be the bit-size of the curve, rather than half the bit-size).

(E-v) pp.3-4, Clause 4 (or, perhaps, more general remark):
Currently, the clause does not make for easy reading, since it just defines the signature format and the public key format and does not
even hint at the clauses in the corresponding base line documentation (RFC 4033,4034, 4035) where all this "falls into place".
I would strongly suggest adding more clues, so as to make this for less esoteric reading. Why not include some text that captures the following
(here, mentioned for 128-bit crypto strength):
The DNSKEY Resource Record is defined in RFC 4034, Clause 2.1.
-the algorithm field (RFC4034, 2.1.3) is set to ECDSAP256SHA256 {TBA-1};
-the public key is set to the representation for the public key introduced in Clause 4;
etc.
Note RS: RFC 4034 already includes Algorithm Type 4 for ECC (cf. Annex A.1), but currently this is undefined.

--

II. Technical comments:

(T-a) p.3, Clause 4, first para:
In this para, the ECDSA signature is 2n octet field, as is the public key Q, where n is the octet size of the order of the underlying curve.
Since the size of the public key Q is important (cf., also Clause 1, third para, last sentence), why not be somewhat more economical here and
represent Q by its x-coordinate only? This does not seem to lead to any loss of functionality, whereas shaving off 25% of the data field 
overhead, from 4n octets to 3n octets. Some details follow:

Underlying motivation:
(1) The point of sending the public key Q along seems to be that one has an identifier for the public signature verification key that one also has
in a white list on the verifier's machine? (If one does not have a white list check on the verifier, the authentication procedure is completely
broken, since then anyone can produce valid signatures.) This assertion seems to be validated by Clause 5.3.1 of RFC 4035 (which discusses 
authentication).
(2) To identify a public key Q residing on a verifier's machine, one does not need the entire public key; the x-coordinate suffices: after all,
no two public signature verification keys belonging to valid signers will have the same x-coordinate (for otherwise, one knows the private key 
of the other).

Suggested improvement:
The above assertions lead to the following 33% size improvement, with following (very modest) changes required:

1) Signing side:
-Clause 4, first para:
Represent the public key Q by its x-coordinate, rather than by the pair x-coordinate and y-coordinate (here, we denote the result by Q');
-Data to be signed: hash data with Q' included, rather than Q (this has no security implications at all, as one can easily see).

2) When verifying an ECDSA signature, "decompress" first:
- Use Q' as index to recover the key Q at verifier's machine;
- Use Q to veerify the ECDSA signature by computing R'=(1/s) (eG +rQ), where e= h(m,Q') and checking that f(R')=r (mathematical short-cut 
notation for ECDSA signature verification).

Final notes RS:
1) If one wishes, one could send either Q'=x-coordinate of Q or Q itself (in case one somehow feels that one needs options (should not be 
necessary, though)). In that case, the "normal" representation of elliptic curve points -- affine representation of Q = (0x04, x, y); new 
x-coordinate only representation Q' = (0x01, x) would do. This does (a) not conflict any ECPoint representations already in use; (b) this does 
allow different representations of the public key in the DNSKEY RR (RFC 4034, Clause 2.1.4), so doing away with need to define new algorithm id 
(RFC 4034, Clause 2.1.3).
2) RFC 4035, Clause 5.1.3 (authentication procedure) already caters for the scenario that one may have "more than one match", so - if one really 
wishes one could compute both Q and -Q from Q' (i.e., compute both (x,y) and (x,-y) given x-coordinate Q') and run the authentication algorithm 
as already specified. 
2) Security is exactly the same as with original construct.
3) There are no nontechnical considerations to be concerned about (note that Q' does not provide any insight on the y-coordinate of Q).

Best regards, Rene




On 06/07/2011 5:17 PM, Olafur Gudmundsson wrote:
> Dear Colleagues
>
> This message starts a Working Group Last Call for
> "Elliptic Curve DSA for DNSSEC" located at
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-01.txt
> This document is on Standards track.
>
> This WGLC will conclude on midnight on July 21'th UTC.
>
> Please review the document and sent a statement that you reviewed the
> document.  If the review raises any issues, please note what they are.
> Remember that we need a minimum of 5 reviewers.
>

On 19/01/2012 1:42 PM, Rene Struik wrote: 
Hi Olafur:

I may have missed this, but I never saw an announcement for WG last call.

More importantly, though, the last versions do not really seem to have
addressed my comments sent prior to the July 2011 meeting in Quebec.

Rene


On 19/01/2012 12:57 PM, Olafur Gudmundsson wrote:

Dear colleagues,

This working group last call has completed, during the last call we
had enough support and reviews to meet the WG requirements.

During the last call a few suggestions about how to improve the text
were made, the editors have applied these to the latest version.
During the last call a suggestion was made to optimize the binary
formats, that proposal did not receive any support.

I will be submitting this document in the next few days to the IESG.

    Olafur
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext





-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
--------------050807020400060809070308-- From paul.hoffman@vpnc.org Thu Jan 19 11:06:30 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B55C21F84A1 for ; Thu, 19 Jan 2012 11:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1LIOry+CK9a for ; Thu, 19 Jan 2012 11:06:29 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA9721F849D for ; Thu, 19 Jan 2012 11:06:29 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0JJ6QP3094854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jan 2012 12:06:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F186400.8010604@gmail.com> Date: Thu, 19 Jan 2012 11:06:28 -0800 Content-Transfer-Encoding: 7bit Message-Id: <7274B0C0-4BB3-4611-B495-91B123F0AECA@vpnc.org> References: <4F185979.1060105@ogud.com> <4F186400.8010604@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1251.1) Cc: DNSEXT Working Group Subject: Re: [dnsext] Summary WGLC: draft-ietf-dnsext-ecdsa 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 Jan 2012 19:06:30 -0000 On Jan 19, 2012, at 10:42 AM, Rene Struik wrote: > I may have missed this, but I never saw an announcement for WG last call. That statement is completely untrue: you responded to that announcement. > More importantly, though, the last versions do not really seem to have > addressed my comments sent prior to the July 2011 meeting in Quebec. Correct. You asked for many changes, and no one else supported your request. --Paul Hoffman From rstruik.ext@gmail.com Thu Jan 19 11:12:09 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4019321F85C7 for ; Thu, 19 Jan 2012 11:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxQbeKedfo2U for ; Thu, 19 Jan 2012 11:12:08 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 93B7721F857D for ; Thu, 19 Jan 2012 11:12:08 -0800 (PST) Received: by ghrr16 with SMTP id r16so219582ghr.31 for ; Thu, 19 Jan 2012 11:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=7BDIZWKrZCqN5urRbGb7OwG7vbycNDvW8ffAk519PLM=; b=JmHKsRv9UiV0AAqJhd6tDDFz8Ytcl2q+UponF5GopDjALm3E66R22NBpZRsax4+DRf IZ8+UhcIJlXQUGgmvE0Ipf41RK8uhCXPP73Tp02Prd6CB8ZkZP02AbJICE9F2/llAdsF Ll/pwvOHyE1MccZ799HATyBD8VRptleZzl9wA= Received: by 10.101.144.18 with SMTP id w18mr9290391ann.88.1327000328176; Thu, 19 Jan 2012 11:12:08 -0800 (PST) Received: from [172.16.13.151] ([12.52.73.66]) by mx.google.com with ESMTPS id s7sm858175anc.4.2012.01.19.11.12.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 11:12:07 -0800 (PST) Message-ID: <4F186AFB.1050702@gmail.com> Date: Thu, 19 Jan 2012 14:11:55 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Paul Hoffman References: <4F185979.1060105@ogud.com> <4F186400.8010604@gmail.com> <7274B0C0-4BB3-4611-B495-91B123F0AECA@vpnc.org> In-Reply-To: <7274B0C0-4BB3-4611-B495-91B123F0AECA@vpnc.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DNSEXT Working Group Subject: Re: [dnsext] Summary WGLC: draft-ietf-dnsext-ecdsa 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 Jan 2012 19:12:09 -0000 Hi Paul: So, was the WGLC the one in July 2011? Olaf did not reference that WGLC, which was eons ago (half a year). Now, there seem to have been three versions since 2 1/2 weeks, with nothing prior for 5 1/2 months. Some more clarity, except a short line that seems to be out of the blue would be appreciated. I am curious as to why "nobody" supported squeezing down message sizes. Was this seriously considered? What was the technical rationale for not supporting my modest suggestions. What is your rationale for not supporting this??? Shouldn't technical merit of comments be discussed openly. I thought IETF was all about openness. Rene On 19/01/2012 2:06 PM, Paul Hoffman wrote: > On Jan 19, 2012, at 10:42 AM, Rene Struik wrote: > >> I may have missed this, but I never saw an announcement for WG last call. > That statement is completely untrue: you responded to that announcement. > >> More importantly, though, the last versions do not really seem to have >> addressed my comments sent prior to the July 2011 meeting in Quebec. > Correct. You asked for many changes, and no one else supported your request. > > --Paul Hoffman > -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From paul.hoffman@vpnc.org Thu Jan 19 11:30:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F40621F85EE for ; Thu, 19 Jan 2012 11:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MM+cqXidvHwF for ; Thu, 19 Jan 2012 11:30:12 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BD83E21F8438 for ; Thu, 19 Jan 2012 11:30:12 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0JJUA4B095676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jan 2012 12:30:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F186AFB.1050702@gmail.com> Date: Thu, 19 Jan 2012 11:30:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <492A6661-39EF-4437-9050-4062379BD530@vpnc.org> References: <4F185979.1060105@ogud.com> <4F186400.8010604@gmail.com> <7274B0C0-4BB3-4611-B495-91B123F0AECA@vpnc.org> <4F186AFB.1050702@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1251.1) Cc: DNSEXT Working Group Subject: Re: [dnsext] Summary WGLC: draft-ietf-dnsext-ecdsa 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 Jan 2012 19:30:13 -0000 On Jan 19, 2012, at 11:11 AM, Rene Struik wrote: > So, was the WGLC the one in July 2011? Yes. You replied on that thread, according to the WG archives. > Olaf did not reference that WGLC, > which was eons ago (half a year). Which part of the word "Last" are you confused about? :-) > Now, there seem to have been three > versions since 2 1/2 weeks, with nothing prior for 5 1/2 months. Some > more clarity, except a short line that seems to be out of the blue = would > be appreciated. There was a WGLC with an end date. There were comments during WGLC. Some = comments asked for changes, and there were multiple people who supported = those changes. The authors (Wouter and I) made those changes. There were = some comments from you that asked for extensive changes, and no one = supported your request. We didn't make those changes. > I am curious as to why "nobody" supported squeezing down message = sizes. > Was this seriously considered? What was the technical rationale for = not > supporting my modest suggestions. I cannot speak for everyone, but I can say why I didn't support it: it = would possibly involve IPR hassles. The IPR hassles are not worth it = here, in my opinion. > What is your rationale for not supporting this??? If one person proposes a technical change to a spec and no one else = agrees with them, it is not a good idea to make that change. > Shouldn't technical merit of comments be discussed openly. You did openly discuss the technical merits of your proposal. No one = supported your assertions. > I thought > IETF was all about openness. No, the IETF is about many things. It is also openness, about not = letting one person derail standards actions, about not unnecessarily = encumbering protocols with questionable IPR if it doesn't add much = value, and about making progress. --Paul Hoffman From rstruik.ext@gmail.com Thu Jan 19 12:20:47 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F96F21F86D6 for ; Thu, 19 Jan 2012 12:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPGWoc5R-Bra for ; Thu, 19 Jan 2012 12:20:46 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA3321F86D5 for ; Thu, 19 Jan 2012 12:20:46 -0800 (PST) Received: by yenm3 with SMTP id m3so248606yen.31 for ; Thu, 19 Jan 2012 12:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=UXm54yfkauYuWWzY+SefEQNAp3thJYp+nW/ufajZmmg=; b=wKDAGNmnTFD+pBnYeu/MmSAsO4ir1QfETLewXgNzO2fUz0+QQt9c0Rw+OZRCjxwmqI XqeYXYgDEWoOj9/MESjQ0yuy1M0Iwd7ipQKZP5PfYZ5eXih3IAs3H9RmYZLMjCaaE4Sl 6EDDFgVWXhXgGa4Tr88cobtqF09ijltD3FQGo= Received: by 10.236.124.206 with SMTP id x54mr41636751yhh.112.1327004446073; Thu, 19 Jan 2012 12:20:46 -0800 (PST) Received: from [172.16.13.151] ([12.52.73.66]) by mx.google.com with ESMTPS id j11sm1270629anl.8.2012.01.19.12.20.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 12:20:45 -0800 (PST) Message-ID: <4F187B0F.90404@gmail.com> Date: Thu, 19 Jan 2012 15:20:31 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Paul Hoffman References: <4F185979.1060105@ogud.com> <4F186400.8010604@gmail.com> <7274B0C0-4BB3-4611-B495-91B123F0AECA@vpnc.org> <4F186AFB.1050702@gmail.com> <492A6661-39EF-4437-9050-4062379BD530@vpnc.org> In-Reply-To: <492A6661-39EF-4437-9050-4062379BD530@vpnc.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DNSEXT Working Group Subject: Re: [dnsext] Summary WGLC: draft-ietf-dnsext-ecdsa 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 Jan 2012 20:20:47 -0000 Hi Paul: I am not a lawyer, but I honestly do not see the IPR flags (or ghosts?) you seem to see in just about any technical suggestion. Sending just the x-coordinate of an affine elliptic curve point Q:=(x,y) has been suggested eons ago, where eon > 20 years (possibly, in Koblitz's 1985 paper). It seems that one can block any change to one's own drafts by raising fear, uncertainty, and doubt about IPR ghosts that are not there, and purportedly triggered by suggestions by others who take time to review this on technical merit and that seem ill-founded. If you believe I am wrong here, please communicate with me offline here. Why not even taking the editorial inaccuracies into account? Rene (end of discussion for me) == I cannot speak for everyone, but I can say why I didn't support it: it would possibly involve IPR hassles. The IPR hassles are not worth it here, in my opinion It is also openness, about not letting one person derail standards actions, about not unnecessarily encumbering protocols with questionable IPR if it doesn't add much value, and about making progress. On 19/01/2012 2:30 PM, Paul Hoffman wrote: > On Jan 19, 2012, at 11:11 AM, Rene Struik wrote: > >> So, was the WGLC the one in July 2011? > Yes. You replied on that thread, according to the WG archives. > >> Olaf did not reference that WGLC, >> which was eons ago (half a year). > Which part of the word "Last" are you confused about? :-) > >> Now, there seem to have been three >> versions since 2 1/2 weeks, with nothing prior for 5 1/2 months. Some >> more clarity, except a short line that seems to be out of the blue would >> be appreciated. > There was a WGLC with an end date. There were comments during WGLC. Some comments asked for changes, and there were multiple people who supported those changes. The authors (Wouter and I) made those changes. There were some comments from you that asked for extensive changes, and no one supported your request. We didn't make those changes. > >> I am curious as to why "nobody" supported squeezing down message sizes. >> Was this seriously considered? What was the technical rationale for not >> supporting my modest suggestions. > I cannot speak for everyone, but I can say why I didn't support it: it would possibly involve IPR hassles. The IPR hassles are not worth it here, in my opinion. > >> What is your rationale for not supporting this??? > If one person proposes a technical change to a spec and no one else agrees with them, it is not a good idea to make that change. > >> Shouldn't technical merit of comments be discussed openly. > You did openly discuss the technical merits of your proposal. No one supported your assertions. > >> I thought >> IETF was all about openness. > No, the IETF is about many things. It is also openness, about not letting one person derail standards actions, about not unnecessarily encumbering protocols with questionable IPR if it doesn't add much value, and about making progress. > > --Paul Hoffman > -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From mstjohns@comcast.net Thu Jan 19 13:05:07 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CE821F85F0 for ; Thu, 19 Jan 2012 13:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UVv2ybVClqS for ; Thu, 19 Jan 2012 13:05:07 -0800 (PST) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF9D21F85DB for ; Thu, 19 Jan 2012 13:05:07 -0800 (PST) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta07.emeryville.ca.mail.comcast.net with comcast id PZ3f1i0051HpZEsA7Z56Hd; Thu, 19 Jan 2012 21:05:06 +0000 Received: from Mike-PC3.comcast.net ([68.83.222.237]) by omta14.emeryville.ca.mail.comcast.net with comcast id PZ531i01N57vnMg8aZ54xq; Thu, 19 Jan 2012 21:05:06 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 19 Jan 2012 16:05:01 -0500 To: Paul Hoffman ,Rene Struik From: Michael StJohns In-Reply-To: <492A6661-39EF-4437-9050-4062379BD530@vpnc.org> References: <4F185979.1060105@ogud.com> <4F186400.8010604@gmail.com> <7274B0C0-4BB3-4611-B495-91B123F0AECA@vpnc.org> <4F186AFB.1050702@gmail.com> <492A6661-39EF-4437-9050-4062379BD530@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20120119210507.1CF9D21F85DB@ietfa.amsl.com> Cc: DNSEXT Working Group Subject: Re: [dnsext] Summary WGLC: draft-ietf-dnsext-ecdsa 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 Jan 2012 21:05:07 -0000 At 02:30 PM 1/19/2012, Paul Hoffman wrote: >> I am curious as to why "nobody" supported squeezing down message sizes. >> Was this seriously considered? What was the technical rationale for not >> supporting my modest suggestions. > >I cannot speak for everyone, but I can say why I didn't support it: it would possibly involve IPR hassles. The IPR hassles are not worth it here, in my opinion. +50.... EC point compression is a known IPR rat hole. AIRC - The group chose to slap a thick timber across the hole and glue and nail it down. Mike From rstruik.ext@gmail.com Thu Jan 19 13:14:32 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C578221F863F for ; Thu, 19 Jan 2012 13:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-B-JvJn+8Uh for ; Thu, 19 Jan 2012 13:14:32 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3721821F85D4 for ; Thu, 19 Jan 2012 13:14:32 -0800 (PST) Received: by ghrr16 with SMTP id r16so301571ghr.31 for ; Thu, 19 Jan 2012 13:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=ILICAK6k9iOYKlXh1oW5ey5JAxxKSf9+RdsJlhT0k0Q=; b=MqTt06MH/8vD1umhKuJe2gay27oVvHUVpYZDYtVEEsemdULBjzwaVgKUDkFzZXWzZU ETbSW0Q0jUsxu70rUm3LAo7I0yAGRfe79ZQo1z+mBA1wgWGzdutC5NUDgGDp1yBuj+Mr rUjht2Tzx4vK9ff+uD2hvWdaHwUATEBw1gqws= Received: by 10.101.23.12 with SMTP id a12mr12724903anj.17.1327007671871; Thu, 19 Jan 2012 13:14:31 -0800 (PST) Received: from [172.16.13.151] ([12.52.73.66]) by mx.google.com with ESMTPS id p63sm1057293yhj.22.2012.01.19.13.14.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 13:14:31 -0800 (PST) Message-ID: <4F1887AC.5080900@gmail.com> Date: Thu, 19 Jan 2012 16:14:20 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Michael StJohns References: <4F185979.1060105@ogud.com> <4F186400.8010604@gmail.com> <7274B0C0-4BB3-4611-B495-91B123F0AECA@vpnc.org> <4F186AFB.1050702@gmail.com> <492A6661-39EF-4437-9050-4062379BD530@vpnc.org> <4f188583.4839440a.0dc9.4ad6SMTPIN_ADDED@mx.google.com> In-Reply-To: <4f188583.4839440a.0dc9.4ad6SMTPIN_ADDED@mx.google.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , DNSEXT Working Group Subject: Re: [dnsext] Summary WGLC: draft-ietf-dnsext-ecdsa 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 Jan 2012 21:14:32 -0000 There may be IPR about representing Q:=(x,y) in a compressed format Q':=(x,y'), where one can *faithfully* reconstruct Q from Q' and the elliptic curve domain parameters alone (so-called lossless compression). To my knowledge, any *lossy* compression technique, including representing Q:=(x,y) by its x-coordinate x only, is not covered at all by IPR. Fear, uncertainty, and doubt should not be based on not understanding the difference between these two compression methods (or portraying everything under the universe vaguely similar suspect). Sadly, it apparently is. (But, perhaps, an "favored" way to mute discussion on technical merit and portraying the world in black-and-white terms (the nuclear option, so to speak).) -50 Rene On 19/01/2012 4:05 PM, Michael StJohns wrote: > At 02:30 PM 1/19/2012, Paul Hoffman wrote: >>> I am curious as to why "nobody" supported squeezing down message sizes. >>> Was this seriously considered? What was the technical rationale for not >>> supporting my modest suggestions. >> I cannot speak for everyone, but I can say why I didn't support it: it would possibly involve IPR hassles. The IPR hassles are not worth it here, in my opinion. > +50.... > > EC point compression is a known IPR rat hole. AIRC - The group chose to slap a thick timber across the hole and glue and nail it down. > > Mike > > -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From paul.hoffman@vpnc.org Thu Jan 19 13:59:35 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660B321F86CE for ; Thu, 19 Jan 2012 13:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTaCTusIKJu5 for ; Thu, 19 Jan 2012 13:59:35 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D08E721F86C5 for ; Thu, 19 Jan 2012 13:59:34 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0JLxTa3000913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jan 2012 14:59:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F187B0F.90404@gmail.com> Date: Thu, 19 Jan 2012 13:59:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <367F8646-093A-49E8-81A0-AA65ADFBA41A@vpnc.org> References: <4F185979.1060105@ogud.com> <4F186400.8010604@gmail.com> <7274B0C0-4BB3-4611-B495-91B123F0AECA@vpnc.org> <4F186AFB.1050702@gmail.com> <492A6661-39EF-4437-9050-4062379BD530@vpnc.org> <4F187B0F.90404@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1251.1) Cc: DNSEXT Working Group Subject: Re: [dnsext] Summary WGLC: draft-ietf-dnsext-ecdsa 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 Jan 2012 21:59:35 -0000 On Jan 19, 2012, at 12:20 PM, Rene Struik wrote: > I am not a lawyer, but I honestly do not see the IPR flags (or = ghosts?) you seem to see in just about any technical suggestion. Fine. I do see IPR issues, and so do others. Why should your single = voice be more valid than our group of voices, particularly on a subject = where none of us can prove anything either way? > It seems that one can block any change to one's own drafts by raising = fear, uncertainty, and doubt about IPR ghosts that are not there, and = purportedly triggered by suggestions by others who take time to review = this on technical merit and that seem ill-founded. You are badly misrepresenting what happened. You made a proposal *that = no one else supported*. No one "blocked" your proposed change. > If you believe I am wrong here, please communicate with me offline = here. You making this offer in public is disingenuous: you and I *have* had = this discussion offline, both when you were a Certicom employee and = afterwards. Pretending that we didn't already have the discussion, or = that having the discussion again even though neither of us have any = better facts would be valuable, is not useful to advancing this = document. --Paul Hoffman From ajs@anvilwalrusden.com Thu Jan 19 14:09:38 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F44021F86B4 for ; Thu, 19 Jan 2012 14:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnbrmTQ7C32U for ; Thu, 19 Jan 2012 14:09:36 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id E854C21F86B1 for ; Thu, 19 Jan 2012 14:09:34 -0800 (PST) Received: from crankycanuck.ca (nat-03-mht.dyndns.com [216.146.45.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D02971ECB420 for ; Thu, 19 Jan 2012 22:09:33 +0000 (UTC) Date: Thu, 19 Jan 2012 17:09:32 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120119220932.GG96608@crankycanuck.ca> References: <4F185979.1060105@ogud.com> <4F186400.8010604@gmail.com> <7274B0C0-4BB3-4611-B495-91B123F0AECA@vpnc.org> <4F186AFB.1050702@gmail.com> <492A6661-39EF-4437-9050-4062379BD530@vpnc.org> <4F187B0F.90404@gmail.com> <367F8646-093A-49E8-81A0-AA65ADFBA41A@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <367F8646-093A-49E8-81A0-AA65ADFBA41A@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Summary WGLC: draft-ietf-dnsext-ecdsa 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 Jan 2012 22:09:38 -0000 Dear colleagues, On Thu, Jan 19, 2012 at 01:59:31PM -0800, Paul Hoffman wrote: > > You are badly misrepresenting what happened. You made a proposal *that no one else supported*. No one "blocked" your proposed change. > Olafur (the shepherd for this document) is travelling, so in his stead and with my chair hat on, I want to underline what Paul said there. There was a proposal on the list; there was zero follow-up, and nobody expressed support for adding it. The document editor didn't agree it was a good idea. Therefore, the change doesn't go into the document. That's the end of the story: we don't need to debate whether there is IPR here, make charges about FUD, or anything else. There is no consensus, rough or otherwise, in favour of the change, and so it's not a candidate to be the product of the WG. Best regards, Andrew -- Andrew Sullivan ajs@crankycanuck.ca From ajs@anvilwalrusden.com Thu Jan 19 21:49:44 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58B421F85BB for ; Thu, 19 Jan 2012 21:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYWJqAT3Mebf for ; Thu, 19 Jan 2012 21:49:43 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 29DC221F85B7 for ; Thu, 19 Jan 2012 21:49:43 -0800 (PST) Received: from mail.yitter.info (unknown [100.44.91.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id AF8321ECB420 for ; Fri, 20 Jan 2012 05:49:41 +0000 (UTC) Date: Fri, 20 Jan 2012 00:49:39 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120120054939.GD4365@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 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 Jan 2012 05:49:44 -0000 Dear colleagues, This message initiates a three week Working Group Last Call on the document draft-ietf-dnsext-dnssec-bis-updates-16. LC will close on 2012-01-11 at 00:00 UTC. The WG's standard conventions, which require five reviewers who state that they have read the draft and support its publication as a necessary but not sufficient determinant of rough consensus, are in force. Please review the document and post to the list any comments you have before the close of LC. If you cannot meet that deadline, but are willing to commit to completing a review and can give me a firm date for it (and that date is within a reasonable horizon), I will announce an extension of the LC deadline. I'd appreciate it if you'd tell me of this need sooner rather than later. Specific comments are much better than generic ones, and specific comments with suggested text (if you find some text wanting) are particularly encouraged. Speaking only personally, this draft is the product of several years of WG work: the -00 of the draft was submitted in 2005. Moreover, it is the product of a lot of heated discussion and careful teasing out of the issues involved. I would be sad to discover that we could not find (rather) more than five reviewers for this document. I will be the shepherd for this document if it is sent to the IESG. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Thu Jan 19 22:09:40 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1ED221F8601; Thu, 19 Jan 2012 22:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tk2PWFBK9D-4; Thu, 19 Jan 2012 22:09:39 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id E8A2121F85FD; Thu, 19 Jan 2012 22:09:38 -0800 (PST) Received: from mail.yitter.info (unknown [100.44.91.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1F2D51ECB420; Fri, 20 Jan 2012 06:09:38 +0000 (UTC) Date: Fri, 20 Jan 2012 01:09:36 -0500 From: Andrew Sullivan To: rdroms.ietf@gmail.com Message-ID: <20120120060936.GE4365@mail.yitter.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="4SFOXa2GPu3tIq4H" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: iesg-secretary@ietf.org, dnsext@ietf.org Subject: [dnsext] Request to publish draft-ietf-dnsext-xnamercode-00 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 Jan 2012 06:09:40 -0000 --4SFOXa2GPu3tIq4H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear Ralph, This is a request to publish draft-ietf-dnsext-xnamercode-00 in the RFC series on the standards track, with a status of Proposed Standard. I attach the usual write-up for the document. Thanks and best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com --4SFOXa2GPu3tIq4H Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="proto-2012-01-20.txt" PROTO write-up for draft-ietf-dnsext-xnamercode Template version 2008-09-17 2012-01-20 (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; yes; yes. (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? It was reviewed by five DNSEXT WG reviewers who said they supported publication. It has not been reviewed to my knowledge outside DNSEXT, but it is related specifically to clarification of how the DNS protocol works. (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 specific concerns. There is no IPR disclosure related to this document as far as I am aware. (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? It is not clear. The document originally failed to reach the minimum number of reviewers during WGLC, which suggested that it has not been widely reviewed. Its recommendations, however, appear to be in line with a general agreement on the mailing list about how to clarify this issue. DNSEXT documents often do not attract as much review as we might like, but when it was announced that this document would die, more reviewers came forward in its support; nobody objected. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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? Nits checked. There are no other review criteria. (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]. References are ok. (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? The IANA Considerations section exists and may be removed at publication time. A note to this effect is included. (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? There are no such sections. (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 This memo clarifies how to set the RCODE and how to handle the AD and AA bits when processing chains of CNAMEs, DNAMEs, or any other similar (as yet uninvented) RRTYPE that performs name redirection. It addresses an ambiguity that has persisted in handling of these RRTYPEs since RFC 1034 was published. Working Group Summary This memo was reviewed by five reviewers of the DNS Extensions Working Group. It agrees with other discussions on the DNSEXT mailing list about how to handle these cases. Document Quality The memo agrees with the actual behaviour of many deployed DNS resolvers. --4SFOXa2GPu3tIq4H-- From ajs@anvilwalrusden.com Thu Jan 19 22:29:30 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25E021F8591 for ; Thu, 19 Jan 2012 22:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5CfbpumNYj8 for ; Thu, 19 Jan 2012 22:29:30 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 317D121F859B for ; Thu, 19 Jan 2012 22:29:30 -0800 (PST) Received: from mail.yitter.info (unknown [100.44.91.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4DC091ECB420 for ; Fri, 20 Jan 2012 06:29:29 +0000 (UTC) Date: Fri, 20 Jan 2012 01:29:27 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120120062927.GF4365@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] What to do with BNAME 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 Jan 2012 06:29:30 -0000 Dear colleagues, There's been a suggestion that BNAME be adopted by the WG and standardized within this WG. At the same time, we have been asked by our Area Director to be ready to wind up the WG by the spring. We are not sure that these goals are consistent with one another, and are therefore reluctant to add the draft to the WG's commitments. But there is an alternative. Those who are interested in pursuing this work could request a BOF session to investigate just this proposal, or aliasing more generally in the DNS. There is still time to prepare such a request: the cutoff date for BOFs is 2012-02-16. We look towards those who are the strongest proponents of this to organize such a BOF; we are both ready to help with the organization in regards to the IETF mechanics. Best regards, Andrew and Olafur -- Andrew Sullivan ajs@anvilwalrusden.com From dougb@dougbarton.us Thu Jan 19 22:57:20 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123E721F84B4 for ; Thu, 19 Jan 2012 22:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPhZuZy4cZEp for ; Thu, 19 Jan 2012 22:57:19 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 000E121F84A0 for ; Thu, 19 Jan 2012 22:57:18 -0800 (PST) Received: (qmail 29065 invoked by uid 399); 20 Jan 2012 06:57:16 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 20 Jan 2012 06:57:16 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F19104B.2060601@dougbarton.us> Date: Thu, 19 Jan 2012 22:57:15 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120119 Thunderbird/9.0 MIME-Version: 1.0 To: Andrew Sullivan References: <20120120062927.GF4365@mail.yitter.info> In-Reply-To: <20120120062927.GF4365@mail.yitter.info> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] What to do with BNAME 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 Jan 2012 06:57:20 -0000 On 01/19/2012 22:29, Andrew Sullivan wrote: > Dear colleagues, > > There's been a suggestion that BNAME be adopted by the WG and > standardized within this WG. I'd also like to get my CLONE draft published, one way or another. :) > At the same time, we have been asked by > our Area Director to be ready to wind up the WG by the spring. > > We are not sure that these goals are consistent with one another, and > are therefore reluctant to add the draft to the WG's commitments. But > there is an alternative. Those who are interested in pursuing this > work could request a BOF session to investigate just this proposal, or > aliasing more generally in the DNS. There is still time to prepare > such a request: the cutoff date for BOFs is 2012-02-16. I'm definitely interested, but can't attend in person. > We look towards those who are the strongest proponents of this to > organize such a BOF; we are both ready to help with the organization > in regards to the IETF mechanics. > > Best regards, > > Andrew and Olafur > -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From marka@isc.org Thu Jan 19 23:23:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468A021F85F8 for ; Thu, 19 Jan 2012 23:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvqIP-HIB3y1 for ; Thu, 19 Jan 2012 23:23:10 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id AB65421F85F6 for ; Thu, 19 Jan 2012 23:23:10 -0800 (PST) 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 07A735F98B1; Fri, 20 Jan 2012 07:22:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:902a:92d4:e011:46b7]) (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 164CF216C6B; Fri, 20 Jan 2012 07:22:49 +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 931F31BB343E; Fri, 20 Jan 2012 18:22:44 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20120120054939.GD4365@mail.yitter.info> In-reply-to: Your message of "Fri, 20 Jan 2012 00:49:39 CDT." <20120120054939.GD4365@mail.yitter.info> Date: Fri, 20 Jan 2012 18:22:44 +1100 Message-Id: <20120120072244.931F31BB343E@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 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 Jan 2012 07:23:11 -0000 5.9. Always set the CD bit on Queries This is demonstratively *bad* advice. The discussion to do with always setting CD bit on queries centered around different sets of trust anchors. If you take two validating recursive server in series with the *same* trust anchors. If you always set CD then the downstream server is vulnerable to a accidental denial of service attack if any of the authoritative servers for the zone is returning stale (will fail validation) data. C -> VR1 -> VR2 -> {A1, A2, A3 .... AN } VR1 should make CD=0 as it has no control over which of A1 ... AN, VR2 queries. By making a CD=0 query, VR2 will filter out responses from the stale server. If the response from VR2 to the CD=0 is SERVFAIL then VR1 it should make a CD=1 query in case there is a mis-configured trust anchor or bad clock. Yes, Andrew it is re-opening this subject. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From matthijs@nlnetlabs.nl Fri Jan 20 06:17:09 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73B021F84E0 for ; Fri, 20 Jan 2012 06:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdbvu3WLJCDN for ; Fri, 20 Jan 2012 06:17:08 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D62121F84FA for ; Fri, 20 Jan 2012 06:17:08 -0800 (PST) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q0KEH4cX091555 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 20 Jan 2012 15:17:05 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1327069027; bh=cG9+5JlbW8+5KDkUx57AlD4EWETczLMVNO9srCkrGN4=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=CONo5VxyKxfhls+FBuy6o1JRBvffADjmmwjbLfL4CqjhK0Ex5oATG5QH4Q8vXTFAF qBFp47SY3IN0fSwXWRbcsQO0wECWgCKVSO8LKT7hMoOu1NMupWC+iscwCLP65clYWn mT3xhvJcdu5uccZoua3IdCwdwiN/4ywNv4VXSaBo= Message-ID: <4F197760.5030809@nlnetlabs.nl> Date: Fri, 20 Jan 2012 15:17:04 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dnsext list 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.7 (open.nlnetlabs.nl [213.154.224.1]); Fri, 20 Jan 2012 15:17:05 +0100 (CET) Subject: [dnsext] An 5155 inconvenience 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 Jan 2012 14:17:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Section 8.2 of RFC 5155 states that a validator MUST ignore NSEC3 RRs with a Flag fields value other than zero or one. But in the IANA Considerations section, bits 0-6 are available for assignment. Could it be that Section 8.2 actually says that a validator MUST ignore bit 0-6 of the NSEC3 Flags field? Do you think this clarification is suitable for an errata or as text in dnssec-bis-updates? Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPGXdgAAoJEA8yVCPsQCW5BnQH/0AyeXy2MCilAfb3ZUM7JPZZ Ya6dYiWnyJo9xN9Y+iCDeKwmgkETT0xOfYyNoHgrN/7fmYsU/F0AERycfaqKkXhD xXoru5/D2t+YjdlpjsYN7CAIGkkwOcniXp4/vdA+m62fFCiC3Qavcml5P8+mKSoJ BQkDt9jU0o7Bm+MUu5AL2pzslxeROdODcOjhc/Qy9zg1lLvxCwZCpHwV0GfphFd3 wcpstycYV7b8UYpWs36CqLgEy3lMKdNVElK7hLUmY03/n5tZ5kOxoGWxhN/Hm9TB tdQqzOn7hVS8BEn5tkrmdpLskjV4cq9VCAtmhYAWJscGIPhWiyH/iRcjIINqnu0= =ZXhb -----END PGP SIGNATURE----- From ajs@anvilwalrusden.com Fri Jan 20 06:22:47 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E57B21F859E for ; Fri, 20 Jan 2012 06:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPuhXXHaez+6 for ; Fri, 20 Jan 2012 06:22:47 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 521CA21F8592 for ; Fri, 20 Jan 2012 06:22:44 -0800 (PST) Received: from mail.yitter.info (nat-03-mht.dyndns.com [216.146.45.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id AE6C51ECB420 for ; Fri, 20 Jan 2012 14:22:43 +0000 (UTC) Date: Fri, 20 Jan 2012 09:22:43 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120120142243.GE4944@mail.yitter.info> References: <20120120054939.GD4365@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120120054939.GD4365@mail.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 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 Jan 2012 14:22:47 -0000 Dear colleagues, On Fri, Jan 20, 2012 at 12:49:39AM -0500, Andrew Sullivan wrote: > Dear colleagues, > > This message initiates a three week Working Group Last Call on the > document draft-ietf-dnsext-dnssec-bis-updates-16. LC will close on > 2012-01-11 at 00:00 UTC. Sigh. When we go past the 31 at the end of January, the _month_ counter goes up. That should, of course, have been 2012-02-11 00:00+00. (I'm particularly ashamed of this one, since 01-11 is my father's birthday.) Sorry, all, and thanks to eagle-eyed Ed Lewis for nudging me. A -- Andrew Sullivan ajs@anvilwalrusden.com From Ed.Lewis@neustar.biz Fri Jan 20 06:40:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B75821F8596 for ; Fri, 20 Jan 2012 06:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.461 X-Spam-Level: X-Spam-Status: No, score=-105.461 tagged_above=-999 required=5 tests=[AWL=1.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPdIYr7Owre1 for ; Fri, 20 Jan 2012 06:40:23 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 89D8021F858A for ; Fri, 20 Jan 2012 06:40:23 -0800 (PST) Received: from nmet-lt60.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q0KEeKCc013648; Fri, 20 Jan 2012 09:40:21 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.129.98] by nmet-lt60.cis.neustar.com (PGP Universal service); Fri, 20 Jan 2012 09:40:21 -0500 X-PGP-Universal: processed; by nmet-lt60.cis.neustar.com on Fri, 20 Jan 2012 09:40:21 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F197760.5030809@nlnetlabs.nl> References: <4F197760.5030809@nlnetlabs.nl> Date: Fri, 20 Jan 2012 09:30:16 -0500 To: Matthijs Mekking From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dnsext list Subject: Re: [dnsext] An 5155 inconvenience 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 Jan 2012 14:40:24 -0000 My reading of this is - if a validator is built with RFC 5155 in mind and it sees an NSEC3 RR with a flag field "other than 0 or 1" the record has been created by a signer that conforms to a more modern specification, say, RFC 17234. (Or the signer is buggy, etc.) As such, the validator is not equipped to deal with the situation and should complain somehow instead of proceeding. At 15:17 +0100 1/20/12, Matthijs Mekking wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi, > >Section 8.2 of RFC 5155 states that a validator MUST ignore NSEC3 RRs >with a Flag fields value other than zero or one. But in the IANA >Considerations section, bits 0-6 are available for assignment. > >Could it be that Section 8.2 actually says that a validator MUST ignore >bit 0-6 of the NSEC3 Flags field? Do you think this clarification is >suitable for an errata or as text in dnssec-bis-updates? > >Best regards, > Matthijs >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.11 (GNU/Linux) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >iQEcBAEBAgAGBQJPGXdgAAoJEA8yVCPsQCW5BnQH/0AyeXy2MCilAfb3ZUM7JPZZ >Ya6dYiWnyJo9xN9Y+iCDeKwmgkETT0xOfYyNoHgrN/7fmYsU/F0AERycfaqKkXhD >xXoru5/D2t+YjdlpjsYN7CAIGkkwOcniXp4/vdA+m62fFCiC3Qavcml5P8+mKSoJ >BQkDt9jU0o7Bm+MUu5AL2pzslxeROdODcOjhc/Qy9zg1lLvxCwZCpHwV0GfphFd3 >wcpstycYV7b8UYpWs36CqLgEy3lMKdNVElK7hLUmY03/n5tZ5kOxoGWxhN/Hm9TB >tdQqzOn7hVS8BEn5tkrmdpLskjV4cq9VCAtmhYAWJscGIPhWiyH/iRcjIINqnu0= >=ZXhb >-----END PGP SIGNATURE----- >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Vote for the word of the day: "Papa"razzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate "red tape" From matthijs@nlnetlabs.nl Fri Jan 20 07:27:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280B021F850D for ; Fri, 20 Jan 2012 07:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqPRL37IxQCq for ; Fri, 20 Jan 2012 07:27:10 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2777B21F84FC for ; Fri, 20 Jan 2012 07:27:09 -0800 (PST) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q0KFR6FL036889 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 20 Jan 2012 16:27:07 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1327073228; bh=Gb7g+ZUhloDo8tj1gX/97Na5NcJ5EACgALD8dzGqFAs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qpys3y0e91bvlZsTqTYeo9a9VZk5ldk8yLwejWE3zygNRnuFBHkGHZ35j18vXbsqs fqz9ilpVNbo+CYg9a1PQjXqnfDlprxKtozBk11Dilm9IZZvxJPQSr+fosH1Do3Pd9X FDVg7ITjg/b4sfICTJDRDkb3WtkP6StOMe5kwQaI= Message-ID: <4F1987CB.9060502@nlnetlabs.nl> Date: Fri, 20 Jan 2012 16:27:07 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: Edward Lewis References: <4F197760.5030809@nlnetlabs.nl> In-Reply-To: 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.7 (open.nlnetlabs.nl [213.154.224.1]); Fri, 20 Jan 2012 16:27:07 +0100 (CET) Cc: dnsext list Subject: Re: [dnsext] An 5155 inconvenience 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 Jan 2012 15:27:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If bit 0-6 must be zero, what's the point of having them available for assignment? Best regards, Matthijs On 01/20/2012 03:30 PM, Edward Lewis wrote: > My reading of this is - if a validator is built with RFC 5155 in mind > and it sees an NSEC3 RR with a flag field "other than 0 or 1" the record > has been created by a signer that conforms to a more modern > specification, say, RFC 17234. (Or the signer is buggy, etc.) As such, > the validator is not equipped to deal with the situation and should > complain somehow instead of proceeding. > > At 15:17 +0100 1/20/12, Matthijs Mekking wrote: > Hi, > > Section 8.2 of RFC 5155 states that a validator MUST ignore NSEC3 RRs > with a Flag fields value other than zero or one. But in the IANA > Considerations section, bits 0-6 are available for assignment. > > Could it be that Section 8.2 actually says that a validator MUST ignore > bit 0-6 of the NSEC3 Flags field? Do you think this clarification is > suitable for an errata or as text in dnssec-bis-updates? > > Best regards, > Matthijs _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPGYfKAAoJEA8yVCPsQCW5XzAH/A6SoczYxU1FCMynyQSZPzvT 6nXtA89SYsB1dmEB3QRfVONmhXaRI2Ahzcvc5oqUtiMOXuFCC5Dqtu5TadKsU/+m tJv6qeUrzeqBBAjl3MmRno8wPfoCbSoQHc+H9jTCOIlDrGPaauiBVowg4zjES9eK TecyfsSrSfzmGseodp/PAXZf6fJgvFFeDRusdA8gL20P0TUzsyMB+AbvBTdfs3xk ZkMJx0xWm96rSSVtvx/CwMD4cjyQyMh/2gjHwKQZRbFiyetEgcJf2D+70TmEaPGp Y+eZ3p9CkbHB422sAk94zkhjffq/DyFjc5IiNuKlDApGuMwbW+c6jtrVGjCvbsk= =yHM2 -----END PGP SIGNATURE----- From Ed.Lewis@neustar.biz Fri Jan 20 07:33:01 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A0B21F862F for ; Fri, 20 Jan 2012 07:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.689 X-Spam-Level: X-Spam-Status: No, score=-105.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSk7E5C6tB-f for ; Fri, 20 Jan 2012 07:32:59 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2330A21F85A1 for ; Fri, 20 Jan 2012 07:32:59 -0800 (PST) Received: from nmet-lt60.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q0KFWuwf014154; Fri, 20 Jan 2012 10:32:57 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.129.98] by nmet-lt60.cis.neustar.com (PGP Universal service); Fri, 20 Jan 2012 10:32:57 -0500 X-PGP-Universal: processed; by nmet-lt60.cis.neustar.com on Fri, 20 Jan 2012 10:32:57 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F1987CB.9060502@nlnetlabs.nl> References: <4F197760.5030809@nlnetlabs.nl> <4F1987CB.9060502@nlnetlabs.nl> Date: Fri, 20 Jan 2012 10:32:54 -0500 To: Matthijs Mekking From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: Edward Lewis , dnsext list Subject: Re: [dnsext] An 5155 inconvenience 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 Jan 2012 15:33:01 -0000 Read it as: MUST BE zero for the purposes of "conformance" to RFC 5155. And/but we are open to future updates. At 16:27 +0100 1/20/12, Matthijs Mekking wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >If bit 0-6 must be zero, what's the point of having them available for >assignment? > >Best regards, > Matthijs > >On 01/20/2012 03:30 PM, Edward Lewis wrote: >> My reading of this is - if a validator is built with RFC 5155 in mind >> and it sees an NSEC3 RR with a flag field "other than 0 or 1" the record >> has been created by a signer that conforms to a more modern >> specification, say, RFC 17234. (Or the signer is buggy, etc.) As such, >> the validator is not equipped to deal with the situation and should >> complain somehow instead of proceeding. >> >> At 15:17 +0100 1/20/12, Matthijs Mekking wrote: >> Hi, >> >> Section 8.2 of RFC 5155 states that a validator MUST ignore NSEC3 RRs >> with a Flag fields value other than zero or one. But in the IANA >> Considerations section, bits 0-6 are available for assignment. >> >> Could it be that Section 8.2 actually says that a validator MUST ignore >> bit 0-6 of the NSEC3 Flags field? Do you think this clarification is >> suitable for an errata or as text in dnssec-bis-updates? >> >> Best regards, >> Matthijs >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.11 (GNU/Linux) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >iQEcBAEBAgAGBQJPGYfKAAoJEA8yVCPsQCW5XzAH/A6SoczYxU1FCMynyQSZPzvT >6nXtA89SYsB1dmEB3QRfVONmhXaRI2Ahzcvc5oqUtiMOXuFCC5Dqtu5TadKsU/+m >tJv6qeUrzeqBBAjl3MmRno8wPfoCbSoQHc+H9jTCOIlDrGPaauiBVowg4zjES9eK >TecyfsSrSfzmGseodp/PAXZf6fJgvFFeDRusdA8gL20P0TUzsyMB+AbvBTdfs3xk >ZkMJx0xWm96rSSVtvx/CwMD4cjyQyMh/2gjHwKQZRbFiyetEgcJf2D+70TmEaPGp >Y+eZ3p9CkbHB422sAk94zkhjffq/DyFjc5IiNuKlDApGuMwbW+c6jtrVGjCvbsk= >=yHM2 >-----END PGP SIGNATURE----- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Vote for the word of the day: "Papa"razzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate "red tape" From benlaurie@gmail.com Fri Jan 20 07:34:59 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66CB21F863C for ; Fri, 20 Jan 2012 07:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRF0gtOglZDU for ; Fri, 20 Jan 2012 07:34:59 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5DA21F85A1 for ; Fri, 20 Jan 2012 07:34:59 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so488376vcb.31 for ; Fri, 20 Jan 2012 07:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NdMdPoaF5BHwzUN1xT46AGVgX0zy24liSQ1CR3W4SQU=; b=tcqyRkMd2wry1AhKbYP2Y/AZaVgfgCduIuOA+myfnb3H64C089zOy9tNjIqsKB6Wn2 YBPkwF8tYCHAIni3vBX24tfeefrlHOLma+g9R4urtp45Vq/IdM56jrWhaNk6XVkjzuhR T/l1sqm9ntjuT5lVDuTiBHymBDfx6fbNF5wdc= MIME-Version: 1.0 Received: by 10.52.69.233 with SMTP id h9mr12605768vdu.84.1327073695115; Fri, 20 Jan 2012 07:34:55 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.52.28.171 with HTTP; Fri, 20 Jan 2012 07:34:55 -0800 (PST) In-Reply-To: <4F1987CB.9060502@nlnetlabs.nl> References: <4F197760.5030809@nlnetlabs.nl> <4F1987CB.9060502@nlnetlabs.nl> Date: Fri, 20 Jan 2012 15:34:55 +0000 X-Google-Sender-Auth: 8DPn__ynkQh1uJUAHqfZG8Ra7hw Message-ID: From: Ben Laurie To: Matthijs Mekking Content-Type: text/plain; charset=ISO-8859-1 Cc: Edward Lewis , dnsext list Subject: Re: [dnsext] An 5155 inconvenience 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 Jan 2012 15:35:00 -0000 On Fri, Jan 20, 2012 at 3:27 PM, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > If bit 0-6 must be zero, what's the point of having them available for > assignment? If they were not forced to some known state before assignment, then they would not be available! From ogud@ogud.com Fri Jan 20 08:00:21 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAEF21F868C; Fri, 20 Jan 2012 08:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.422 X-Spam-Level: X-Spam-Status: No, score=-106.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aimgopXhIg3Q; Fri, 20 Jan 2012 08:00:19 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id EA27821F84DC; Fri, 20 Jan 2012 08:00:18 -0800 (PST) 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 q0KG0Fp2014449; Fri, 20 Jan 2012 11:00:16 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F198F8E.5060906@ogud.com> Date: Fri, 20 Jan 2012 11:00:14 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: iesg-secretary@ietf.org, int-ads@tools.ietf.org Content-Type: multipart/mixed; boundary="------------000004010101040101010505" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dnsext@ietf.org Subject: [dnsext] Publication Request 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 Jan 2012 16:00:21 -0000 This is a multi-part message in MIME format. --------------000004010101040101010505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ralph, Jari, DNSEXT requests the publication of: http://tools.ietf.org/html/draft-ietf-dnsext-ecdsa-04 attached is the document writup Olafur --------------000004010101040101010505 Content-Type: text/plain; name="ecdsa-writeup.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ecdsa-writeup.txt" Changes are expected over time. This 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? Olafur Gudmundsson is the document shepherd. He has reviewed this version and it is ready for publication. (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? This document has been through a number of discussions on the working group mailing list, including a long WGLC. During the last call few documentation issues were raised and addressed by the editors. We had many reviewers of this document, the document shepherd has no issues with the review. (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. There has been an IPR filed against this document like any other ECC related document. This IPR is similar to others filed thus this document should be processed the same way as the other documents that have been published with similar IPR filed against them by the same party. The WG did not discuss the IPR filing. https://datatracker.ietf.org/ipr/1597/ (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? Strong Consensus, the WG understand the need for this specifcation to be published but not all of the members of the working group may understand exactly how ECC works. (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? ID nits have all been addressed and this version is id-nit free. no other reviews are needed. (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]. yes. (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, the document updates existing 2 registires. (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? No such section. (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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Working group has not had any issues with this document, there was some disucussion during the drafts adoption if this was needed. The document editors have been good about addressing any points raised. Consensus is solid. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The document is well written, there are at least 2 implementations and they interoperate. The document has been stable since being adopted by the working group most of the versions have been to incorporate textual changes of the clarificaiton kind, and the last one addressed ID-nits. --------------000004010101040101010505-- From Ed.Lewis@neustar.biz Fri Jan 20 08:55:46 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5D321F8646 for ; Fri, 20 Jan 2012 08:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.84 X-Spam-Level: X-Spam-Status: No, score=-105.84 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iveQ7xKNdzO4 for ; Fri, 20 Jan 2012 08:55:46 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id EA52621F863B for ; Fri, 20 Jan 2012 08:55:45 -0800 (PST) Received: from nmet-lt60.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q0KGtgWw014881; Fri, 20 Jan 2012 11:55:43 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.129.98] by nmet-lt60.cis.neustar.com (PGP Universal service); Fri, 20 Jan 2012 11:55:43 -0500 X-PGP-Universal: processed; by nmet-lt60.cis.neustar.com on Fri, 20 Jan 2012 11:55:43 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20120120142243.GE4944@mail.yitter.info> References: <20120120054939.GD4365@mail.yitter.info> <20120120142243.GE4944@mail.yitter.info> Date: Fri, 20 Jan 2012 11:55:22 -0500 To: Andrew Sullivan From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 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 Jan 2012 16:55:46 -0000 Comments. In 2005 it was too soon to publish, now it is not. And at this point there may be more and more wrinkles in the DNSSEC specs, but we need to get out at least this (first) update. Some comments: Pressence has a presence in the document. It shouldn't (the spelling, I mean). 5.9's title is misleading. The content is good, it's about answering from cache in the face of a CD query. But "always doing CD" only applies to elements that will do their own validation. 5.4 could optionally make the point that a validator that expects all signatures to be good and/or all chains to work is vulnerable to malicious insertions of gibberish-based signatures. It's harder to construct a good chain than a false chain. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Vote for the word of the day: "Papa"razzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate "red tape" From iesg-secretary@ietf.org Mon Jan 23 10:23:18 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A39F21F86EB; Mon, 23 Jan 2012 10:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3Umlxm50e2B; Mon, 23 Jan 2012 10:23:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39BD21F863D; Mon, 23 Jan 2012 10:23:17 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120123182317.28636.48689.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2012 10:23:17 -0800 Cc: dnsext@ietf.org Subject: [dnsext] Last Call: (xNAME RCODE and Status Bits Clarification) 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: Mon, 23 Jan 2012 18:23:18 -0000 The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'xNAME RCODE and Status Bits Clarification' 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 2012-02-06. 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 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-xnamercode/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-xnamercode/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue Jan 24 06:45:20 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FE721F85EA; Tue, 24 Jan 2012 06:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X56jWZukOJTX; Tue, 24 Jan 2012 06:45:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93DD21F858D; Tue, 24 Jan 2012 06:45:19 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120124144519.30604.84440.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2012 06:45:19 -0800 Cc: dnsext@ietf.org Subject: [dnsext] Last Call: (Elliptic Curve DSA for DNSSEC) to Informational RFC 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: Tue, 24 Jan 2012 14:45:20 -0000 The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Elliptic Curve DSA for DNSSEC' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-ecdsa/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-ecdsa/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1597/ From d3e3e3@gmail.com Tue Jan 24 19:48:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F1F11E80AF for ; Tue, 24 Jan 2012 19:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.297 X-Spam-Level: X-Spam-Status: No, score=-104.297 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1iM6HbR-0Xy for ; Tue, 24 Jan 2012 19:48:24 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 580D711E80A5 for ; Tue, 24 Jan 2012 19:48:24 -0800 (PST) Received: by lahl5 with SMTP id l5so906185lah.31 for ; Tue, 24 Jan 2012 19:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=tVjnHpd5h/4+tqT9+p7RejwKTXwgq509qEgoPEhNp2k=; b=Z9x/OV8u1ihHrveKijZicFWG2+8yzUJ2UZNXVTNXLS8YgilM7L48Gby+vwARUCRSfH yWv3Pr0AP0j621Ea6mSq/cx093daTp65ShH9TbqSPg7fzFVKjquLHPmzBrbjJQJRoI08 GnUu2VHNGufo4p/+jPpubbuRTTKK0DMvG/fx8= Received: by 10.152.148.227 with SMTP id tv3mr7892559lab.15.1327463303351; Tue, 24 Jan 2012 19:48:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.100.131 with HTTP; Tue, 24 Jan 2012 19:48:02 -0800 (PST) In-Reply-To: References: <20120123182317.28636.48689.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120123103439.0a87a228@resistor.net> From: Donald Eastlake Date: Tue, 24 Jan 2012 22:48:02 -0500 Message-ID: To: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [dnsext] Fwd: Last Call: (xNAME RCODE and Status Bits Clarification) 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: Wed, 25 Jan 2012 03:48:25 -0000 Sorry, didn't cc DNSEXT... ---------- Forwarded message ---------- From: Donald Eastlake Date: Tue, Jan 24, 2012 at 10:46 PM Subject: Re: Last Call: (xNAME RCODE and Status Bits Clarification) to Proposed Standard To: SM Cc: ietf@ietf.org Hi, On Mon, Jan 23, 2012 at 2:04 PM, SM wrote: > At 10:23 23-01-2012, The IESG wrote: >> >> The IESG has received a request from the DNS Extensions WG (dnsext) to >> consider the following document: >> - 'xNAME RCODE and Status Bits Clarification' >> =A0 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 2012-02-06. Exceptionally, comments may b= e > > > From the Introduction Section: > > > =A0"This document clarifies, in the case of such redirected queries, > =A0 how the RCODE and status bits correspond to the initial query > =A0 cycle (where the (first) xNAME was detected) and subsequent or > =A0 final query cycles." > > From Section 2.1: > > =A0"[RFC1035] states that the AA bit is to be set based on whether the > =A0 server providing the answer with the first owner name in the answer > =A0 section is authoritative. =A0This specification of the AA bit has not > =A0 been changed. =A0This specification of the AA bit has not been change= d." Actually, the last sentence above is not duplicated in the draft. > And Section 2.2: > > =A0"[RFC4035] unambiguously states that the AD bit is to be set in a DNS > =A0 response header only if the DNSSEC enabled server believes all RRs in > =A0 the answer and authority sections of that response to be authentic. > =A0 This specification of the AD bit has not been changed." > > It is not clear to me what is being clarified about the status bits. This draft brings together the aspects of the AA, AD, and RCODE bits related to xNAME RR query cycles and expresses them clearly and succinctly. As such it has been approved by the DNSEXT WG. I do not believe that text has to make a change to be a clarification. > In Section 3: > > =A0 =A0"The RCODE in the ultimate DNS response > =A0 =A0 MUST BE set based on the final query cycle leading to that > =A0 =A0 response." > > Shouldn't the "BE" be lowercased? Yes, thanks for pointing this out. "BE" should probably be lowercase. > The status of the memo suggests sending comments to > namedroppers@ops.ietf.org. =A0Is that IETF mailing list still being used = by > DNSEXT? That was the mailing list at the time of the -00 personal draft version. Sorry I missed updating the mailing list reference somewhere along the way. 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 > Regards, > -sm From sm@resistor.net Tue Jan 24 20:43:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC64811E80AE for ; Tue, 24 Jan 2012 20:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCnLCW1BY4oO for ; Tue, 24 Jan 2012 20:43:08 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD5311E80A5 for ; Tue, 24 Jan 2012 20:43:08 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0P4h0US002015; Tue, 24 Jan 2012 20:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327466586; i=@resistor.net; bh=G+OnbFDA/ripELmz81gqfI0cpeA+YV9E8QeA991agQw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=AbQdu4XMwpdWY5xch/Gn7tMXygd2kZ1JgypKYAV2k+ztHEvl7t00/aZrCNZL5zplW Q3J8HGfSrCxJS4Fe29xV7OWlSNDazcnrFB1VR2F5jAl4oRKPusjaC9KDcYj2BUDlbO jh3ViaZjgDB1m5zS1LWmicugUhAiP3+Q3HdYaw/I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327466586; i=@resistor.net; bh=G+OnbFDA/ripELmz81gqfI0cpeA+YV9E8QeA991agQw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=xiAZiRVdFBuXJhM4wTzdH5RkWwYj1ppxqp99Ct1J2Am62X4bb7jUkS8mxJJutm48W O9wugOciJDVPIWX1HCzcEhDgmTqeAoIjCJAEzERL2/37s4NtK+IXSF3HWTvtdrOeis JyMJ0+euUa50KaESB76FeZWDU5aCyqMkN+aStJDQ= Message-Id: <6.2.5.6.2.20120124203632.09c401a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 24 Jan 2012 20:39:45 -0800 To: Donald Eastlake From: SM In-Reply-To: References: <20120123182317.28636.48689.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120123103439.0a87a228@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] Last Call: (xNAME RCODE and Status Bits Clarification) 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: Wed, 25 Jan 2012 04:43:12 -0000 Hi Donald, At 19:46 24-01-2012, Donald Eastlake wrote: >Actually, the last sentence above is not duplicated in the draft. Sorry about that; the mistake is at my end. >This draft brings together the aspects of the AA, AD, and RCODE bits >related to xNAME RR query cycles and expresses them clearly and >succinctly. As such it has been approved by the DNSEXT WG. I do not >believe that text has to make a change to be a clarification. Thanks for the clarification. Regards, -sm From wouter@nlnetlabs.nl Wed Jan 25 03:46:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E9D21F85B4 for ; Wed, 25 Jan 2012 03:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVtx8gI5apdB for ; Wed, 25 Jan 2012 03:46:25 -0800 (PST) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by ietfa.amsl.com (Postfix) with ESMTP id 12B6421F85AF for ; Wed, 25 Jan 2012 03:46:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 3069458CC7 for ; Wed, 25 Jan 2012 12:46:23 +0100 (CET) Received: from [192.168.254.3] (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 298F05845B for ; Wed, 25 Jan 2012 12:46:18 +0100 (CET) Message-ID: <4F1FEB8D.1080703@nlnetlabs.nl> Date: Wed, 25 Jan 2012 12:46:21 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120120054939.GD4365@mail.yitter.info> <20120120142243.GE4944@mail.yitter.info> 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.2 at rotring X-Virus-Status: Clean Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 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 Jan 2012 11:46:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have reviewed, carefully, and support publication. Some (additional) comments, they have little substance. The section and appendix on CD bits are long. Not wrong, but long. With the root trust anchor deployed, not having a covering trust anchor is unlikely. The last validating resolver is the one that can be trusted, upstream validating resolvers are connected via some network transport, and trust may therefore not be advisable. Section 6.2 is correct. But its tone is loose. It is about lenient acceptance of the SEP flag. Please say that, or say that the proper setting of the SEP flag is defined in its RFC. Thanks to Sam, David and Rob for editing. Best regards, Wouter On 01/20/2012 05:55 PM, Edward Lewis wrote: > Comments. > > In 2005 it was too soon to publish, now it is not. And at this point > there may be more and more wrinkles in the DNSSEC specs, but we need to > get out at least this (first) update. > > Some comments: > > Pressence has a presence in the document. It shouldn't (the spelling, I > mean). > > 5.9's title is misleading. The content is good, it's about answering > from cache in the face of a CD query. But "always doing CD" only > applies to elements that will do their own validation. > > 5.4 could optionally make the point that a validator that expects all > signatures to be good and/or all chains to work is vulnerable to > malicious insertions of gibberish-based signatures. It's harder to > construct a good chain than a false chain. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPH+uMAAoJEJ9vHC1+BF+NnZYQAIsY6q3t5ogVfOwtt3fBy1og YFwK69nmP8B/SBmJjaXgQIkevBS0lOOqWvnwpGo2moxZfmDvNVHIZqlRv1Yab6NQ bsWCGP9JfgrGd1l8mqfO08yDOGMcGAZSNsgToa+2cG9zyLfBzowZOx0hAmRXp4bQ Yclz4zexSUxeCYSIF6I73xWJ2E61Ld+SxLfS2PdazIVF6NPPj1lek5IpqZ+mk3gy jSRLUQnm70vDEoS7uosCQfkpHyFzwrjEWdaVTHG7IBNiZ1J8fO4qSob0+44lqr4O LZcnCybQvcb43324321STQaCer+QScvl6UJymbU+YZS9ALO00gVhu2oDYslV+XOC jA39v5ssTUAA4BPHf3x6D7oPU39nz/j6sFEw5Gvoj2rskaWex0WNDeLA4+i5HzV0 RvevpjnGvE0yrcqxIu9ZVwOKBAqTp8HnRyedC3+4PH9mOuT+RxTADjGySdZOREcf +mSgGsoHkEIMjl0v1+S5bpdyq8dGNLn2kojjH8vm5e9HFKu4ITH10MPUiyOzvDf1 U4akvAk13k5CWiHPbFJX92uUgQ6C1Kd6l6u62wEFFAayv68aejIHn3CZQpTdmXTp K5NFlVISL158i1KZ4jtNK+Em4Hk0YJvNsDdMzSUeaJrwtIXSuyMdfSenCfmaHEkl InejDsWOP+VLUJ5+zIOI =UJX8 -----END PGP SIGNATURE----- From ajs@anvilwalrusden.com Fri Jan 27 13:39:31 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADC221F8631 for ; Fri, 27 Jan 2012 13:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ9xVTNtGYuk for ; Fri, 27 Jan 2012 13:39:31 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D5F0B21F8675 for ; Fri, 27 Jan 2012 13:39:30 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0FB991ECB41F for ; Fri, 27 Jan 2012 21:39:30 +0000 (UTC) Date: Fri, 27 Jan 2012 16:39:28 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120127213928.GI17728@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] WG state reminder 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, 27 Jan 2012 21:39:31 -0000 Summary: reviews needed on draft-ietf-dnsext-dnssec-bis-updates, draft-srose-dnssec-registry-update-00 and draft-srose-dnssec-algo-imp-status-00. Dear colleagues, Ed Lewis made an excellent suggestion for some updates on the state of the WG work, so that it's clear to people what's outstanding. Here's what I know. We have two documents, draft-srose-dnssec-registry-update-00 and draft-srose-dnssec-algo-imp-status-00, that are not yet officially WG documents but could turn into them at any time. They exist in order to fix the problems with draft-ietf-dnsext-dnssec-registry-fixes (which is officially in IESG processing but is effectively dead). I requested on 9 January that people who reacted to registry-fixes respond to those documents. See http://www.ietf.org/mail-archive/web/dnsext/current/msg12076.html. draft-ietf-dnsext-dnssec-bis-updates is in WGLC now. The LC ends on 11 February. (see http://www.ietf.org/mail-archive/web/dnsext/current/msg12129.html and http://www.ietf.org/mail-archive/web/dnsext/current/msg12135.html). We have had three reviews, two of which made suggestions about some changes but generally supported publication, and one of which appears opposed to publication. More reviews are urgently needed, please. draft-ietf-dnsext-rfc2671bis-edns0 completed WGLC and is waiting for the shepherd to write the PROTO write-up and request publication. draft-ietf-dnsext-dnssec-algo-signal completed a WGLC under its (apponted, non-WG chair) shepherd some time ago, but there have been comments since. The shepherd was appointed because both of the WG co-chairs, in their employment, reported to one of the document authors. The appointed shephed is busy. Given that I am no longer reporting to the author in question in my employment, I wonder whether people still have a concern here. Comments are welcome. draft-ietf-dnsext-aliasing-requirements expired. draft-ietf-dnsext-ecdsa is in IETF Last Call. draft-ietf-dnsext-xnamercode is in IETF Last Call. draft-ietf-dnsext-rfc2672bis-dname seems to be hung up in the IESG. I have been following up on this matter. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From suruti94@gmail.com Fri Jan 27 18:21:37 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CEC21F858F for ; Fri, 27 Jan 2012 18:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.109 X-Spam-Level: X-Spam-Status: No, score=-3.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uenYpotzjnmN for ; Fri, 27 Jan 2012 18:21:36 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B19F021F8589 for ; Fri, 27 Jan 2012 18:21:36 -0800 (PST) Received: by obbwc12 with SMTP id wc12so2823929obb.31 for ; Fri, 27 Jan 2012 18:21:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=yKqXpu1kOSJmsWsyig3eBCFl87yxj3utcqiSA1GR3Ls=; b=iQAzev8P51/aybjaDu6NbVw0BKqZozR+0f/BNeZ5wgdzsXNxDOmxvrlwP9VPcNtmlz bZg4WFdP7jH60NkDM7K2lTG93c+SOX/AL5eRZFMNdWJp8zFRKtKCIR6ttbOG2c5ymYoL XkTT+3Vnite/qar6h6sAlaMGgTOh77DfNLURM= MIME-Version: 1.0 Received: by 10.182.36.106 with SMTP id p10mr8815911obj.55.1327717295274; Fri, 27 Jan 2012 18:21:35 -0800 (PST) Received: by 10.182.147.105 with HTTP; Fri, 27 Jan 2012 18:21:35 -0800 (PST) In-Reply-To: <20120120054939.GD4365@mail.yitter.info> References: <20120120054939.GD4365@mail.yitter.info> Date: Fri, 27 Jan 2012 18:21:35 -0800 Message-ID: From: Mohan Parthasarathy To: DNSEXT Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 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, 28 Jan 2012 02:21:37 -0000 I read the draft and support publication of the draft. Here are a few comments... - Section 4.4 Insecure Delegation proofs last sentence is very confusing. An example as to what attack this is describing would be helpful to the implementer. - Section 5.7 setting the AD bit on queries. Is CD=3D0,DO=3D0 in the query same as AD=3D1,DO=3D0 ? If so, why do we need two ways ? I might have missed the discussion on this earlier. If there is a valid reason, that needs to be stated explicitly as to why we are introducing this new option. - The "Security Considerations" section says: This document adds two cryptographic features to the core DNSSEC proto= col. Is this referring to the algorithms mentioned in section 2.2 ( which actually lists three) or something else ? -mohan On Thu, Jan 19, 2012 at 9:49 PM, Andrew Sullivan w= rote: > Dear colleagues, > > This message initiates a three week Working Group Last Call on the > document draft-ietf-dnsext-dnssec-bis-updates-16. =A0LC will close on > 2012-01-11 at 00:00 UTC. > > The WG's standard conventions, which require five reviewers who state > that they have read the draft and support its publication as a > necessary but not sufficient determinant of rough consensus, are in > force. =A0Please review the document and post to the list any comments > you have before the close of LC. =A0If you cannot meet that deadline, > but are willing to commit to completing a review and can give me a > firm date for it (and that date is within a reasonable horizon), I > will announce an extension of the LC deadline. =A0I'd appreciate it if > you'd tell me of this need sooner rather than later. =A0Specific > comments are much better than generic ones, and specific comments with > suggested text (if you find some text wanting) are particularly > encouraged. > > Speaking only personally, this draft is the product of several years > of WG work: the -00 of the draft was submitted in 2005. =A0Moreover, it > is the product of a lot of heated discussion and careful teasing out > of the issues involved. =A0I would be sad to discover that we could not > find (rather) more than five reviewers for this document. > > I will be the shepherd for this document if it is sent to the IESG. > > Best regards, > > Andrew > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From marka@isc.org Fri Jan 27 21:20:56 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D2B21F85BD for ; Fri, 27 Jan 2012 21:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPGc9Zzufhnx for ; Fri, 27 Jan 2012 21:20:56 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1FF21F8584 for ; Fri, 27 Jan 2012 21:20:55 -0800 (PST) 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 137C55F98A2; Sat, 28 Jan 2012 05:20:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:2d63:f876:b008:591a]) (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 DCBEB216C6B; Sat, 28 Jan 2012 05:20:32 +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 618CE1C32BFA; Sat, 28 Jan 2012 16:20:29 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <20120120054939.GD4365@mail.yitter.info> In-reply-to: Your message of "Fri, 27 Jan 2012 18:21:35 -0800." Date: Sat, 28 Jan 2012 16:20:29 +1100 Message-Id: <20120128052029.618CE1C32BFA@drugs.dv.isc.org> Cc: DNSEXT Working Group Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 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, 28 Jan 2012 05:20:56 -0000 In message , Mohan Parthasarathy writes: > - Section 5.7 setting the AD bit on queries. Is CD=0,DO=0 in the query > same as AD=1,DO=0 ? The question doesn't make sense. AD=0,DO=1 and AD=1,DO=1 produce the same result. AD=0,DO=0 and AD=1,DO=0 produce different results. AD=0,DO=0 and AD=0,DO=1 produce different results. AD=1,DO=0 and AD=0,DO=1 produce different results. > missed the discussion on this earlier. If there is a valid reason, > that needs to be stated explicitly as to why we are introducing this > new option. Section 5.7 explains why this option exists. This allows a requestor to indicate that it understands the AD bit without also requesting DNSSEC data via the DO bit. Examples of AD=1 vs DO=1. % dig +adflag soa . +noauth +noadd ; <<>> DiG 9.7.3-P3 <<>> +adflag soa . +noauth +noadd ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41997 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN SOA ;; ANSWER SECTION: . 86382 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2012012701 1800 900 604800 86400 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jan 28 16:03:34 2012 ;; MSG SIZE rcvd: 285 % dig +dnssec soa . +noauth +noadd ; <<>> DiG 9.7.3-P3 <<>> +dnssec soa . +noauth +noadd ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61859 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;. IN SOA ;; ANSWER SECTION: . 86372 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2012012701 1800 900 604800 86400 . 86372 IN RRSIG SOA 8 0 86400 20120203000000 20120126230000 51201 . nhFWtVAAdecUyYiGqvYYLprczaXbhsR+XK2S+OPBrBWMAk9fPyNjRH7A rSu7I1qIBNstxAlUJ/ncn+lL5o88wDD2PZW4GXolzFc3LslvmyEcEhVe wHhPETDJEsR9rrpx1yt1o5EqhjzBrQNT4FPbmqse0z+r9v9uPCZlB+KQ OvE= ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jan 28 16:03:44 2012 ;; MSG SIZE rcvd: 612 % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From suruti94@gmail.com Fri Jan 27 22:11:44 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A436621F85E7 for ; Fri, 27 Jan 2012 22:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULkgaMdZXfdu for ; Fri, 27 Jan 2012 22:11:43 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B387721F858F for ; Fri, 27 Jan 2012 22:11:43 -0800 (PST) Received: by qcsf16 with SMTP id f16so1551116qcs.31 for ; Fri, 27 Jan 2012 22:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Dp9BckQPNagW1Iscd+vPcXzCAniTwMbZTM2ahaPuDpo=; b=iO/zCTkSYqSC6dW6AtA+Bz4mLQTsGagZ4a1vQI+Ro3arxaPJjoCes+XjUo0MQWEqA6 QaEbJ3iOuj9xi9sVP/5j0x6MQqIlnNE2msd6yHFeJu9Rs2VKBgxSb03UPNi0vqzuwKtq PUSdycEotroYvCXsUN63I3/x+m+Zs/ZmdIO7Q= MIME-Version: 1.0 Received: by 10.229.105.159 with SMTP id t31mr3637197qco.57.1327731103193; Fri, 27 Jan 2012 22:11:43 -0800 (PST) Received: by 10.229.20.193 with HTTP; Fri, 27 Jan 2012 22:11:43 -0800 (PST) In-Reply-To: <20120128052029.618CE1C32BFA@drugs.dv.isc.org> References: <20120120054939.GD4365@mail.yitter.info> <20120128052029.618CE1C32BFA@drugs.dv.isc.org> Date: Fri, 27 Jan 2012 22:11:43 -0800 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DNSEXT Working Group Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 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, 28 Jan 2012 06:11:44 -0000 On Fri, Jan 27, 2012 at 9:20 PM, Mark Andrews wrote: > > In message > , Mohan Parthasarathy writes: > >> - Section 5.7 setting the AD bit on queries. Is CD=3D0,DO=3D0 in the que= ry >> same as AD=3D1,DO=3D0 ? > > The question doesn't make sense. > > AD=3D0,DO=3D1 and AD=3D1,DO=3D1 produce the same result. > AD=3D0,DO=3D0 and AD=3D1,DO=3D0 produce different results. > AD=3D0,DO=3D0 and AD=3D0,DO=3D1 produce different results. > AD=3D1,DO=3D0 and AD=3D0,DO=3D1 produce different results. > Thanks for the clarification. I realized after I posted that not setting CD and DO is pre-DNSSEC. >> missed the discussion on this earlier. If there is a valid reason, >> that needs to be stated explicitly as to why we are introducing this >> new option. > > Section 5.7 explains why this option exists. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This allows a requestor to indicate that i= t understands > =A0 the AD bit without also requesting DNSSEC data via the DO bit. > > So, "understands" here means "Please do the validation for me " ? Then, is CD=3D1, AD=3D1 a invalid option ? So, there are implementations out there that want to know whether validation was successful or not but just not want to handle any DNSSEC records ? My question was more on what prompted the addition of this new feature ? -mohan > Examples of AD=3D1 vs DO=3D1. > > % dig +adflag soa . +noauth +noadd > > ; <<>> DiG 9.7.3-P3 <<>> +adflag soa . +noauth +noadd > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41997 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IN =A0 =A0 = =A0SOA > > ;; ANSWER SECTION: > . =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 86382 =A0 IN =A0 =A0 =A0SOA= =A0 =A0 a.root-servers.net. nstld.verisign-grs.com. 2012012701 1800 900 60= 4800 86400 > > ;; Query time: 2 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sat Jan 28 16:03:34 2012 > ;; MSG SIZE =A0rcvd: 285 > > % dig +dnssec soa . +noauth +noadd > > ; <<>> DiG 9.7.3-P3 <<>> +dnssec soa . +noauth +noadd > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61859 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IN =A0 =A0 = =A0SOA > > ;; ANSWER SECTION: > . =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 86372 =A0 IN =A0 =A0 =A0SOA= =A0 =A0 a.root-servers.net. nstld.verisign-grs.com. 2012012701 1800 900 60= 4800 86400 > . =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 86372 =A0 IN =A0 =A0 =A0RRS= IG =A0 SOA 8 0 86400 20120203000000 20120126230000 51201 . nhFWtVAAdecUyYiG= qvYYLprczaXbhsR+XK2S+OPBrBWMAk9fPyNjRH7A rSu7I1qIBNstxAlUJ/ncn+lL5o88wDD2PZ= W4GXolzFc3LslvmyEcEhVe wHhPETDJEsR9rrpx1yt1o5EqhjzBrQNT4FPbmqse0z+r9v9uPCZl= B+KQ OvE=3D > > ;; Query time: 1 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sat Jan 28 16:03:44 2012 > ;; MSG SIZE =A0rcvd: 612 > > % > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org From marka@isc.org Sat Jan 28 05:43:53 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FBA21F8576 for ; Sat, 28 Jan 2012 05:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2hCJftNGYXl for ; Sat, 28 Jan 2012 05:43:52 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2237321F853B for ; Sat, 28 Jan 2012 05:43:49 -0800 (PST) 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 0200FC9478; Sat, 28 Jan 2012 13:43:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:69a2:4c28:157f:527e]) (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 67BED216C6B; Sat, 28 Jan 2012 13:43: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 819221C33944; Sun, 29 Jan 2012 00:43:31 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <20120120054939.GD4365@mail.yitter.info> <20120128052029.618CE1C32BFA@drugs.dv.isc.org> In-reply-to: Your message of "Fri, 27 Jan 2012 22:11:43 -0800." Date: Sun, 29 Jan 2012 00:43:31 +1100 Message-Id: <20120128134331.819221C33944@drugs.dv.isc.org> Cc: DNSEXT Working Group Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 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, 28 Jan 2012 13:43:53 -0000 In message , Mohan Parthasarathy writes: > On Fri, Jan 27, 2012 at 9:20 PM, Mark Andrews wrote: > > > > In message l.com> > > , Mohan Parthasarathy writes: > > > >> - Section 5.7 setting the AD bit on queries. Is CD=0,DO=0 in the que= > ry > >> same as AD=1,DO=0 ? > > > > The question doesn't make sense. > > > > AD=0,DO=1 and AD=1,DO=1 produce the same result. > > AD=0,DO=0 and AD=1,DO=0 produce different results. > > AD=0,DO=0 and AD=0,DO=1 produce different results. > > AD=1,DO=0 and AD=0,DO=1 produce different results. > > > Thanks for the clarification. I realized after I posted that not > setting CD and DO is pre-DNSSEC. > > >> missed the discussion on this earlier. If there is a valid reason, > >> that needs to be stated explicitly as to why we are introducing this > >> new option. > > > > Section 5.7 explains why this option exists. > > > > This allows a requestor to indicate that i= > t understands > > the AD bit without also requesting DNSSEC data via the DO bit. > > > > > So, "understands" here means "Please do the validation for me " ? > Then, is CD=1, AD=1 a invalid option ? No. AD will be 1 if the answer + authority sections come from cached data that has validated as secure. That said I don't think there is much use unless you are trying to check if a lookup failure was due to DNSSEC errors. > So, there are implementations out there that want to know whether > validation was successful or not but just not want to handle any > DNSSEC records? I will put it this way. I doubt if there is a application that cares about AD that *wants* the DNSSEC records. At the moment they have no choice unless they are using the draft. > My question was more on what prompted the addition of this new feature ? 1. It reduces the response size. 2. You can apply DNS64, NXDOMAIN redirection, bad site filtering, etc. with AD=1 which you can't with DO=1. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From suruti94@gmail.com Sun Jan 29 18:12:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621AB21F84BF for ; Sun, 29 Jan 2012 18:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVvpYQglrLvN for ; Sun, 29 Jan 2012 18:12:14 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B476821F8471 for ; Sun, 29 Jan 2012 18:12:14 -0800 (PST) Received: by qan41 with SMTP id 41so110142qan.10 for ; Sun, 29 Jan 2012 18:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ITh6O3D7dK+oCGYH7Bdaq8wnjkYxfxjMMNrfYIcHajk=; b=x+EIAiAzFqlYkjGwSMci8MX/YZnbpl0H0Xc/VV/iWfRX7g0leNcOPh3zE3uSU18iWG KLwP+uLwjQtx9PwKu6aIRQJcH94aRaJHl3bNMTAlT1rBMbOmfaYpwXWdU0VSKAnk+TTR +LIORzDAkoneso7bDkk65uSqyTZvoTLcZiz9E= MIME-Version: 1.0 Received: by 10.224.198.3 with SMTP id em3mr18775221qab.23.1327889534195; Sun, 29 Jan 2012 18:12:14 -0800 (PST) Received: by 10.229.20.193 with HTTP; Sun, 29 Jan 2012 18:12:14 -0800 (PST) In-Reply-To: <20120128134331.819221C33944@drugs.dv.isc.org> References: <20120120054939.GD4365@mail.yitter.info> <20120128052029.618CE1C32BFA@drugs.dv.isc.org> <20120128134331.819221C33944@drugs.dv.isc.org> Date: Sun, 29 Jan 2012 18:12:14 -0800 Message-ID: From: Mohan Parthasarathy To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DNSEXT Working Group Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 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 Jan 2012 02:12:15 -0000 On Sat, Jan 28, 2012 at 5:43 AM, Mark Andrews wrote: > > In message > , Mohan Parthasarathy writes: >> On Fri, Jan 27, 2012 at 9:20 PM, Mark Andrews wrote: >> > >> > In message > l.com> >> > , Mohan Parthasarathy writes: >> > >> >> - Section 5.7 setting the AD bit on queries. Is CD=3D0,DO=3D0 in the = que=3D >> ry >> >> same as AD=3D1,DO=3D0 ? >> > >> > The question doesn't make sense. >> > >> > AD=3D0,DO=3D1 and AD=3D1,DO=3D1 produce the same result. >> > AD=3D0,DO=3D0 and AD=3D1,DO=3D0 produce different results. >> > AD=3D0,DO=3D0 and AD=3D0,DO=3D1 produce different results. >> > AD=3D1,DO=3D0 and AD=3D0,DO=3D1 produce different results. >> > >> Thanks for the clarification. I realized after I posted that not >> setting CD and DO is pre-DNSSEC. >> >> >> missed the discussion on this earlier. If there is a valid reason, >> >> that needs to be stated explicitly as to why we are introducing this >> >> new option. >> > >> > Section 5.7 explains why this option exists. >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This allows a requestor to indicate tha= t i=3D >> t understands >> > =A0 the AD bit without also requesting DNSSEC data via the DO bit. >> > >> > >> So, "understands" here means "Please do the validation for me " ? >> Then, is =A0CD=3D1, AD=3D1 a invalid option ? > > No. =A0AD will be 1 if the answer + authority sections come from > cached data that has validated as secure. =A0That said I don't think > there is much use unless you are trying to check if a lookup failure > was due to DNSSEC errors. > Okay. >> So, there are implementations out there that want to know whether >> validation was successful or not but just not want to handle any >> DNSSEC records? > > I will put it this way. =A0I doubt if there is a application that > cares about AD that *wants* the DNSSEC records. =A0At the moment they > have no choice unless they are using the draft. > Agreed that those DNSSEC records are not of much use. For non-validating resolvers, there is now a choice of setting the DO bit or AD bit and setting both does not make sense. Perhaps, this should be explained. >> My question was more on what prompted the addition of this new feature ? > > 1. It reduces the response size. > 2. You can apply DNS64, NXDOMAIN redirection, bad site filtering, etc. wi= th > =A0 AD=3D1 which you can't with DO=3D1. > Why does the extra DNSSEC records affect DNS64 ? If AD=3D1 seems better for non-validating resolvers, perhaps that should be recommended in the draft ? -mohan > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org From marka@isc.org Sun Jan 29 19:30:22 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783B621F850F for ; Sun, 29 Jan 2012 19:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRixD4leGBti for ; Sun, 29 Jan 2012 19:30:22 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id F39C821F8503 for ; Sun, 29 Jan 2012 19:30:21 -0800 (PST) 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 78DE3C9425; Mon, 30 Jan 2012 03:30:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6d48:c4cd:82ef:670]) (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 29510216C6B; Mon, 30 Jan 2012 03:30: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 65DEB1C470D3; Mon, 30 Jan 2012 14:29:54 +1100 (EST) To: Mohan Parthasarathy From: Mark Andrews References: <20120120054939.GD4365@mail.yitter.info> <20120128052029.618CE1C32BFA@drugs.dv.isc.org> <20120128134331.819221C33944@drugs.dv.isc.org> In-reply-to: Your message of "Sun, 29 Jan 2012 18:12:14 -0800." Date: Mon, 30 Jan 2012 14:29:54 +1100 Message-Id: <20120130032954.65DEB1C470D3@drugs.dv.isc.org> Cc: DNSEXT Working Group Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 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 Jan 2012 03:30:22 -0000 In message , Mohan Parthasarathy writes: > >> My question was more on what prompted the addition of this new feature ? > > > > 1. It reduces the response size. > > 2. You can apply DNS64, NXDOMAIN redirection, bad site filtering, etc. with > > AD=1 which you can't with DO=1. > > Why does the extra DNSSEC records affect DNS64 ? Because, despite what Section 3 of RFC 6147 says, you can't divine intent from DO and CD and applying DNS64 synthesis to DO=1,CD=0 is just as bad as applying DNS64 synthesis to DO=1,CD=1. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From internet-drafts@ietf.org Mon Jan 30 10:03:08 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCE521F861C; Mon, 30 Jan 2012 10:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgzTOGfX7zzU; Mon, 30 Jan 2012 10:03:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA4F21F860F; Mon, 30 Jan 2012 10:03:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120130180307.28116.53671.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 10:03:07 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-registry-update-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 18:03:08 -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 : DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Upd= ates Author(s) : Scott Rose Filename : draft-ietf-dnsext-dnssec-registry-update-00.txt Pages : 6 Date : 2012-01-30 The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA maintained registry. This document presents a set of changes for some entries of the registry and presents a new registry table. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-updat= e-00.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-update= -00.txt From internet-drafts@ietf.org Mon Jan 30 10:03:38 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C631D11E8093; Mon, 30 Jan 2012 10:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 486JUfSJ7+-g; Mon, 30 Jan 2012 10:03:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602C111E8086; Mon, 30 Jan 2012 10:03:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120130180338.27331.28809.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 10:03:38 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 18:03:38 -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 Implementation Status Author(s) : Scott Rose Filename : draft-ietf-dnsext-dnssec-algo-imp-status-00.txt Pages : 6 Date : 2012-01-30 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 recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation compliance status for DNSSEC implementations. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-imp-statu= s-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-imp-status= -00.txt From Ed.Lewis@neustar.biz Mon Jan 30 12:17:47 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020F621F8699 for ; Mon, 30 Jan 2012 12:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.914 X-Spam-Level: X-Spam-Status: No, score=-105.914 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFUrt0nMMnm0 for ; Mon, 30 Jan 2012 12:17:46 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 10B1B21F85C9 for ; Mon, 30 Jan 2012 12:17:45 -0800 (PST) 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 q0UKHhAF003305; Mon, 30 Jan 2012 15:17:44 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.221] by Work-Laptop-2.local (PGP Universal service); Mon, 30 Jan 2012 15:17:43 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 30 Jan 2012 15:17:43 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20120127213928.GI17728@mail.yitter.info> References: <20120127213928.GI17728@mail.yitter.info> Date: Mon, 30 Jan 2012 15:17:40 -0500 To: Andrew Sullivan From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dnsext@ietf.org Subject: [dnsext] algo-sig shepherd was Re: WG state reminder 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 Jan 2012 20:17:47 -0000 At 16:39 -0500 1/27/12, Andrew Sullivan wrote: >draft-ietf-dnsext-dnssec-algo-signal completed a WGLC under its >(apponted, non-WG chair) shepherd some time ago, but there have been >comments since. The shepherd was appointed because both of the WG >co-chairs, in their employment, reported to one of the document >authors. The appointed shephed is busy. Given that I am no longer >reporting to the author in question in my employment, I wonder whether >people still have a concern here. Comments are welcome. Frankly I've never been a fan of that document (so I wouldn't be a good shepherd) but I don't have a problem with Andrew taking this on. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From Ed.Lewis@neustar.biz Mon Jan 30 12:31:45 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E49D11E80BB for ; Mon, 30 Jan 2012 12:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.989 X-Spam-Level: X-Spam-Status: No, score=-105.989 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78TMRivV9Kjg for ; Mon, 30 Jan 2012 12:31:44 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2C511E8091 for ; Mon, 30 Jan 2012 12:31:44 -0800 (PST) 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 q0UKVgJb003437; Mon, 30 Jan 2012 15:31:43 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.221] by Work-Laptop-2.local (PGP Universal service); Mon, 30 Jan 2012 15:31:43 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 30 Jan 2012 15:31:43 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20120130180338.27331.28809.idtracker@ietfa.amsl.com> References: <20120130180338.27331.28809.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 15:31:40 -0500 To: From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-884166993==_ma============" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [dnsext] draft-ietf-dnsext-dnssec-algo-imp-status-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 20:31:45 -0000 --============_-884166993==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Stupid question... Why do we have "DSA-NSEC3-SHA1" and "RSASHA1-NSEC3-SHA1" and not "DSA-NSEC3" and "RSASHA1-NSEC3"? Is that just they way it was defined in RFC 5155? Or is it from somewhere else? I.e., why the extra "-SHA1"? I suppose the ship has sailed on changing that though ... if it were changeable. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! --============_-884166993==_ma============ Content-Type: text/html; charset="us-ascii" draft-ietf-dnsext-dnssec-algo-imp-status-00.txt
Stupid question...

Why do we have

"DSA-NSEC3-SHA1" and "RSASHA1-NSEC3-SHA1"

and not

"DSA-NSEC3" and "RSASHA1-NSEC3"?

Is that just they way it was defined in RFC 5155?  Or is it from somewhere else?

I.e., why the extra "-SHA1"?

I suppose the ship has sailed on changing that though ... if it were changeable.

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

2012...time to reuse those 1984 calendars!
--============_-884166993==_ma============-- From warren@kumari.net Mon Jan 30 13:08:28 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628B721F865C for ; Mon, 30 Jan 2012 13:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYcMksq8Ock9 for ; Mon, 30 Jan 2012 13:08:27 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B547C21F8636 for ; Mon, 30 Jan 2012 13:08:27 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id A01751B40115; Mon, 30 Jan 2012 16:08:26 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <20120120054939.GD4365@mail.yitter.info> Date: Mon, 30 Jan 2012 16:08:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4FAAB581-0AE1-46FC-B05D-AC9FF2FEB030@kumari.net> References: <20120120054939.GD4365@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 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 Jan 2012 21:08:28 -0000 On Jan 20, 2012, at 12:49 AM, Andrew Sullivan wrote: > Dear colleagues, >=20 > This message initiates a three week Working Group Last Call on the > document draft-ietf-dnsext-dnssec-bis-updates-16. LC will close on > 2012-01-11 at 00:00 UTC. >=20 > The WG's standard conventions, which require five reviewers who state > that they have read the draft and support its publication as a > necessary but not sufficient determinant of rough consensus, are in > force. Please review the document and post to the list any comments > you have before the close of LC. =20 I have reviewed the document and support its publication (regardless of = the outcome of the Section 5.9 discussions). Nits:=20 Multiple times I read "Section 4 - Security Concerns" as "Security = Considerations" (probably because I am conditioned to see "Security = Considerations" :-P). I'd personally like it to be reworded = ("Considerations Relating to Security"?), but not enough to care (I = suspect that I'm the only one who misread this...) Section 5.11 O: "The pressence of an algorithm in a zone's DS or DNSKEY RRset" P: "The presence of an algorithm in a zone's DS or DNSKEY RRset" C: Spello. Appendix B, Model 1. O: "This model is so named because the validating resolver sets the CD = bit on queries it makes reegardless of whether it has a covering trust = anchor for the query." O: "This model is so named because the validating resolver sets the CD = bit on queries it makes regardless of whether it has a covering trust = anchor for the query." C: Spello. > If you cannot meet that deadline, > but are willing to commit to completing a review and can give me a > firm date for it (and that date is within a reasonable horizon), I > will announce an extension of the LC deadline. I'd appreciate it if > you'd tell me of this need sooner rather than later. Specific > comments are much better than generic ones, and specific comments with > suggested text (if you find some text wanting) are particularly > encouraged. >=20 > Speaking only personally, this draft is the product of several years > of WG work: the -00 of the draft was submitted in 2005. Moreover, it > is the product of a lot of heated discussion and careful teasing out > of the issues involved. I would be sad to discover that we could not > find (rather) more than five reviewers for this document. As it "is the product of a lot of heated discussion and careful teasing = out of the issues involved" perhaps some of that can count towards = review (if needed)? W >=20 > I will be the shepherd for this document if it is sent to the IESG. >=20 > Best regards, >=20 > Andrew >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 From paul.hoffman@vpnc.org Mon Jan 30 13:48:23 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A2921F8489 for ; Mon, 30 Jan 2012 13:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXp6C7SH--6I for ; Mon, 30 Jan 2012 13:48:22 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C8E9B21F8478 for ; Mon, 30 Jan 2012 13:48:22 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0ULmEh4007254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Jan 2012 14:48:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 30 Jan 2012 13:48:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120130180338.27331.28809.idtracker@ietfa.amsl.com> To: Edward Lewis X-Mailer: Apple Mail (2.1251.1) Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-imp-status-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:48:23 -0000 On Jan 30, 2012, at 12:31 PM, Edward Lewis wrote: > Stupid question... >=20 > Why do we have >=20 > "DSA-NSEC3-SHA1" and "RSASHA1-NSEC3-SHA1" >=20 > and not >=20 > "DSA-NSEC3" and "RSASHA1-NSEC3"? >=20 > Is that just they way it was defined in RFC 5155? Or is it from = somewhere else? >=20 > I.e., why the extra "-SHA1"? In the future, there might be different hash algorithms to use with = NSEC3, yes? --Paul Hoffman From Ray.Bellis@nominet.org.uk Tue Jan 31 01:36:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086AE21F8748 for ; Tue, 31 Jan 2012 01:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.088 X-Spam-Level: X-Spam-Status: No, score=-9.088 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLmCJLAlH1gc for ; Tue, 31 Jan 2012 01:36:14 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1B31D21F86B4 for ; Tue, 31 Jan 2012 01:36:13 -0800 (PST) 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: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=bGVqTTFqTwEBGswjSLjQqBY/q1S6TsZ2/P5Ucd1OSd8MOrL2xg7ZUh1i uQuNVQQBA0EBFgHShkbD8AcgohvEn7oVZ2KohgfxuXDf4qhBAZAx+U4Rt fuBi/n2q5lPeNev; 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=1328002574; x=1359538574; 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]=20algo-sig=20shepherd=20was=20 Re:=20WG=20state=20reminder|Date:=20Tue,=2031=20Jan=20201 2=2009:36:03=20+0000|Message-ID:=20<20496A7D-C79D-4A82-BC A7-0E0F721AB4D8@nominet.org.uk>|To:=20"dnsext@ietf.org" =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<019ff959-5556-4537-9f3c-58f94ee49d6d> |In-Reply-To:=20 |References:=20<20120127213928.GI17728@mail.yitter.info> =0D=0A=20; bh=yaqOWg+A3/AjACyEGOk2hvIjfpTjzHNrb2cBA1U450s=; b=AxZE2VZjo9gnFQfjU0ftsY0EL3Tsout/Bj+ZgXK5KEpzPFd4+fpcscwI 94FRQ/y4RSgrWuOqS9BzcYCHfost/sr9P2046T/e+NswFEN/rvNX/kOkD S5VeujDv16ByEhg; X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="30931518" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 31 Jan 2012 09:36:05 +0000 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 Jan 2012 09:36:05 +0000 From: Ray Bellis To: "dnsext@ietf.org" Thread-Topic: [dnsext] algo-sig shepherd was Re: WG state reminder Thread-Index: AQHM34xL07XJrncaM0K8Q3T+BawZQZYmOGaA Date: Tue, 31 Jan 2012 09:36:03 +0000 Message-ID: <20496A7D-C79D-4A82-BCA7-0E0F721AB4D8@nominet.org.uk> References: <20120127213928.GI17728@mail.yitter.info> 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: <019ff959-5556-4537-9f3c-58f94ee49d6d> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dnsext] algo-sig shepherd was Re: WG state reminder 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 Jan 2012 09:36:15 -0000 On 30 Jan 2012, at 20:17, Edward Lewis wrote: > Frankly I've never been a fan of that document (...) but > I don't have a problem with Andrew taking this on. +1 on both counts. Ray From scottr.nist@gmail.com Tue Jan 31 07:11:32 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531F621F8647 for ; Tue, 31 Jan 2012 07:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcdCpWOj2uAH for ; Tue, 31 Jan 2012 07:11:31 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 441C821F8644 for ; Tue, 31 Jan 2012 07:11:31 -0800 (PST) Received: from h222012.nist.gov (h222012.nist.gov [129.6.222.12]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q0VFBIKa013546; Tue, 31 Jan 2012 10:11:21 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Scott Rose In-Reply-To: Date: Tue, 31 Jan 2012 10:11:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120130180338.27331.28809.idtracker@ietfa.amsl.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr.nist@gmail.com Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-imp-status-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 15:11:32 -0000 That's the mnemonics used in RFC 5155 and I didn't want to change it, so = it's there for consistency. Scott On Jan 30, 2012, at 4:48 PM, Paul Hoffman wrote: > On Jan 30, 2012, at 12:31 PM, Edward Lewis wrote: >=20 >> Stupid question... >>=20 >> Why do we have >>=20 >> "DSA-NSEC3-SHA1" and "RSASHA1-NSEC3-SHA1" >>=20 >> and not >>=20 >> "DSA-NSEC3" and "RSASHA1-NSEC3"? >>=20 >> Is that just they way it was defined in RFC 5155? Or is it from = somewhere else? >>=20 >> I.e., why the extra "-SHA1"? >=20 > In the future, there might be different hash algorithms to use with = NSEC3, yes? >=20 > --Paul Hoffman >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From Ed.Lewis@neustar.biz Tue Jan 31 09:49:15 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F61B21F850C for ; Tue, 31 Jan 2012 09:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.051 X-Spam-Level: X-Spam-Status: No, score=-106.051 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cyfp5I5e7k6 for ; Tue, 31 Jan 2012 09:49:15 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id F1A1F21F8503 for ; Tue, 31 Jan 2012 09:49:14 -0800 (PST) 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 q0VHnCev011247; Tue, 31 Jan 2012 12:49:13 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.221] by Work-Laptop-2.local (PGP Universal service); Tue, 31 Jan 2012 12:49:14 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 31 Jan 2012 12:49:14 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120130180338.27331.28809.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2012 12:46:50 -0500 To: Paul Hoffman From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-imp-status-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:49:15 -0000 At 13:48 -0800 1/30/12, Paul Hoffman wrote: >In the future, there might be different hash algorithms to use with >NSEC3, yes? Not really. We only needed an NSEC3-ized RSA/SHA-1 to deal with backward compatibility issues at the time. From here out, any "new" DNSSEC "algorithm" will be defined for NSEC3 and NSEC. And - for RSASHA1-NSEC3-SHA1, the -SHA1 is there twice! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From mstjohns@comcast.net Tue Jan 31 10:57:29 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB2F11E808E for ; Tue, 31 Jan 2012 10:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnHLMpW76GQl for ; Tue, 31 Jan 2012 10:57:29 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAE811E8075 for ; Tue, 31 Jan 2012 10:57:28 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta13.westchester.pa.mail.comcast.net with comcast id UJhE1i0090xGWP85DJxVVd; Tue, 31 Jan 2012 18:57:29 +0000 Received: from Mike-PC3.comcast.net ([68.83.222.237]) by omta12.westchester.pa.mail.comcast.net with comcast id UJxU1i01A57vnMg3YJxV9D; Tue, 31 Jan 2012 18:57:29 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 31 Jan 2012 13:57:26 -0500 To: Andrew Sullivan ,dnsext@ietf.org From: Michael StJohns In-Reply-To: <20120120054939.GD4365@mail.yitter.info> References: <20120120054939.GD4365@mail.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20120131185729.1BAE811E8075@ietfa.amsl.com> Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 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 Jan 2012 18:57:30 -0000 I support the publication of this document - finally. Any nits are just that - nits - and shouldn't affect the publication. No changes, no take backs! Mike At 12:49 AM 1/20/2012, Andrew Sullivan wrote: >Dear colleagues, > >This message initiates a three week Working Group Last Call on the >document draft-ietf-dnsext-dnssec-bis-updates-16. LC will close on >2012-01-11 at 00:00 UTC. > >The WG's standard conventions, which require five reviewers who state >that they have read the draft and support its publication as a >necessary but not sufficient determinant of rough consensus, are in >force. Please review the document and post to the list any comments >you have before the close of LC. If you cannot meet that deadline, >but are willing to commit to completing a review and can give me a >firm date for it (and that date is within a reasonable horizon), I >will announce an extension of the LC deadline. I'd appreciate it if >you'd tell me of this need sooner rather than later. Specific >comments are much better than generic ones, and specific comments with >suggested text (if you find some text wanting) are particularly >encouraged. > >Speaking only personally, this draft is the product of several years >of WG work: the -00 of the draft was submitted in 2005. Moreover, it >is the product of a lot of heated discussion and careful teasing out >of the issues involved. I would be sad to discover that we could not >find (rather) more than five reviewers for this document. > >I will be the shepherd for this document if it is sent to the IESG. > >Best regards, > >Andrew > >-- >Andrew Sullivan >ajs@anvilwalrusden.com >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext From Ed.Lewis@neustar.biz Tue Jan 31 12:05:39 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E99921F8540 for ; Tue, 31 Jan 2012 12:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.101 X-Spam-Level: X-Spam-Status: No, score=-106.101 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StcSWJgbTpwG for ; Tue, 31 Jan 2012 12:05:38 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB7B21F853C for ; Tue, 31 Jan 2012 12:05:35 -0800 (PST) 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 q0VK5Q9a012267; Tue, 31 Jan 2012 15:05:27 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.221] by Work-Laptop-2.local (PGP Universal service); Tue, 31 Jan 2012 15:05:28 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 31 Jan 2012 15:05:28 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120130180338.27331.28809.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2012 14:58:27 -0500 To: Scott Rose From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: Edward Lewis , Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-imp-status-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 20:05:39 -0000 At 10:11 -0500 1/31/12, Scott Rose wrote: >That's the mnemonics used in RFC 5155 and I didn't want to change it, so >it's there for consistency. I can buy that. (But given that inconsistency in the docs has been a "family tradition"... ;)) Seriously I don't think that we can change the names. Still, I'm left scratching my head over this. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars!