From wouter@nlnetlabs.nl Sat Jan 1 14:13:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F603A6936 for ; Sat, 1 Jan 2011 14:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAmya-4oBoBm for ; Sat, 1 Jan 2011 14:13:21 -0800 (PST) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by core3.amsl.com (Postfix) with ESMTP id 7F1CD3A6931 for ; Sat, 1 Jan 2011 14:13:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 6033458660 for ; Sat, 1 Jan 2011 23:15:26 +0100 (CET) Received: from [192.168.1.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 72D5658658 for ; Sat, 1 Jan 2011 23:15:14 +0100 (CET) Message-ID: <4D1FA772.6070000@nlnetlabs.nl> Date: Sat, 01 Jan 2011 23:15:14 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <5C578182DAA04FE6B9CF4A18B7BC0D95@local> 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.96.4 at rotring X-Virus-Status: Clean Subject: Re: [dnsext] Checking RRSIG RR validity X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jan 2011 22:13:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mohan or Sean and George, On 12/31/2010 08:36 PM, Sean Wells or Mohan wrote: > On Fri, Dec 31, 2010 at 9:55 AM, George Barwood wrote: >> I agree the standard is not explicit here. These are my thoughts That looks ok to me. >> Unfortunately a validating resolver does not know the zone in a >> secure way, so it's unclear how this is to be implemented. Yes it may know more, because it may know where the information was fetched from (it is also a full resolver) and thus that the signer name must be equal or lower to that last delegation point. If you really want, it is possible to securely determine the zone, think nodata DS answers. > That is exactly my issue. > Perhaps, it would be good to clarify this in the > Clarifications document ? (assuming there is consensus). The checks from George look good to me. However I do not think that needs to be RFC-ed, because, I do not want to force 'bottom-up' or 'top-down' validation. Also, I believe those RR type checks are a bit over-the-top. Although it means the zone is badly configured, you can leniently let it pass, since it was signed by the owner. (And Happy New Year for Ed :-) ). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0fp3EACgkQkDLqNwOhpPiUdgCgqH3S6NUAn+fmW+IwCTkMET59 HTgAnjqzViLyG5uSUn7gz71MAmpxfTcd =EcXP -----END PGP SIGNATURE----- From scott.rose@nist.gov Sun Jan 2 12:36:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66AA23A6923 for ; Sun, 2 Jan 2011 12:36:07 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdfZf-UzFcR0 for ; Sun, 2 Jan 2011 12:36:05 -0800 (PST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id AD9DC3A691D for ; Sun, 2 Jan 2011 12:36:05 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p02Kc2Xb006190; Sun, 2 Jan 2011 15:38:02 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Sun, 2 Jan 2011 15:38:02 -0500 From: "Rose, Scott W." To: "dnsext@ietf.org" Date: Sun, 2 Jan 2011 15:38:01 -0500 Thread-Topic: [dnsext] Re. Adotping draft: draft-hoffman-ecdsa-dnssec-04.txt Thread-Index: AcuqvPIz9k8VzDZCS/209dxIlBY5lA== Message-ID: References: <570331.89742.qm@web30502.mail.mud.yahoo.com> 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="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Cc: Edward Lewis Subject: Re: [dnsext] Re. Adotping draft: draft-hoffman-ecdsa-dnssec-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jan 2011 20:36:07 -0000 On Dec 30, 2010, at 2:35 PM, Edward Lewis wrote: > With the end of the decade drawing close, I finally had time to look at this: > > http://tools.ietf.org/html/draft-hoffman-dnssec-ecdsa-04 > > This should be adopted and edited by the WG. > > Some first blush notes - it needs some support for these claims: > > "Currently, the most popular signature algorithm is RSA with SHA-1, > using keys 1024 or 2048 bits long." > > I don't think that is a relevant point, so maybe there's no need to > add a reference. But if it sticks, as Wikipedia says "This article > lacks inline citations. Please help improve this article by > introducing appropriate citations to additional sources." > Talking about the algorithm is probably correct (being that RSA/SHA-1 is the only algorithm considered mandatory to implement). The key size statement may not be easier to prove, but doesn't add much to the discussion, so could be dropped. > Another example is the claim: > > "Current estimates are that ECDSA with curve P-256 has an approximate > equivalent strength to RSA with 3072-bit keys." > > The notion of cryptographic strength is one that should be something > I can find in a referenced document somewhere. > I would offer NIST SP 800-57 Part 1 as a reference here - Section 5.6.1 provides a comparison. Scott > I welcome the definition of additional algorithms for DNSSEC. But as > an DNS engineer, don't expect me no know anything about cryptography. > IOW, if a 3072 bit elliptical curve key was as strong as a normal RSA > key of 100 bits, I'd welcome the definition. > > I just wouldn't use it. > > Seriously - what I am asking for are more references in the text, > enough that this document could stand on it's own and I wouldn't need > a background in cryptography to believe the arguments and claims made. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > The 21st Century is 10% complete. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext =================================== Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== From marc.lampo@eurid.eu Tue Jan 4 01:49:50 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2674E3A6B63 for ; Tue, 4 Jan 2011 01:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thdjSFu-s6Tm for ; Tue, 4 Jan 2011 01:49:48 -0800 (PST) Received: from cuda.eurid.eu (mx.eurid.eu [77.67.53.136]) by core3.amsl.com (Postfix) with ESMTP id 33DCD3A69F5 for ; Tue, 4 Jan 2011 01:49:47 -0800 (PST) X-ASG-Debug-ID: 1294134710-1ebb1e440001-uIE7UK Received: from zimbra.eurid.eu (blade2.bc2.vt.eurid.eu [172.19.101.22]) by cuda.eurid.eu with ESMTP id HVfXo88rQR4JXhMA for ; Tue, 04 Jan 2011 10:51:50 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 5B306B0060 for ; Tue, 4 Jan 2011 10:51:50 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCfiX4rw6c2q for ; Tue, 4 Jan 2011 10:51:50 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [172.19.0.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 482D7B005F for ; Tue, 4 Jan 2011 10:51:50 +0100 (CET) From: "Marc Lampo" To: Date: Tue, 4 Jan 2011 10:51:50 +0100 (CET) X-ASG-Orig-Subj: RFC 4035 and "caching" of "expired RRSIG's" Message-ID: <000201cbabf5$0533d010$0f9b7030$@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 5.0.18_GA_3011.RHEL5_64 (ZimbraConnectorForOutlook/5.0.3064.18) Content-Language: en-za Thread-Index: Acur9QTIZ5zL2FvVR/aJmJd2k8RWBA== X-Originating-IP: [172.20.1.130] X-Barracuda-Connect: blade2.bc2.vt.eurid.eu[172.19.101.22] X-Barracuda-Start-Time: 1294134710 X-Barracuda-URL: http://77.67.53.136:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: [dnsext] RFC 4035 and "caching" of "expired RRSIG's" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jan 2011 09:49:50 -0000 Hello group, and my best whishes for a healthy and challenging 2011 ! Allow me to throw a question about "caching" of "expired RRSIG's". In RFC4035, DNSSEC “protocol”, in section 4 : “Resolving” 4.5. Response Caching A security-aware resolver SHOULD cache each response as a single atomic entry containing the entire answer, including the named RRset and any associated DNSSEC RRs. The resolver SHOULD discard the entire atomic entry when any of the RRs contained in it expire. In a preceding paragraph on “Recursive Name Servers” (3.2), it reads : The resolver side follows the usual rules for caching and negative caching that would apply to any security-aware resolver. --> I interpret that the discarding of an entire atomic entry when (even at least) one RRSIG in it expire (even though others may be still be valid) is a recommendation (only). There are two aspects I feel might need some explicit clarification : 1) the "should", from 4.5, is to be interpreted as : "recommended" and "developer, know what you are doing when you do not implement this" (free after rfc 2119) Consequently : some name server implementations/versions may chose to cache expired RRSIG's 2) "*any* of the RRs ... expire" Fact is that multiple RRSIG's may be available, not all of which expired, and those that are still valid, may allow to perform full DNSSEC validation. If taken literally, name servers that do implement discarding according to 4.5 of RFC4035 might not cache otherwise valid info (RRset + related RRSIG(set)) as soon as one of the RRSIG's expires. As this might defeat the functioning of caching - there are name servers that almost continuously return an expired RRSIG, In the presence of other, not expired, RRSIG(s) that do allow DNSSEC validation - if at leased one received RRSIG is already expired upon reception. Consequently : Wouldn't it be wise to rephrase 4.5 of RFC4035 such that "DNSSEC validation becomes impossible" is meant ? At this moment, as eu. top-level domain, we continue to warn for RRSIG's that may expire while in some cache. (because throwing them out of the cache is "recommended" only). We feel this is in the interest of optimal DNSSEC operation. Thanks for sharing your feedback. Kind regards, Marc Lampo Security Officer       EURid     Woluwelaan 150         1831 Diegem - Belgium     marc.lampo@eurid.eu     http://www.eurid.eu Register your .eu domain name and win an iPod touch this X-Mas http://www.winwith.eu From fweimer@bfk.de Tue Jan 4 02:03:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873A23A6B71 for ; Tue, 4 Jan 2011 02:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDJ6GWVxIRc6 for ; Tue, 4 Jan 2011 02:03:24 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 2C41B3A6B70 for ; Tue, 4 Jan 2011 02:03:22 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Pa3lg-00037h-Bo; Tue, 04 Jan 2011 10:05:28 +0000 Received: by bfk.de with local id 1Pa3lg-0002zH-8r; Tue, 04 Jan 2011 10:05:28 +0000 To: "Marc Lampo" References: <000201cbabf5$0533d010$0f9b7030$@eurid.eu> From: Florian Weimer Date: Tue, 04 Jan 2011 10:05:28 +0000 In-Reply-To: <000201cbabf5$0533d010$0f9b7030$@eurid.eu> (Marc Lampo's message of "Tue\, 4 Jan 2011 10\:51\:50 +0100 \(CET\)") Message-ID: <82sjx9kmqf.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC 4035 and "caching" of "expired RRSIG's" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jan 2011 10:03:25 -0000 * Marc Lampo: > Consequently : > Wouldn't it be wise to rephrase 4.5 of RFC4035 such that > "DNSSEC validation becomes impossible" > is meant ? Please clarify if you're concerned with TTLs or signature validity periods. (The quoted sections in the RFCs are strictly about TTLs, and not about cryptographic constraints.) --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From marc.lampo@eurid.eu Tue Jan 4 02:44:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AE533A6B63 for ; Tue, 4 Jan 2011 02:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crvcU+i00cQc for ; Tue, 4 Jan 2011 02:44:47 -0800 (PST) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by core3.amsl.com (Postfix) with ESMTP id CD1093A6B5A for ; Tue, 4 Jan 2011 02:44:46 -0800 (PST) X-ASG-Debug-ID: 1294138012-7acf1f5c0001-uIE7UK Received: from zimbra.eurid.eu (blade2.bc2.vt.eurid.eu [172.19.101.22]) by barra.eurid.eu with ESMTP id mKIbFxisSO1DmRBo; Tue, 04 Jan 2011 11:46:52 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 0DC63B0060; Tue, 4 Jan 2011 11:46:52 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5c85k8MYab9; Tue, 4 Jan 2011 11:46:51 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [172.19.0.120]) by zimbra.eurid.eu (Postfix) with ESMTP id ECF7AB005F; Tue, 4 Jan 2011 11:46:51 +0100 (CET) From: "Marc Lampo" To: "'Florian Weimer'" , "'Marc Lampo'" References: <000201cbabf5$0533d010$0f9b7030$@eurid.eu> <82sjx9kmqf.fsf@mid.bfk.de> In-Reply-To: <82sjx9kmqf.fsf@mid.bfk.de> Date: Tue, 4 Jan 2011 11:46:51 +0100 (CET) X-ASG-Orig-Subj: RE: [dnsext] RFC 4035 and "caching" of "expired RRSIG's" Message-ID: <000c01cbabfc$b527e4f0$1f77aed0$@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 5.0.18_GA_3011.RHEL5_64 (ZimbraConnectorForOutlook/5.0.3064.18) Content-Language: en-za Thread-Index: Acur9vyxoyW6mu5QSIq7pz7OUb+A6gABChtg X-Originating-IP: [172.20.1.130] X-Barracuda-Connect: blade2.bc2.vt.eurid.eu[172.19.101.22] X-Barracuda-Start-Time: 1294138012 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC 4035 and "caching" of "expired RRSIG's" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jan 2011 10:44:48 -0000 Hello, I understand what you mean, but the RFC uses the word "expire". And that, by itself, can be interpreted in two ways : 1) the ttl counts down to 0 2) the present time is later then the "expiration date" of the (a ?) RRSIG record You indicate that this portion of the RFC handles TTL only, but the last paragraph of that section 4.5 states : "until the TTL or signatures ... expire" --> this leads to believe that it is not exclusively TTL only That possible, dual, interpretation indicates the need for clarifation, I would say. And, if the original RFC meant the TTL only, then the case of an RRSIG past expiration time (second interpretation above) is not addressed at all, is it ? Furthermore, since TTL of RRSIG RRset must be identical to the TTL of the RRset it signs, all records in the "atomic entry" should have the same TTL anyway. Though I suppose that somehow, data might arrive/be refreshed at different times, yielding different TTL values in a validating name servers cache. Kind regards, Marc -----Original Message----- From: Florian Weimer [mailto:fweimer@bfk.de] Sent: 04 January 2011 11:05 AM To: Marc Lampo Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC 4035 and "caching" of "expired RRSIG's" * Marc Lampo: > Consequently : > Wouldn't it be wise to rephrase 4.5 of RFC4035 such that > "DNSSEC validation becomes impossible" > is meant ? Please clarify if you're concerned with TTLs or signature validity periods. (The quoted sections in the RFCs are strictly about TTLs, and not about cryptographic constraints.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 Register your .eu domain name and win an iPod touch this X-Mas http://www.winwith.eu From fweimer@bfk.de Tue Jan 4 02:50:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69B903A6B5A for ; Tue, 4 Jan 2011 02:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUQeJo8AB8Yi for ; Tue, 4 Jan 2011 02:50:05 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 6D5A73A698E for ; Tue, 4 Jan 2011 02:50:00 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Pa4Up-0006Xw-1c; Tue, 04 Jan 2011 10:52:07 +0000 Received: by bfk.de with local id 1Pa4Uo-0004kV-VC; Tue, 04 Jan 2011 10:52:06 +0000 To: "Marc Lampo" References: <000201cbabf5$0533d010$0f9b7030$@eurid.eu> <82sjx9kmqf.fsf@mid.bfk.de> <000c01cbabfc$b527e4f0$1f77aed0$@eurid.eu> From: Florian Weimer Date: Tue, 04 Jan 2011 10:52:06 +0000 In-Reply-To: <000c01cbabfc$b527e4f0$1f77aed0$@eurid.eu> (Marc Lampo's message of "Tue\, 4 Jan 2011 11\:46\:51 +0100 \(CET\)") Message-ID: <82lj31uejt.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC 4035 and "caching" of "expired RRSIG's" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jan 2011 10:50:06 -0000 * Marc Lampo: > You indicate that this portion of the RFC handles TTL only, > but the last paragraph of that section 4.5 states : > "until the TTL or signatures ... expire" > --> this leads to believe that it is not exclusively TTL only > That possible, dual, interpretation indicates the need for clarifation, I > would say. The paragraph containing this statement sketches NODATA/NXDOMAIN/wildcard synthesis and recommends against it. For that type of synthesis, you likely want to obey cryptographic constraints because you only want to synthesize an answer which can be proven cryptographically valid. This is about pulling records from thin air, and it is fundamentally different from regular caching behavior. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From anicoll@cert.org Tue Jan 4 06:22:30 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5273A6C19 for ; Tue, 4 Jan 2011 06:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BW7osPLButr8 for ; Tue, 4 Jan 2011 06:22:25 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by core3.amsl.com (Postfix) with ESMTP id A37773A6BDF for ; Tue, 4 Jan 2011 06:22:25 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.13.8/8.13.8/1294) with ESMTP id p04EOWbl023401 for ; Tue, 4 Jan 2011 09:24:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1294151072; bh=+mTjPVCqblhGE67BMMt8AQtxUhgxz0SV8LtJCWY2b8k=; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=Whsr8PyhsPEcu3WebJOwvWm0fZgKde34yRB1PvzzudaZjAJfvxsx5lhiFgsjAUpeI qAmLO7KfOneK4vvZWh7NSEgcZdFwBB3YIFq6rmwULCmX0I/CRIiMzyGAkyfFQiI76+ Gw1fxDJudYjI+4G9AXLJlXdpSwzPN4PK0B0z2h+s= Received: from owa.sei.cmu.edu (tyranus.sei.cmu.edu [10.64.28.15]) by timber.sei.cmu.edu (8.13.8/8.13.8/1348) with ESMTP id p04EOWC1003612 for ; Tue, 4 Jan 2011 09:24:32 -0500 Received: from EXCHANGE.sei.cmu.edu ([10.64.28.12]) by tyranus.sei.cmu.edu ([10.64.28.15]) with mapi; Tue, 4 Jan 2011 09:24:31 -0500 From: Alex Nicoll To: "dnsext@ietf.org" Date: Tue, 4 Jan 2011 09:24:30 -0500 Thread-Topic: DNS Documentation Project Thread-Index: AcusGxlzOC7IAZ3iQ0qmPxpikBRfcg== 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_A32A045574615B4FAB96C4952BA5768BB76D93F5B0EXCHANGEseicm_" MIME-Version: 1.0 Subject: [dnsext] DNS Documentation Project X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jan 2011 14:22:30 -0000 --_000_A32A045574615B4FAB96C4952BA5768BB76D93F5B0EXCHANGEseicm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good Morning All! (yes, I'm well aware that you over achievers in Europe h= ave been at work for six hours already. ;) As I mentioned back in December, I would very much like to put together a f= ormal set of documentation for the DNS protocol. My intent is to produce d= ocumentation that those who wish to create their own DNS client or server i= mplementations can use to definitively answer the questions "Am I Done?" an= d "Did I Get It Right?". Some of you have given me a large number of poin= ters already, and I am very grateful for those! If anyone has additional= pointers, particularly to past attempts at documentation of the entire sta= ndard (including all relevant RFCs), I would be very appreciative if you co= uld pass those on to me. I intend to start on this project immediately. If any of you wish to help,= please let me know! -Alex (Disclaimer: I'm not the smartest guy on this list. I'm not even close to = being the most knowledgeable. You can always join in to help me not make m= istakes!) Alex Nicoll CERT Carnegie Mellon University/Software Engineering Institute anicoll@cert.org (412)268-9205 (USA) --_000_A32A045574615B4FAB96C4952BA5768BB76D93F5B0EXCHANGEseicm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good Morning All= !  (yes, I’m well aware that you over achievers in Europe have b= een at work for six hours already. ;)

 

As I mentioned back in December, I = would very much like to put together a formal set of documentation for the = DNS protocol.  My intent is to produce documentation that those who wi= sh to create their own DNS client or server implementations can use to defi= nitively answer the questions “Am I Done?” and “Did I Get= It Right?”.   Some of you have given me a large number of = pointers already, and I am very grateful for those!    If an= yone has additional pointers, particularly to past attempts at documentatio= n of the entire standard (including all relevant RFCs), I would be very app= reciative if you could pass those on to me.

 

I intend to start on this pro= ject immediately.  If any of you wish to help, please let me know!

 

-= Alex

 

(Disclaimer:  I’m not the smartest guy on this list. I= 217;m not even close to being the most knowledgeable.  You can always = join in to help me not make mistakes!)

<= o:p> 

Alex Nicoll

CERT

Carnegie Mellon Univer= sity/Software Engineering Institute

anicoll@cert.org

(412)268-9205 (USA)

&n= bsp;

= --_000_A32A045574615B4FAB96C4952BA5768BB76D93F5B0EXCHANGEseicm_-- From ogud@ogud.com Tue Jan 4 13:25:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D8D3A6BD5 for ; Tue, 4 Jan 2011 13:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U92avGGE8ST for ; Tue, 4 Jan 2011 13:25:51 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 37C7E3A6BD2 for ; Tue, 4 Jan 2011 13:25:51 -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 p04LRvxa058465 for ; Tue, 4 Jan 2011 16:27:57 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D2390DE.8050409@ogud.com> Date: Tue, 04 Jan 2011 16:27:58 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> In-Reply-To: <4D014A84.5070204@ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jan 2011 21:25:52 -0000 On 09/12/2010 4:30 PM, Olafur Gudmundsson wrote: > > Dear colleagues > > The chairs have received a request to adopt the following draft as a > working group document. > http://tools.ietf.org/html/draft-hoffman-dnssec-ecdsa-04 > > > The draft falls within the WG charter because it pertains to DNSSEC > algorithm maintenance > > The rules of the working group require that at least 5 members of the > working group publicly state that they support adoption. If 5 people > have not stepped forward by January 15'th the draft will not be adopted. The draft has reached its threshold for adoption, one issue has been brought up that the chairs would like more input on: + - IMHO the SHA-384 DS stuff should be put in another document: + * there is no reason to mix SHA-384 DS with ECDSA DNSKEY/RRSIG + * there is even no text explaining when SHA-384 should be used + in this case + * it makes easier to address the next item Please tell us if this item belongs in the draft, in a separate document or not at all? > > Please read the document and say what changes are needed to get the > document to be ready for advancement. The plan is to dispose of this > document in short order. > Please comment on if this document should be for informational or > standards track. We are assuming Standards Track is where the working group wants to place this document. Olafur & Andrew From paul.hoffman@vpnc.org Tue Jan 4 14:32:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7493A6C1A for ; Tue, 4 Jan 2011 14:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.633 X-Spam-Level: X-Spam-Status: No, score=-101.633 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id on13CbIAFBSY for ; Tue, 4 Jan 2011 14:32:03 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id AAB8F3A6C14 for ; Tue, 4 Jan 2011 14:32:03 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p04MY9Xd087668 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 4 Jan 2011 15:34:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D23A061.3060501@vpnc.org> Date: Tue, 04 Jan 2011 14:34:09 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> In-Reply-To: <4D2390DE.8050409@ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jan 2011 22:32:05 -0000 On 1/4/11 1:27 PM, Olafur Gudmundsson wrote: > On 09/12/2010 4:30 PM, Olafur Gudmundsson wrote: >> >> Dear colleagues >> >> The chairs have received a request to adopt the following draft as a >> working group document. >> http://tools.ietf.org/html/draft-hoffman-dnssec-ecdsa-04 >> >> >> The draft falls within the WG charter because it pertains to DNSSEC >> algorithm maintenance >> >> The rules of the working group require that at least 5 members of the >> working group publicly state that they support adoption. If 5 people >> have not stepped forward by January 15'th the draft will not be adopted. > > The draft has reached its threshold for adoption, one issue has been > brought up that the chairs would like more input on: > > + - IMHO the SHA-384 DS stuff should be put in another document: > + * there is no reason to mix SHA-384 DS with ECDSA DNSKEY/RRSIG > + * there is even no text explaining when SHA-384 should be used > + in this case > + * it makes easier to address the next item > > Please tell us if this item belongs in the draft, in a separate document > or not at all? It belongs in the draft because it makes no sense to have a signature that is ECDSA with the P-384 curve and SHA-384 that is pointed to by a DS of SHA-256: that gives an attacker a unneeded opening. >> Please read the document and say what changes are needed to get the >> document to be ready for advancement. The plan is to dispose of this >> document in short order. >> Please comment on if this document should be for informational or >> standards track. > > We are assuming Standards Track is where the working group wants to > place this document. That would be appropriate. From ogud@ogud.com Wed Jan 5 07:05:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397343A6E36 for ; Wed, 5 Jan 2011 07:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wz5sVtXM3LuV for ; Wed, 5 Jan 2011 07:05:55 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 031323A6E33 for ; Wed, 5 Jan 2011 07:05:54 -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 p05F808K065073 for ; Wed, 5 Jan 2011 10:08:00 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D248950.3040208@ogud.com> Date: Wed, 05 Jan 2011 10:08:00 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> In-Reply-To: <4D23A061.3060501@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 15:05:56 -0000 On 04/01/2011 5:34 PM, Paul Hoffman wrote: > On 1/4/11 1:27 PM, Olafur Gudmundsson wrote: >> On 09/12/2010 4:30 PM, Olafur Gudmundsson wrote: >>> >>> Dear colleagues >>> >>> The chairs have received a request to adopt the following draft as a >>> working group document. >>> http://tools.ietf.org/html/draft-hoffman-dnssec-ecdsa-04 >>> >>> >>> The draft falls within the WG charter because it pertains to DNSSEC >>> algorithm maintenance >>> >>> The rules of the working group require that at least 5 members of the >>> working group publicly state that they support adoption. If 5 people >>> have not stepped forward by January 15'th the draft will not be adopted. >> >> The draft has reached its threshold for adoption, one issue has been >> brought up that the chairs would like more input on: >> >> + - IMHO the SHA-384 DS stuff should be put in another document: >> + * there is no reason to mix SHA-384 DS with ECDSA DNSKEY/RRSIG >> + * there is even no text explaining when SHA-384 should be used >> + in this case >> + * it makes easier to address the next item >> >> Please tell us if this item belongs in the draft, in a separate document >> or not at all? > > It belongs in the draft because it makes no sense to have a signature > that is ECDSA with the P-384 curve and SHA-384 that is pointed to by a > DS of SHA-256: that gives an attacker a unneeded opening. > Trying to interpret your statement above, is this a fair generalization? "DS digest should/must be as strong as the DNSKEY it points to ?" Olafur From paul.hoffman@vpnc.org Wed Jan 5 07:10:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993513A6E33 for ; Wed, 5 Jan 2011 07:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.647 X-Spam-Level: X-Spam-Status: No, score=-101.647 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By9oGl2bruTQ for ; Wed, 5 Jan 2011 07:10:44 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id F0BA23A6E30 for ; Wed, 5 Jan 2011 07:10:43 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p05FCoQc022285 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 5 Jan 2011 08:12:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D248A72.5010404@vpnc.org> Date: Wed, 05 Jan 2011 07:12:50 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> In-Reply-To: <4D248950.3040208@ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 15:10:46 -0000 On 1/5/11 7:08 AM, Olafur Gudmundsson wrote: > On 04/01/2011 5:34 PM, Paul Hoffman wrote: >> It belongs in the draft because it makes no sense to have a signature >> that is ECDSA with the P-384 curve and SHA-384 that is pointed to by a >> DS of SHA-256: that gives an attacker a unneeded opening. >> > > > Trying to interpret your statement above, is this a fair > generalization? > "DS digest should/must be as strong as the DNSKEY it points to ?" With a non-normative slant, yes. Maybe "the DS digest should be able to be as strong as the DNSKEY signature that it covers". If someone wants to cover a strong signature with a weak hash, or vice versa, that's their choice, of course. From ogud@ogud.com Wed Jan 5 07:22:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C723A6C69 for ; Wed, 5 Jan 2011 07:22:20 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W57uqzRdH1xS for ; Wed, 5 Jan 2011 07:22:19 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 74E4B3A6C24 for ; Wed, 5 Jan 2011 07:22:19 -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 p05FOPtO065233 for ; Wed, 5 Jan 2011 10:24:26 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D248D29.50804@ogud.com> Date: Wed, 05 Jan 2011 10:24:25 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> In-Reply-To: <4D248A72.5010404@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 15:22:20 -0000 On 05/01/2011 10:12 AM, Paul Hoffman wrote: > On 1/5/11 7:08 AM, Olafur Gudmundsson wrote: >> On 04/01/2011 5:34 PM, Paul Hoffman wrote: > >>> It belongs in the draft because it makes no sense to have a signature >>> that is ECDSA with the P-384 curve and SHA-384 that is pointed to by a >>> DS of SHA-256: that gives an attacker a unneeded opening. >>> >> >> >> Trying to interpret your statement above, is this a fair >> generalization? >> "DS digest should/must be as strong as the DNSKEY it points to ?" > > With a non-normative slant, yes. Maybe "the DS digest should be able to > be as strong as the DNSKEY signature that it covers". If someone wants > to cover a strong signature with a weak hash, or vice versa, that's > their choice, of course. > Thinking ahead, why not just define SHA-512 DS and skip the 384 ? Olafur From Ed.Lewis@neustar.biz Wed Jan 5 07:46:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97513A69F2 for ; Wed, 5 Jan 2011 07:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.168 X-Spam-Level: X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lJYLgnLyCZZ for ; Wed, 5 Jan 2011 07:46:38 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 8A8523A6AF4 for ; Wed, 5 Jan 2011 07:46:38 -0800 (PST) Received: from gdun-e4300.cis.neustar.com (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p05Fmb2R065440; Wed, 5 Jan 2011 10:48:39 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.116] by gdun-e4300.cis.neustar.com (PGP Universal service); Wed, 05 Jan 2011 10:48:44 -0500 X-PGP-Universal: processed; by gdun-e4300.cis.neustar.com on Wed, 05 Jan 2011 10:48:44 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D248A72.5010404@vpnc.org> References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> Date: Wed, 5 Jan 2011 10:38:33 -0500 To: Paul Hoffman From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 15:46:39 -0000 At 7:12 -0800 1/5/11, Paul Hoffman wrote: >With a non-normative slant, yes. Maybe "the DS digest should be able to be >as strong as the DNSKEY signature that it covers". If someone wants to cover >a strong signature with a weak hash, or vice versa, that's their choice, >of course. I'd like to see this stated in DNS terms - i.e., the notion of strength is not one of them. I would suggest that - the authoritative set of the DS record SHOULD include a DS RR for each key that is of the same hash algorithm as is used in the key and MAY have other hashes (and MAY even have only other hashes[1]) [1] The parenthetical comment is redundant, put it there for emphasis. - a validator SHOULD prefer the DS record of the same hash algorithm over other hash algorithms for a key. Prefer means that it SHOULD be the first tried and if it fails, the validator MAY declare failure without examining the other applicable hash algorithms. A validator MUST NOT require that there be a hash of the same algorithm present, with require meaning - if such a hash is absent, failure is not automatic. You may note that I spec "the same hash algorithm" because I don't know of any way to say if one hash algorithm is stronger than the next. I.e., bit length might be an indicator but I bet it also isn't reliable. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 The 21st Century is 10% complete. From paul.hoffman@vpnc.org Wed Jan 5 07:53:49 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7AA3A6C77 for ; Wed, 5 Jan 2011 07:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.649 X-Spam-Level: X-Spam-Status: No, score=-101.649 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gt3SSv9FU1sj for ; Wed, 5 Jan 2011 07:53:48 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 904763A6AF4 for ; Wed, 5 Jan 2011 07:53:48 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p05Ftscw023977 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 5 Jan 2011 08:55:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D24948A.7080002@vpnc.org> Date: Wed, 05 Jan 2011 07:55:54 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <4D248D29.50804@ogud.com> In-Reply-To: <4D248D29.50804@ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 15:53:49 -0000 On 1/5/11 7:24 AM, Olafur Gudmundsson wrote: > On 05/01/2011 10:12 AM, Paul Hoffman wrote: >> On 1/5/11 7:08 AM, Olafur Gudmundsson wrote: >>> On 04/01/2011 5:34 PM, Paul Hoffman wrote: >> >>>> It belongs in the draft because it makes no sense to have a signature >>>> that is ECDSA with the P-384 curve and SHA-384 that is pointed to by a >>>> DS of SHA-256: that gives an attacker a unneeded opening. >>>> >>> >>> >>> Trying to interpret your statement above, is this a fair >>> generalization? >>> "DS digest should/must be as strong as the DNSKEY it points to ?" >> >> With a non-normative slant, yes. Maybe "the DS digest should be able to >> be as strong as the DNSKEY signature that it covers". If someone wants >> to cover a strong signature with a weak hash, or vice versa, that's >> their choice, of course. >> > > Thinking ahead, why not just define SHA-512 DS and skip the 384 ? That's two very separate questions. - I tend not to propose protocol elements that I doubt I could use myself. I see no cryptographic purpose to SHA-512 DSs if there are no signatures that require that strength hash. I know of no cryptographic reason to have signatures whose effective strength is greater than 192 bits. - There are operational advantages of SHA-384 over SHA-512, namely size on the wire. Thus, "skipping" SHA-384 would waste bandwidth without offering any advantage. From dol@cryptocom.ru Wed Jan 5 08:11:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AE9A3A6B78 for ; Wed, 5 Jan 2011 08:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0N+jRD8kQ60W for ; Wed, 5 Jan 2011 08:11:04 -0800 (PST) Received: from mx.cryptocom.ru (mx.cryptocom.ru [89.188.97.107]) by core3.amsl.com (Postfix) with ESMTP id CB81D3A6B90 for ; Wed, 5 Jan 2011 08:11:03 -0800 (PST) Received: from [192.168.63.201] (unknown [91.79.139.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id A96E646451 for ; Wed, 5 Jan 2011 19:13:08 +0300 (MSK) Message-ID: <4D249894.1030701@cryptocom.ru> Date: Wed, 05 Jan 2011 19:13:08 +0300 From: Basil Dolmatov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <4D248D29.50804@ogud.com> <4D24948A.7080002@vpnc.org> In-Reply-To: <4D24948A.7080002@vpnc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 16:11:13 -0000 05.01.2011 18:55, Paul Hoffman пишет: > On 1/5/11 7:24 AM, Olafur Gudmundsson wrote: >> On 05/01/2011 10:12 AM, Paul Hoffman wrote: >>> On 1/5/11 7:08 AM, Olafur Gudmundsson wrote: >>>> On 04/01/2011 5:34 PM, Paul Hoffman wrote: >>> >>>>> It belongs in the draft because it makes no sense to have a signature >>>>> that is ECDSA with the P-384 curve and SHA-384 that is pointed to >>>>> by a >>>>> DS of SHA-256: that gives an attacker a unneeded opening. >>>>> >>>> >>>> >>>> Trying to interpret your statement above, is this a fair >>>> generalization? >>>> "DS digest should/must be as strong as the DNSKEY it points to ?" >>> >>> With a non-normative slant, yes. Maybe "the DS digest should be able to >>> be as strong as the DNSKEY signature that it covers". If someone wants >>> to cover a strong signature with a weak hash, or vice versa, that's >>> their choice, of course. >>> >> >> Thinking ahead, why not just define SHA-512 DS and skip the 384 ? > > That's two very separate questions. > > - I tend not to propose protocol elements that I doubt I could use > myself. I see no cryptographic purpose to SHA-512 DSs if there are no > signatures that require that strength hash. I know of no cryptographic > reason to have signatures whose effective strength is greater than 192 > bits. No signatures are requiring any "strength of hash". The implementors are the only persons who can require some strength from some elements of security chain. The obvious reason for implementor to require something is to ensure that all elements in this chain are equally reliable. Unfortunately, "bits of strength" are not the obvious characteristics of reliability which are good for comparison in all cases. So, the demand of equality of some bits figures looks somewhat artificial. dol@ > > - There are operational advantages of SHA-384 over SHA-512, namely > size on the wire. Thus, "skipping" SHA-384 would waste bandwidth > without offering any advantage. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From Internet-Drafts@ietf.org Wed Jan 5 08:30:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4DB13A6C1F; Wed, 5 Jan 2011 08:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCuOAX0zjlwj; Wed, 5 Jan 2011 08:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46DCA3A6B78; Wed, 5 Jan 2011 08:30:02 -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.10 Message-ID: <20110105163002.18428.42035.idtracker@localhost> Date: Wed, 05 Jan 2011 08:30:02 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-registry-fixes-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 16:30:04 -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 : Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Author(s) : S. Rose Filename : draft-ietf-dnsext-dnssec-registry-fixes-07.txt Pages : 7 Date : 2011-01-05 The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms that is incomplete in that it lacks the implementation status of each algorithm. This document provides an applicability statement on algorithm implementation compliance status for DNSSEC implementations. This status is to measure compliance to this RFC only. This document replaces that registry table with a new IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers that lists (or assigns) each algorithm's status based on the current reference. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-fixes-07.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-dnssec-registry-fixes-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-05082225.I-D@ietf.org> --NextPart-- From scott.rose@nist.gov Wed Jan 5 08:53:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C643A6C40 for ; Wed, 5 Jan 2011 08:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.151 X-Spam-Level: **** X-Spam-Status: No, score=4.151 tagged_above=-999 required=5 tests=[AWL=-10.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, VIRUS_WARNING250=1.5, VIRUS_WARNING66=20] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saFGQEyVUdKT for ; Wed, 5 Jan 2011 08:53:28 -0800 (PST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 70E023A6C21 for ; Wed, 5 Jan 2011 08:53:26 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p05GtaZ1001607 for ; Wed, 5 Jan 2011 11:55:36 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 5 Jan 2011 11:55:16 -0500 From: "Rose, Scott W." To: "dnsext@ietf.org" Date: Wed, 5 Jan 2011 11:55:18 -0500 Thread-Topic: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-registry-fixes-07.txt Thread-Index: Acus+VK6Q4vb7ua/RG6yyCT3TIX44w== Message-ID: <0B0D32E9-C71F-4C9B-9E15-FD359A09F7E0@nist.gov> References: <20110105163002.18428.42035.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_0B0D32E9C71F4C9B9E15FD359A09F7E0nistgov_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be infected X-NIST-MailScanner-From: scott.rose@nist.gov Subject: [dnsext] {Blocked Content} Fwd: I-D Action:draft-ietf-dnsext-dnssec-registry-fixes-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 16:53:29 -0000 --_004_0B0D32E9C71F4C9B9E15FD359A09F7E0nistgov_ Content-Type: text/plain; charset="us-ascii" Warning: This message has had one or more attachments removed Warning: (not named). Warning: Please read the following for more information. Updated the table to stress that the column on compliance refers to compliance to this document only. Changed other text to reflect that as much as possible. If any text is unclear, or if I forgot to change something, let me know. Scott Begin forwarded message: > From: "Internet-Drafts@ietf.org" > Date: January 5, 2011 11:30:02 AM EST > To: "i-d-announce@ietf.org" > Cc: "dnsext@ietf.org" > Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-registry-fixes-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. > > > Title : Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry > Author(s) : S. Rose > Filename : draft-ietf-dnsext-dnssec-registry-fixes-07.txt > Pages : 7 > Date : 2011-01-05 > > The DNS Security Extensions (DNSSEC) requires the use of > cryptographic algorithm suites for generating digital signatures over > DNS data. There is currently an IANA registry for these algorithms > that is incomplete in that it lacks the implementation status of each > algorithm. This document provides an applicability statement on > algorithm implementation compliance status for DNSSEC > implementations. This status is to measure compliance to this RFC > only. This document replaces that registry table with a new IANA > registry table for Domain Name System Security (DNSSEC) Algorithm > Numbers that lists (or assigns) each algorithm's status based on the > current reference. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-fixes-07.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. --_004_0B0D32E9C71F4C9B9E15FD359A09F7E0nistgov_ Content-Type: text/plain; charset="ISO-8859-1"; name="NIST-Attachment-Warning.txt" Content-Disposition: inline; filename="NIST-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail itac@nist.gov and include the whole of this message in your request. Alternatively, you can call them on x5375, with the contents of this message at hand when you call. At Wed Jan 5 11:55:38 2011 the virus scanner said: External message bodies cannot be scanned and are removed Note to iTAC: Look on the NIST MailScanner1 in /var/spool/MailScanner/quara= ntine/20110105 (message p05GtaZ1001607). --=20 Postmaster National Institute of Standards and Technology --_004_0B0D32E9C71F4C9B9E15FD359A09F7E0nistgov_ Content-Type: text/plain; name="ATT00001..c" Content-Description: ATT00001..c Content-Disposition: attachment; filename="ATT00001..c"; size=137; creation-date="Wed, 05 Jan 2011 11:55:13 GMT"; modification-date="Wed, 05 Jan 2011 11:55:13 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NDQpkbnNleHQgbWFpbGluZyBsaXN0DQ0KZG5zZXh0QGlldGYub3JnDQ0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNleHQN DQo= --_004_0B0D32E9C71F4C9B9E15FD359A09F7E0nistgov_ Content-Type: text/plain; name="ATT00001..c" Content-Description: ATT00001..c Content-Disposition: attachment; filename="ATT00001..c"; size=185; creation-date="Wed, 05 Jan 2011 11:55:13 GMT"; modification-date="Wed, 05 Jan 2011 11:55:13 GMT" Content-Transfer-Encoding: base64 DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KU2NvdHQg Um9zZQ0KTklTVA0Kc2NvdHRyQG5pc3QuZ292DQorMSAzMDEtOTc1LTg0MzkN Ckdvb2dsZSBWb2ljZTogKzEgNTcxLTI0OS0zNjcxDQpodHRwOi8vd3d3LmRu c29wcy5nb3YvDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KDQo= --_004_0B0D32E9C71F4C9B9E15FD359A09F7E0nistgov_-- From paul.hoffman@vpnc.org Wed Jan 5 09:40:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AFE83A6C69 for ; Wed, 5 Jan 2011 09:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.651 X-Spam-Level: X-Spam-Status: No, score=-101.651 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JIXes2uqx-k for ; Wed, 5 Jan 2011 09:40:53 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 828733A6AF4 for ; Wed, 5 Jan 2011 09:40:53 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p05HgxX8028629 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 5 Jan 2011 10:43:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D24ADA3.20305@vpnc.org> Date: Wed, 05 Jan 2011 09:42:59 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 17:40:54 -0000 On 1/5/11 7:38 AM, Edward Lewis wrote: > At 7:12 -0800 1/5/11, Paul Hoffman wrote: > >> With a non-normative slant, yes. Maybe "the DS digest should be able >> to be >> as strong as the DNSKEY signature that it covers". If someone wants to >> cover >> a strong signature with a weak hash, or vice versa, that's their choice, >> of course. > > I'd like to see this stated in DNS terms - i.e., the notion of strength > is not one of them. If this was *DNS*SEC, I would agree. However, this is more DNS*SEC*. In security, strength is particularly important. > I would suggest that > > - the authoritative set of the DS record SHOULD include a DS RR for each > key that is of the same hash algorithm as is used in the key and MAY > have other hashes (and MAY even have only other hashes[1]) > > [1] The parenthetical comment is redundant, put it there for emphasis. That idea (with a bit more careful wording) would work fine for current signature schemes. It might fall apart later, but it works fine for all the signature schemes under consideration. > - a validator SHOULD prefer the DS record of the same hash algorithm > over other hash algorithms for a key. Prefer means that it SHOULD be the > first tried and if it fails, the validator MAY declare failure without > examining the other applicable hash algorithms. A validator MUST NOT > require that there be a hash of the same algorithm present, with require > meaning - if such a hash is absent, failure is not automatic. Ditto. > You may note that I spec "the same hash algorithm" because I don't know > of any way to say if one hash algorithm is stronger than the next. I.e., > bit length might be an indicator but I bet it also isn't reliable. It is reliable as long as the hash algorithm does not have known pre-image weaknesses. None of the hash algorithms under consideration do, and in fact there are no practical pre-image attacks even for the soon-to-be-deprecated MD5. There is no future guarantee that this will be the case, of course. But, getting back to the cryptography you don't want to discuss, note that your use of "the same hash algorithm" assumes that a pre-image attack on the contents of something signed will have the same effect as a pre-image attack on the DS record. That is extremely unlikely to be true, as we have seen in recent collision attacks. Regardless, if you are unwilling to talk about strengths, using the same hash algorithm in both places is currently the best way around it. On 1/5/11 8:13 AM, Basil Dolmatov wrote: > No signatures are requiring any "strength of hash". Signers sign with some assumption of the strength of the signature against attack. One significant factor in that strength is the strength of the hash against pre-image attacks. > The implementors are the only persons who can require some strength from > some elements of security chain. True, but irrelevant. > The obvious reason for implementor to require something is to ensure > that all elements in this chain are equally reliable. Unfortunately, > "bits of strength" are not the obvious characteristics of reliability > which are good for comparison in all cases. We disagree here. I understand that, given the tight limitations of GOST, that might be true in your market. However, in a future world where there are multiple hash algorithms (thinking ahead to SHA-3), some of which will have the same effective strengths, effective strength is a reasonable measurement. > So, the demand of equality of some bits figures looks somewhat artificial. In the GOST world, yes; in the less-restricted space of open standards, no. From paul.hoffman@vpnc.org Wed Jan 5 09:50:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A7A3A6C69 for ; Wed, 5 Jan 2011 09:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.653 X-Spam-Level: X-Spam-Status: No, score=-101.653 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1X4T8LG+vFiF for ; Wed, 5 Jan 2011 09:50:17 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A9D973A681C for ; Wed, 5 Jan 2011 09:50:13 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p05HqJX2029484 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 5 Jan 2011 10:52:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D24AFD3.4040604@vpnc.org> Date: Wed, 05 Jan 2011 09:52:19 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110105163002.18428.42035.idtracker@localhost> <0B0D32E9-C71F-4C9B-9E15-FD359A09F7E0@nist.gov> In-Reply-To: <0B0D32E9-C71F-4C9B-9E15-FD359A09F7E0@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Fwd: I-D Action:draft-ietf-dnsext-dnssec-registry-fixes-07.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 17:50:20 -0000 On 1/5/11 8:55 AM, Rose, Scott W. wrote: > Updated the table to stress that the column on compliance refers to compliance to this document only. Changed other text to reflect that as much as possible. > > If any text is unclear, or if I forgot to change something, let me know. Thanks, Scott. This is much clearer than the last draft, and I think most people looking at the proposed registry will have a much better understanding of what it means. This clears up all the WGLC comments I had; let's ship it off to the AD! --Paul Hoffman, Director --VPN Consortium From Ed.Lewis@neustar.biz Wed Jan 5 10:14:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F453A6C9F for ; Wed, 5 Jan 2011 10:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.843 X-Spam-Level: X-Spam-Status: No, score=-101.843 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356, SARE_SUB_8CONS_WORD=0.36, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMfoCbFSOvvH for ; Wed, 5 Jan 2011 10:14:02 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 54F163A681C for ; Wed, 5 Jan 2011 10:14:02 -0800 (PST) Received: from gdun-e4300.cis.neustar.com (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p05IG1gY066555; Wed, 5 Jan 2011 13:16:02 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.116] by gdun-e4300.cis.neustar.com (PGP Universal service); Wed, 05 Jan 2011 13:16:08 -0500 X-PGP-Universal: processed; by gdun-e4300.cis.neustar.com on Wed, 05 Jan 2011 13:16:08 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D24ADA3.20305@vpnc.org> References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <4D24ADA3.20305@vpnc.org> Date: Wed, 5 Jan 2011 13:15:59 -0500 To: Paul Hoffman From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: [dnsext] strngths, was Re: Adopting draft:... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 18:14:03 -0000 At 9:42 -0800 1/5/11, Paul Hoffman wrote: >...Regardless, if you are unwilling to talk about strengths, using >the same hash algorithm in both places is currently the best way >around it. Exactly why I used that term. It's one thing to define equivalence, it's another to define ordering (in this case, strength). I don't question the notion of strength in the cryptographic sense, I just don't see how you can translate that into a DNS document in a way that will be helpful to DNS operators. Out of pure curiosity about the threat of pre-image attacks, are the attacks possible within the DNS message format? I mean, I have heard that one can forge a PDF file to match the hash of another, for the purposes of changing the meaning of the file. I assume this takes more than a few bits of diddling to do. If I sign a single A record, how can a forgery be concocted to replace the set? I don't mean 1 for 1 necessarily, maybe it would take 10 or so. Is MD5 really broken within the confines of DNS? (My point is that thie is *DNS*SEC and not DNS*SEC*.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 The 21st Century is 10% complete. From cet1@hermes.cam.ac.uk Wed Jan 5 10:37:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BDB13A6C9F for ; Wed, 5 Jan 2011 10:37: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1jg4gsagtnP for ; Wed, 5 Jan 2011 10:37:38 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 13A9E3A6C69 for ; Wed, 5 Jan 2011 10:37:37 -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]:53268) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:cet1) id 1PaYGs-0004fI-pc (Exim 4.72) (return-path ); Wed, 05 Jan 2011 18:39:42 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1PaYGr-0006N6-Vu (Exim 4.67) (return-path ); Wed, 05 Jan 2011 18:39:41 +0000 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.3); 05 Jan 2011 18:39:41 +0000 Date: 05 Jan 2011 18:39:41 +0000 From: Chris Thompson To: Edward Lewis Message-ID: In-Reply-To: References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> X-Mailer: Prayer v1.3.3 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 18:37:39 -0000 On Jan 5 2011, Edward Lewis wrote: >I'd like to see this stated in DNS terms - i.e., the notion of >strength is not one of them. > >I would suggest that > > - the authoritative set of the DS record SHOULD include a DS RR for >each key that is of the same hash algorithm as is used in the key and >MAY have other hashes (and MAY even have only other hashes[1]) > >[1] The parenthetical comment is redundant, put it there for emphasis. > > - a validator SHOULD prefer the DS record of the same hash algorithm >over other hash algorithms for a key. You mean that a validator should prefer a digest type 1 (SHA-1) DS over a type 2 (SHA-256) DS if the key to be validated uses algorithm RSASHA1? This directly contradicts the SHOULD in RFC 4509 section 3, and also doesn't seem too sensible to me. > Prefer means that it SHOULD be >the first tried and if it fails, the validator MAY declare failure >without examining the other applicable hash algorithms. A validator >MUST NOT require that there be a hash of the same algorithm present, >with require meaning - if such a hash is absent, failure is not >automatic. > >You may note that I spec "the same hash algorithm" because I don't >know of any way to say if one hash algorithm is stronger than the >next. I.e., bit length might be an indicator but I bet it also isn't >reliable. It's perfectly possible for an implementor, or an operator, to have opinions about this, though. -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From dol@cryptocom.ru Wed Jan 5 10:50:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E893A6C40 for ; Wed, 5 Jan 2011 10:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPerkJvIsafX for ; Wed, 5 Jan 2011 10:50:36 -0800 (PST) Received: from mx.cryptocom.ru (mx.cryptocom.ru [89.188.97.107]) by core3.amsl.com (Postfix) with ESMTP id B6FCF3A6BE9 for ; Wed, 5 Jan 2011 10:50:36 -0800 (PST) Received: from [192.168.63.201] (unknown [91.79.139.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id DA58946451 for ; Wed, 5 Jan 2011 21:52:41 +0300 (MSK) Message-ID: <4D24BDF9.4020406@cryptocom.ru> Date: Wed, 05 Jan 2011 21:52:41 +0300 From: Basil Dolmatov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <4D24ADA3.20305@vpnc.org> In-Reply-To: <4D24ADA3.20305@vpnc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 18:50:39 -0000 05.01.2011 20:42, Paul Hoffman пишет: > > > The obvious reason for implementor to require something is to ensure > > that all elements in this chain are equally reliable. Unfortunately, > > "bits of strength" are not the obvious characteristics of reliability > > which are good for comparison in all cases. > > We disagree here. I understand that, given the tight limitations of > GOST, that might be true in your market. However, in a future world > where there are multiple hash algorithms (thinking ahead to SHA-3), > some of which will have the same effective strengths, effective > strength is a reasonable measurement. > > > So, the demand of equality of some bits figures looks somewhat > artificial. > > In the GOST world, yes; in the less-restricted space of open > standards, no. I did not make any GOST references, moreover I did not imply any GOST peculiarities in my comment, it is true for _any_ algorithm (the fact that GOST belongs to "space of open standards" too is worth mentioning, but irrelevant). In any space of cryptographic standards the strength of algorithm is measured not by "bits of strength" or "bits of key or hash length" but by the number of operations which should be performed for given attack. If one bothers to compare the algorithm strength more accurately then the product of (operations)*(memory required) is used. Other figures have mostly marketing meaning rather than technical one. dol@ From paul.hoffman@vpnc.org Wed Jan 5 10:52:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469FE3A6CBB for ; Wed, 5 Jan 2011 10:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.298 X-Spam-Level: X-Spam-Status: No, score=-101.298 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, SARE_SUB_6CONS_WORD=0.356, SARE_SUB_8CONS_WORD=0.36, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zixIcRKmwcDO for ; Wed, 5 Jan 2011 10:52:40 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 7A15F3A681C for ; Wed, 5 Jan 2011 10:52:39 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p05Isj61032743 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 5 Jan 2011 11:54:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D24BE75.6030104@vpnc.org> Date: Wed, 05 Jan 2011 10:54:45 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <4D24ADA3.20305@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] strngths, was Re: Adopting draft:... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 18:52:41 -0000 On 1/5/11 10:15 AM, Edward Lewis wrote: > At 9:42 -0800 1/5/11, Paul Hoffman wrote: > >> ...Regardless, if you are unwilling to talk about strengths, using the >> same hash algorithm in both places is currently the best way around it. > > Exactly why I used that term. It's one thing to define equivalence, it's > another to define ordering (in this case, strength). I don't question > the notion of strength in the cryptographic sense, I just don't see how > you can translate that into a DNS document in a way that will be helpful > to DNS operators. Note that the current draft doesn't have anything about strengths in it: this came up in a discussion with Olafur about why I didn't bother to define a SHA-512 DS record. > Out of pure curiosity about the threat of pre-image attacks, are the > attacks possible within the DNS message format? No. There are no practical pre-image attacks for any of the hash algorithms we are talking about, even MD5. It doesn't matter the format of the hashed data: there are none to date for any format until you get to the truly ridiculous sizes of messages (billions of petabytes per hashed message). From paul.hoffman@vpnc.org Wed Jan 5 10:54:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251773A6C78 for ; Wed, 5 Jan 2011 10:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.656 X-Spam-Level: X-Spam-Status: No, score=-101.656 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-SJ+4LMY3oV for ; Wed, 5 Jan 2011 10:54:17 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6A3083A6BE9 for ; Wed, 5 Jan 2011 10:54:17 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p05IuNII032813 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 5 Jan 2011 11:56:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D24BED7.1060007@vpnc.org> Date: Wed, 05 Jan 2011 10:56:23 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 18:54:18 -0000 On 1/5/11 10:39 AM, Chris Thompson wrote: > On Jan 5 2011, Edward Lewis wrote: > >> I'd like to see this stated in DNS terms - i.e., the notion of >> strength is not one of them. >> >> I would suggest that >> >> - the authoritative set of the DS record SHOULD include a DS RR for >> each key that is of the same hash algorithm as is used in the key and >> MAY have other hashes (and MAY even have only other hashes[1]) >> >> [1] The parenthetical comment is redundant, put it there for emphasis. >> >> - a validator SHOULD prefer the DS record of the same hash algorithm >> over other hash algorithms for a key. > > You mean that a validator should prefer a digest type 1 (SHA-1) DS over > a type 2 (SHA-256) DS if the key to be validated uses algorithm RSASHA1? > This directly contradicts the SHOULD in RFC 4509 section 3, and also > doesn't seem too sensible to me. Thank you, Chris. I knew that someone had said something about strengths in an RFC, but I could not remember where. You nailed it. That's not to say that we should have equivalent wording in this document, just that the "cannot say anything about strength" is a new requirement that is not met by earlier standards-track documents from this WG. From paul.hoffman@vpnc.org Wed Jan 5 10:59:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1175B3A6C69 for ; Wed, 5 Jan 2011 10:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.658 X-Spam-Level: X-Spam-Status: No, score=-101.658 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1oBGEshIbzJ for ; Wed, 5 Jan 2011 10:59:04 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 5595A3A6C40 for ; Wed, 5 Jan 2011 10:59:04 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p05J1AnY033024 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 5 Jan 2011 12:01:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D24BFF6.7060704@vpnc.org> Date: Wed, 05 Jan 2011 11:01:10 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <4D24ADA3.20305@vpnc.org> <4D24BDF9.4020406@cryptocom.ru> In-Reply-To: <4D24BDF9.4020406@cryptocom.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 18:59:05 -0000 On 1/5/11 10:52 AM, Basil Dolmatov wrote: > I did not make any GOST references, moreover I did not imply any GOST > peculiarities in my comment, it is true for _any_ algorithm (the fact > that GOST belongs to "space of open standards" too is worth mentioning, > but irrelevant). GOST limits which hash algorithm can be used in signatures to one choice, so that is indeed relevant. > In any space of cryptographic standards the strength of algorithm is > measured not by "bits of strength" or "bits of key or hash length" but > by the number of operations which should be performed for given attack. > If one bothers to compare the algorithm strength more accurately then > the product of (operations)*(memory required) is used. Both are used as measurements, and the one that is most commonly used in discussion is equivalent bit strength. > Other figures have mostly marketing meaning rather than technical one. That was not the IETF consensus when we adopted RFC 3766, which was heavily reviewed in the IETF's cryptographic community. From Ed.Lewis@neustar.biz Wed Jan 5 11:15:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7453A6C78 for ; Wed, 5 Jan 2011 11:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.846 X-Spam-Level: X-Spam-Status: No, score=-101.846 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356, SARE_SUB_8CONS_WORD=0.36, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACaGfW-a0EBf for ; Wed, 5 Jan 2011 11:15:22 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 547783A681C for ; Wed, 5 Jan 2011 11:15:22 -0800 (PST) Received: from gdun-e4300.cis.neustar.com (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p05JHK9I067079; Wed, 5 Jan 2011 14:17:21 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.116] by gdun-e4300.cis.neustar.com (PGP Universal service); Wed, 05 Jan 2011 14:17:27 -0500 X-PGP-Universal: processed; by gdun-e4300.cis.neustar.com on Wed, 05 Jan 2011 14:17:27 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D24BE75.6030104@vpnc.org> References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <4D24ADA3.20305@vpnc.org> <4D24BE75.6030104@vpnc.org> Date: Wed, 5 Jan 2011 14:10:27 -0500 To: Paul Hoffman From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] strngths, was Re: Adopting draft:... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 19:15:23 -0000 At 10:54 -0800 1/5/11, Paul Hoffman wrote: >On 1/5/11 10:15 AM, Edward Lewis wrote: >> Out of pure curiosity about the threat of pre-image attacks, are the >> attacks possible within the DNS message format? > >No. Again asking from pure curiosity, why then are we concerned about strengths and broken hashes? Within the confines of DNS again, that is. I can understand not wanting to use MD5 because it has been discredited and thus code supporting it might disappear from general distribution. And I am not encouraging using any past the grave technology just because we can. My question arises from what seems to be a preoccupation (by others) with attacks via downgrading the "strength" of the cryptography used. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 The 21st Century is 10% complete. From Ed.Lewis@neustar.biz Wed Jan 5 11:19:59 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099013A6C17 for ; Wed, 5 Jan 2011 11:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.206 X-Spam-Level: X-Spam-Status: No, score=-102.206 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aJPpSC6TT3N for ; Wed, 5 Jan 2011 11:19:58 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id F093C3A681C for ; Wed, 5 Jan 2011 11:19:57 -0800 (PST) Received: from gdun-e4300.cis.neustar.com (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p05JLveg067137; Wed, 5 Jan 2011 14:21:58 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.116] by gdun-e4300.cis.neustar.com (PGP Universal service); Wed, 05 Jan 2011 14:22:04 -0500 X-PGP-Universal: processed; by gdun-e4300.cis.neustar.com on Wed, 05 Jan 2011 14:22:04 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D24BED7.1060007@vpnc.org> References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <4D24BED7.1060007@vpnc.org> Date: Wed, 5 Jan 2011 14:21:55 -0500 To: Paul Hoffman From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: [dnsext] RFC 4509 was Re: Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 19:19:59 -0000 At 10:56 -0800 1/5/11, Paul Hoffman wrote: >Thank you, Chris. I knew that someone had said something about strengths in >an RFC, but I could not remember where. You nailed it. > >That's not to say that we should have equivalent wording in this document, >just that the "cannot say anything about strength" is a new requirement that >is not met by earlier standards-track documents from this WG. Looking at 4509, the two places "strength" is mentioned is here: 6.2. SHA-1 vs. SHA-256 Considerations for DS Records Users of DNSSEC are encouraged to deploy SHA-256 as soon as software implementations allow for it. SHA-256 is widely believed to be more resilient to attack than SHA-1, and confidence in SHA-1's strength is being eroded by recently announced attacks.... My comment about needing references applies to that - "recently announced attacks" is unsupported by a reference. ...It is beyond the scope of this document to speculate extensively on the cryptographic strength of the SHA-256 digest algorithm. And here the document says strength is beyond the scope. In section 3: ...Validator implementations SHOULD ignore DS RRs containing SHA-1 digests if DS RRs with SHA-256 digests are present in the DS RRset. Looking at this, I don't see why this is a good idea if the key is RSA/SHA-1 (algorithm 5 or 7). Well, not a bad idea, but what is gained? If SHA-1 is questionable, why is it more questionable if it's the DS hash than if it is the DNSKEY hash? Isn't the weakest link still SHA-1? (Ignoring the rest of the chain.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 The 21st Century is 10% complete. From jwkckid1@ix.netcom.com Wed Jan 5 11:23:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5A63A6C69 for ; Wed, 5 Jan 2011 11:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUwZHKAhR2k2 for ; Wed, 5 Jan 2011 11:23:54 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 840093A6C17 for ; Wed, 5 Jan 2011 11:23:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=qk/nMRr/gzXgo2a4Fe0RslLwHRRTdmsK2ha0h+XicOCuqXJ4nZ7LxYoeI8ITvwj0; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PaYzh-0006nP-2X for dnsext@ietf.org; Wed, 05 Jan 2011 14:26:01 -0500 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 5 Jan 2011 14:26:00 -0500 Message-ID: <26133275.1294255561010.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Wed, 5 Jan 2011 13:26:00 -0600 (GMT-06:00) From: "Jeffrey A. Williams" To: dnsext@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688677a080fb5fa1ce428211b39f1f998df350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:23:56 -0000 Paul and all, -----Original Message----- >From: Paul Hoffman >Sent: Jan 5, 2011 12:56 PM >To: dnsext@ietf.org >Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt > >On 1/5/11 10:39 AM, Chris Thompson wrote: >> On Jan 5 2011, Edward Lewis wrote: >> >>> I'd like to see this stated in DNS terms - i.e., the notion of >>> strength is not one of them. >>> >>> I would suggest that >>> >>> - the authoritative set of the DS record SHOULD include a DS RR for >>> each key that is of the same hash algorithm as is used in the key and >>> MAY have other hashes (and MAY even have only other hashes[1]) >>> >>> [1] The parenthetical comment is redundant, put it there for emphasis. >>> >>> - a validator SHOULD prefer the DS record of the same hash algorithm >>> over other hash algorithms for a key. >> >> You mean that a validator should prefer a digest type 1 (SHA-1) DS over >> a type 2 (SHA-256) DS if the key to be validated uses algorithm RSASHA1? >> This directly contradicts the SHOULD in RFC 4509 section 3, and also >> doesn't seem too sensible to me. > >Thank you, Chris. I knew that someone had said something about strengths >in an RFC, but I could not remember where. You nailed it. > >That's not to say that we should have equivalent wording in this >document, just that the "cannot say anything about strength" is a new >requirement that is not met by earlier standards-track documents from >this WG. Why cannot there be anything about strength as a new requirement that is not yet met by earlier standards-track diocuments? >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext Kindest regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 Network security Eng. SR. Eng. Network data security, IT/information security. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From paul.hoffman@vpnc.org Wed Jan 5 11:34:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6693A6C74 for ; Wed, 5 Jan 2011 11:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.302 X-Spam-Level: X-Spam-Status: No, score=-101.302 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, SARE_SUB_6CONS_WORD=0.356, SARE_SUB_8CONS_WORD=0.36, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssQP7oMIhSYe for ; Wed, 5 Jan 2011 11:34:29 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CE3BD3A6AB5 for ; Wed, 5 Jan 2011 11:34:29 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p05JaZ8H034334 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 5 Jan 2011 12:36:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D24C843.90309@vpnc.org> Date: Wed, 05 Jan 2011 11:36:35 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <4D24ADA3.20305@vpnc.org> <4D24BE75.6030104@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] strngths, was Re: Adopting draft:... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 19:34:31 -0000 On 1/5/11 11:10 AM, Edward Lewis wrote: > At 10:54 -0800 1/5/11, Paul Hoffman wrote: >> On 1/5/11 10:15 AM, Edward Lewis wrote: > >>> Out of pure curiosity about the threat of pre-image attacks, are the >>> attacks possible within the DNS message format? >> >> No. > > Again asking from pure curiosity, why then are we concerned about > strengths and broken hashes? Within the confines of DNS again, that is. Strengths matter because, even with no brokenness, some hashes are stronger than others with respect to pre-image attacks. SHA-256 is inherently stronger than SHA-1 by 96 bits of equivalent strength. We are currently not concerned about breaking of the pre-image strength because we have no idea what such a break would mean. A zillion assumptions in all security protocols would come into question if there was any practical pre-image reduction in a hash being commonly used. We should be concerned about reductions in collision strength only if it turns out that DNSSEC uses hashes in a way that can be affected by such a reduction. To date, no one has shown how that affects DNSSEC, even though there have been some pretty creative collision attacks on systems that rely on PKIX certificate chaining. A few people might insist that some collision attack is important in some corner cases, but that's where the hard cryptography ends and the sober world of consensus starts. > I can understand not wanting to use MD5 because it has been discredited > and thus code supporting it might disappear from general distribution. > And I am not encouraging using any past the grave technology just > because we can. My question arises from what seems to be a preoccupation > (by others) with attacks via downgrading the "strength" of the > cryptography used. Such arguments are in the same category as "the DNS doesn't scale" and its ilk. If you don't define your terms carefully, you can make arguments about almost anything. When you define your terms carefully, others can decide whether or not your argument applies to a significant portion of the world. From brian.peter.dickson@gmail.com Wed Jan 5 12:22:46 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED2D3A6D01 for ; Wed, 5 Jan 2011 12:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356, SARE_SUB_8CONS_WORD=0.36] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBnwQyy6gHEJ for ; Wed, 5 Jan 2011 12:22:44 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5460C3A6CEC for ; Wed, 5 Jan 2011 12:22:44 -0800 (PST) Received: by fxm9 with SMTP id 9so15454832fxm.31 for ; Wed, 05 Jan 2011 12:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EWaYfgeV8ly9NScAuKwx8qveTYCpTBWkPxw7dD9KRkg=; b=pKc+lmmR32IzYzJszOPe1B6KTV9oVgrZZ28I9Dpx54VUWuMfuU8j+6brSp25WyuCC0 cBpYFVaBjIxWymX6oo7GRMZkL95WRbtCMZadYA2knoYJRoLYMilE6Qy+ezAXG9AyBY9s OA4OMWyfrEEFRZ2+6h2Zfs+Ad1obCHx+VgbKs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CF9nrTNO5EGLpEE8ZgaHsJIPW20TbAEUrAx7WITh+uNmG5WK67Y1xwKT2ITdF3OS8S qyYB2F5VffnRM2zzBb/u6YUgXkpaKsBa+A+BeF0rj7qKjW994rl6opFs2241R7ECvJNZ flSxtPs4ynmUitufF1g9khHm4XGxmxG2EnDEU= MIME-Version: 1.0 Received: by 10.223.112.79 with SMTP id v15mr410756fap.143.1294259090801; Wed, 05 Jan 2011 12:24:50 -0800 (PST) Received: by 10.223.111.142 with HTTP; Wed, 5 Jan 2011 12:24:50 -0800 (PST) In-Reply-To: References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <4D24ADA3.20305@vpnc.org> Date: Wed, 5 Jan 2011 16:24:50 -0400 Message-ID: From: Brian Dickson To: Edward Lewis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] strngths, was Re: Adopting draft:... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 20:22:46 -0000 On Wed, Jan 5, 2011 at 2:15 PM, Edward Lewis wrote: > If I sign a single A record, how can a forgery be concocted to replace th= e > set? =A0I don't mean 1 for 1 necessarily, maybe it would take 10 or so. = =A0Is > MD5 really broken within the confines of DNS? =A0(My point is that thie i= s > *DNS*SEC and not DNS*SEC*.) I don't think you can for an A record per se, but it might be possible for other record types. If you can forge the delegation to the zone containing the A record, it makes the forging the A signature unnecessary. Can we (do the latter)? In order to forge (given what we know of the MD5 weakness), it is necessary to fit in 128 bytes of arbitrary data, aligned on a 64-byte boundary. The math of 2^n works against us here, in terms of the ability to get things aligned. The only factors of 2^n are 2^m (for m < n), which means that unless *both* the RRSIG RDATA (less the signature itself) *and* the canonical wire-format of the RR of the covered RR type, happen to be of length 2^x and 2^y respectively, it is possible to add more forged RR records to the set until the RR RDATA is aligned on the 64-byte boundary. The question then becomes, are any "important" RR types capable of having arbitrary 128-byte RDATA values? I don't know offhand, but I suspect that the NS record can, since the DNS protocol itself allows binary labels long enough. It may boil down to canonical sort order, on a given NS set (!!!). This means insecure delegations from zones signed with MD5 might be vulnera= ble. Whether corresponding DS records can similarly be "forged" (e.g. by synthesizing DNSKEY values in the redirected delegated zone) when SHA-1 is the hash for DS, is beyond my ability to figure out... If it is, then it would imply that MD5 is fatally broken, since any delegation signed with MD5, secure or otherwise, could be forged. But, even insecure delegations being forged is bad enough... Brian From Francis.Dupont@fdupont.fr Wed Jan 5 14:30:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D58B3A6D0B for ; Wed, 5 Jan 2011 14:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGBFAq6asFPQ for ; Wed, 5 Jan 2011 14:30:12 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 875E83A67D6 for ; Wed, 5 Jan 2011 14:30:12 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p05MWIZI043441; Wed, 5 Jan 2011 22:32:18 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101052232.p05MWIZI043441@givry.fdupont.fr> From: Francis Dupont To: Edward Lewis In-reply-to: Your message of Wed, 05 Jan 2011 10:38:33 EST. Date: Wed, 05 Jan 2011 23:32:18 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 22:30:13 -0000 In your previous mail you wrote: - a validator SHOULD prefer the DS record of the same hash algorithm over other hash algorithms for a key. Prefer means that it SHOULD be the first tried and if it fails, the validator MAY declare failure without examining the other applicable hash algorithms. => thanks to have opened the can of worms about the validator behavior when there are more than more than one DS RR using different digest algorithm. Today only the case SHA-1 vs. SHA-256 is clear. Regards Francis.Dupont@fdupont.fr From dburk@burkov.aha.ru Wed Jan 5 14:43:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36C53A6D02 for ; Wed, 5 Jan 2011 14:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.823 X-Spam-Level: X-Spam-Status: No, score=0.823 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HELO_IS_SMALL6=0.556, HOST_EQ_RU=0.875, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+vaeC5FrKGz for ; Wed, 5 Jan 2011 14:43:00 -0800 (PST) Received: from aha.ru (backend13.aha.ru [62.113.86.202]) by core3.amsl.com (Postfix) with ESMTP id 669363A6CD9 for ; Wed, 5 Jan 2011 14:42:59 -0800 (PST) Received: from [92.36.68.246] (account dburk@burkov.aha.ru HELO [192.168.0.128]) by backend13.aha.ru (CommuniGate Pro SMTP 4.3.11) with ESMTPSA id 67719770; Thu, 06 Jan 2011 01:45:04 +0300 References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <4D24ADA3.20305@vpnc.org> <4D24BDF9.4020406@cryptocom.ru> <4D24BFF6.7060704@vpnc.org> In-Reply-To: <4D24BFF6.7060704@vpnc.org> Mime-Version: 1.0 (iPad Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <827829D4-F559-4511-895F-AC2E402A5E54@burkov.aha.ru> X-Mailer: iPad Mail (8C148) From: Dmitry Burkov Date: Thu, 6 Jan 2011 01:48:18 +0300 To: Paul Hoffman Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 22:43:01 -0000 Strange discussion for me - if it can be named a discussion :-) gost belongs to national recommendations with all their typical faults and m= istakes yes, if it was openly described and implemenented in open source - i can't u= nderstand what's the issue? you can use it or not - it's your choice the choice for russian authourity to issue new recommendations which can be m= ore strength then some alternatives :-) - it is not a problem - i hope - if s= omeone don't like competitors - it doesn't mean that they are dead=20 Or I am wrong and someone is not satisfied that russian authorities simply d= idn't provided newest algorithms in open source?=20 Sent from my iPad On 05.01.2011, at 22:01, Paul Hoffman wrote: > On 1/5/11 10:52 AM, Basil Dolmatov wrote: >> I did not make any GOST references, moreover I did not imply any GOST >> peculiarities in my comment, it is true for _any_ algorithm (the fact >> that GOST belongs to "space of open standards" too is worth mentioning, >> but irrelevant). >=20 > GOST limits which hash algorithm can be used in signatures to one choice, s= o that is indeed relevant. >=20 >> In any space of cryptographic standards the strength of algorithm is >> measured not by "bits of strength" or "bits of key or hash length" but >> by the number of operations which should be performed for given attack. >> If one bothers to compare the algorithm strength more accurately then >> the product of (operations)*(memory required) is used. >=20 > Both are used as measurements, and the one that is most commonly used in d= iscussion is equivalent bit strength. >=20 >> Other figures have mostly marketing meaning rather than technical one. >=20 > That was not the IETF consensus when we adopted RFC 3766, which was heavil= y reviewed in the IETF's cryptographic community. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From wwwrun@rfc-editor.org Wed Jan 5 14:16:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247F73A6CD9 for ; Wed, 5 Jan 2011 14:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.807 X-Spam-Level: X-Spam-Status: No, score=-99.807 tagged_above=-999 required=5 tests=[AWL=-2.207, BAYES_00=-2.599, GB_SUMOF=5, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwvuSJb3Eq5x for ; Wed, 5 Jan 2011 14:16:08 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 6FE253A67D6 for ; Wed, 5 Jan 2011 14:16:08 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A7E0FE0701; Wed, 5 Jan 2011 14:18:15 -0800 (PST) To: roy.arends@telin.nl, sra@isc.org, mlarson@verisign.com, massey@cs.colostate.edu, scott.rose@nist.gov, rdroms.ietf@gmail.com, jari.arkko@piuha.net, ogud@ogud.com, ajs@shinkuro.com From: RFC Errata System Message-Id: <20110105221815.A7E0FE0701@rfc-editor.org> Date: Wed, 5 Jan 2011 14:18:15 -0800 (PST) X-Mailman-Approved-At: Wed, 05 Jan 2011 14:46:53 -0800 Cc: gubailey@microsoft.com, dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] [Technical Errata Reported] RFC4034 (2681) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 22:16:09 -0000 The following errata report has been submitted for RFC4034, "Resource Records for the DNS Security Extensions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4034&eid=2681 -------------------------------------- Type: Technical Reported by: Guillaume Bailey Section: B Original Text ------------- The key tag is the same for all DNSKEY algorithm types except algorithm 1 (please see Appendix B.1 for the definition of the key tag for algorithm 1). The key tag algorithm is the sum of the wire format of the DNSKEY RDATA broken into 2 octet groups. First, the RDATA (in wire format) is treated as a series of 2 octet groups. These groups are then added together, ignoring any carry bits. Corrected Text -------------- The key tag is the same for all DNSKEY algorithm types except algorithm 1 (please see Appendix B.1 for the definition of the key tag for algorithm 1). The key tag algorithm is the sum of the wire format of the DNSKEY RDATA broken into 2 octet groups. First, the RDATA (in wire format) is treated as a series of 2 octet groups. These groups are then added together with at least 32-bit precision, retaining any carry bits. The carry bits are then added to the result, and finally, only the lower 16 bits of the result are used as the key tag. Notes ----- This change comes from the example implementation. The accumulator, ac, is required ("assumed") to be 32-bits or larger, and the carry bits are added to the accumulator before returning: ac += (ac >> 16) & 0xFFFF; Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4034 (draft-ietf-dnsext-dnssec-records-11) -------------------------------------- Title : Resource Records for the DNS Security Extensions Publication Date : March 2005 Author(s) : R. Arends, R. Austein, M. Larson, D. Massey, S. Rose Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From Ray.Bellis@nominet.org.uk Thu Jan 6 02:52:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777553A6A1A for ; Thu, 6 Jan 2011 02:52:36 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwNQ-kJuuDc9 for ; Thu, 6 Jan 2011 02:52:35 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id E74DC3A6D1F for ; Thu, 6 Jan 2011 02:52:34 -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=zFJBiTEL5EHGBhVzQDNj5DKndh8BpQlGgEdjVFmxV55FBF51GVbtycYg af7uelj+q3c79TGAe+gub7hcHnrWhmwZNfcaeMkOl0YLrVM0+Hyzsl9FK 2OYH47Jyz57NdPh; 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=1294311282; x=1325847282; 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]=20WG=20Action:=20RECHARTER:=20 DNS=20Extensions=20(dnsext)|Date:=20Thu,=206=20Jan=202011 =2010:54:33=20+0000|Message-ID:=20|To:=20Andrew=20Sullivan=20 |CC:=20""=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20 quoted-printable|Content-ID:=20|In-Reply-To:=20<20101207211455.GS29384@shink uro.com>|References:=20<20101207174352.146FE3A6823@core3. amsl.com>=0D=0A=20=0D=0A=20<20101207194144.GK2938 4@shinkuro.com>=0D=0A=20=0D=0A=20<20101207211455. GS29384@shinkuro.com>; bh=ojUor+T0EjlzlupyL4kZsnCHcEstpJ9vlM4MbHaXPpI=; b=xFv9HbCtxrdr1KVP2UEEhvjd9j7Dmf5fyULHfyFdDFKbZLQDfUL0kguk kDDAnhWl0jG5t7DdpaHssrDK15WBeefYzB38Zt382POpspEYqhF8306od v0wfxQFOOWX1fPE; X-IronPort-AV: E=Sophos;i="4.60,282,1291593600"; d="scan'208";a="23834390" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 06 Jan 2011 10:54:35 +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; Thu, 6 Jan 2011 10:54:35 +0000 From: Ray Bellis To: Andrew Sullivan Thread-Topic: [dnsext] WG Action: RECHARTER: DNS Extensions (dnsext) Thread-Index: AcuWRsqeUkyqMxS9vk66Mb/36MnXjwACthqwAACKQQAFzxNwgA== Date: Thu, 6 Jan 2011 10:54:33 +0000 Message-ID: References: <20101207174352.146FE3A6823@core3.amsl.com> <20101207194144.GK29384@shinkuro.com> <20101207211455.GS29384@shinkuro.com> In-Reply-To: <20101207211455.GS29384@shinkuro.com> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dnsext] WG Action: RECHARTER: DNS Extensions (dnsext) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 10:52:36 -0000 On 7 Dec 2010, at 21:14, Andrew Sullivan wrote: > Right, I saw that. It's a little shy on many of the details, but it's > not wrong, I think. Dave and I knocked that version out during Beijing. The intent was not to be exhaustive, but to list those RFCs which are funda= mentally "core" to DNS. Trying to determine apparently logical groupings f= or the different components was somewhat, umm, challenging... BTW, I've had a few requests to publish the code for the graph generator so= I plan to get around to that soon. kind regards, Ray From Ray.Bellis@nominet.org.uk Fri Jan 7 00:19:49 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC8F3A67EB for ; Fri, 7 Jan 2011 00:19:49 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8F9uGynmkW8j for ; Fri, 7 Jan 2011 00:19:48 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 5C1BF3A67AC for ; Fri, 7 Jan 2011 00:19:47 -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=X60hAn4x77gMVaOQADg+agYbChESlKIyVuBVwjG7kT9qw6zwGE1M1aNV sY/JPlHuSmjf+xGYJNM4+FqSrvXLAeR5KNnZFe+U3vLW+NhdYQkiyHKO4 N6gvBl4+75Ch7EQ; 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=1294388515; x=1325924515; 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]=20WG=20Action:=20RECHARTER:=20 DNS=20Extensions=20(dnsext)|Date:=20Fri,=207=20Jan=202011 =2008:21:52=20+0000|Message-ID:=20|To:=20Andrew=20Sullivan=20 |CC:=20""=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20 quoted-printable|Content-ID:=20<6453fdb0-ed97-4093-aec2-5 08aba951e64>|In-Reply-To:=20<20101207211455.GS29384@shink uro.com>|References:=20<20101207174352.146FE3A6823@core3. amsl.com>=0D=0A=20=0D=0A=20<20101207194144.GK2938 4@shinkuro.com>=0D=0A=20=0D=0A=20<20101207211455. GS29384@shinkuro.com>; bh=i0VkzHV4Yl7ozBp9Fkq9KQfqzvudGPJNzepL3zefLbM=; b=rffwf0Glpm1iMoVFlylwSu0pAzfnRB/BxOg2hUI3D3gHVjDBFVJRs3TB 1vyP/FBjKvQk653/PHeDZIoHmWRTl2gxrRyB3iqXL9R0WHiopQlMxd07C eaupNx+hOedseRR; X-IronPort-AV: E=Sophos;i="4.60,288,1291593600"; d="scan'208";a="23848574" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 07 Jan 2011 08:21:54 +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; Fri, 7 Jan 2011 08:21:53 +0000 From: Ray Bellis To: Andrew Sullivan Thread-Topic: [dnsext] WG Action: RECHARTER: DNS Extensions (dnsext) Thread-Index: AcuWRsqeUkyqMxS9vk66Mb/36MnXjwACthqwAACKQQAF/AjyAA== Date: Fri, 7 Jan 2011 08:21:52 +0000 Message-ID: References: <20101207174352.146FE3A6823@core3.amsl.com> <20101207194144.GK29384@shinkuro.com> <20101207211455.GS29384@shinkuro.com> In-Reply-To: <20101207211455.GS29384@shinkuro.com> 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: <6453fdb0-ed97-4093-aec2-508aba951e64> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dnsext] WG Action: RECHARTER: DNS Extensions (dnsext) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 08:19:49 -0000 On 7 Dec 2010, at 21:14, Andrew Sullivan wrote: > Right, I saw that. It's a little shy on many of the details, but it's > not wrong, I think. Dave and I knocked that version out during Beijing. The intent was not to be exhaustive, but to list those RFCs which are funda= mentally "core" to DNS. Trying to determine logi BTW, I've had a few requests to publish the code for the graph generator so= I plan to get around to that soon. kind regards, Ray From fweimer@bfk.de Fri Jan 7 05:37:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A70E43A68BE for ; Fri, 7 Jan 2011 05:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_6CONS_WORD=0.356, SARE_SUB_8CONS_WORD=0.36] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKOPx-cGLnWI for ; Fri, 7 Jan 2011 05:37:23 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 843053A68BC for ; Fri, 7 Jan 2011 05:37:21 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PbCXM-0002OG-Lp; Fri, 07 Jan 2011 13:39:24 +0000 Received: by bfk.de with local id 1PbCXM-0004im-Gr; Fri, 07 Jan 2011 13:39:24 +0000 To: Edward Lewis References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <4D24ADA3.20305@vpnc.org> From: Florian Weimer Date: Fri, 07 Jan 2011 13:39:24 +0000 In-Reply-To: (Edward Lewis's message of "Wed\, 5 Jan 2011 13\:15\:59 -0500") Message-ID: <82r5coestv.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] strngths, was Re: Adopting draft:... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 13:37:24 -0000 * Edward Lewis: > If I sign a single A record, how can a forgery be concocted to replace > the set? I don't mean 1 for 1 necessarily, maybe it would take 10 or > so. Is MD5 really broken within the confines of DNS? As far as I can tell, MD5 is only broken for hashing sufficiently predictable messages supplied by non-trusted parties, and only for certain message configurations. In most cases, when you sign an A RRset, there is a close relationship between the key holder and the data source, so MD5 would still work. Signing the DS RRset for a delegation is a different matter, though: the data is supplied by an untrusted party, and there is much more wiggle room, too (provided that the signer does not reconstruct the DS RRs from the DNSKEYs in the delegated zone). I haven't tried to implement an actual attack, but I suspect that the attack on MD5-based X.509 certificates could be adapted to hypothetical MD5-based signatures on DS RRsets. (The attack would work by submitting a registration for a previously unregistered domain with crafted DS RRs which causes the MD5 hash to converge with the hash of the domain which is being attacked.) --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From hallam@gmail.com Fri Jan 7 06:30:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 783A23A68D8 for ; Fri, 7 Jan 2011 06:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.889 X-Spam-Level: X-Spam-Status: No, score=-2.889 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IeDa4jxc7Ap for ; Fri, 7 Jan 2011 06:30:50 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id DB9833A68BE for ; Fri, 7 Jan 2011 06:30:49 -0800 (PST) Received: by yie19 with SMTP id 19so5352537yie.31 for ; Fri, 07 Jan 2011 06:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bVTEe0Wud6yeNedB0T4zslRMjkiHWemFR8VFo1bw8II=; b=UQo0Tikqdqfmj8/IbYRqwNNSiXORH6uriYwE9Po5yYSnKHG4+xJ6/JxsoLr8Z9LBF3 P1ZAFjbtZ5Fa10aYW/ysR7+PoPtcC+uLCSxBeX6VLUn7dhIhXH9PeabUWDeIfdUPkBKP 6okEmmJJNUPJsbOqWvzm3/LeU3XUO+q+4CHD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cl9FG4GesSpb2y8v8zmtJHqgUJ+lYrBnsWPW+dxfC7M52CIXsATI9exUf9x8sDzYbF Jo8jWRotK9QvYQ3u3DGIjmuFR+aJD6bXRgDS3L22z/j/OpuqGN5Xk5G3cA7/bhA1cAUu I4citZs8cKDrVRtwkebnYXn7ulxUpIK3I0JYI= MIME-Version: 1.0 Received: by 10.100.93.6 with SMTP id q6mr3124415anb.69.1294410776267; Fri, 07 Jan 2011 06:32:56 -0800 (PST) Received: by 10.100.31.8 with HTTP; Fri, 7 Jan 2011 06:32:56 -0800 (PST) In-Reply-To: References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> Date: Fri, 7 Jan 2011 09:32:56 -0500 Message-ID: From: Phillip Hallam-Baker To: cet1@cam.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Edward Lewis , Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 14:30:52 -0000 Rather than using the term 'strength' I suggest we use the term 'work facto= r'. The term strength tends to be interpreted relative to the algorithm concerned, 'what strength RSA key', it is not really defined as an absolute measure. Work factor using known best attack is much better defined. Although there is always going to be a degree of slop since many attacks have memory/CPu tradeoffs. But all this is really outside the parameters of what DNSEXT should have to concern itself with. What matters most in choice of cryptographic algorithm is consistency. The attacker only needs to break the weakest link in the chain. So if we have SHA3 in the DNSSEC layer and MD5 in the S/MIME we are still vulnerable. I would like to propose we change the model here. The IETF should get out of the business for issuing DNSSEC code points for any algorithm other than those which are mandatory to implement. Mandatory to implement algorithms should be specified in RFCs that apply to a collection of protocols. Working Groups would be free to decide whether to specify their own algorithms or use the common mandatory set. The advantage of using a common mandatory set being that they would be subject to ongoing maintenance and revision. So an implementation that offered DNSSEC with the 2012 crypto set might specify RFC4043 + RFC 7xxx compliance. All non-mandatory crypto would use ASN.1 OIDs to declare the algorithm type. In the case of DNSSEC this would require an approach similar to the one that the OID based CERT type uses. There would be a code point reserved for identifying the algorithm by ASN.1 oid and a defined mechanism for squeezing in the OID as a prefix to the crypto material. Some people are going to complain about the lack of control here. But that is worrying about the wrong problem. The only problems we should be concerned with are interoperability and endorsement. The only interoperability concern should be that applications that support a common algorithm be able to use it to communicate. That means that they all use the same code points to identify the same algorithm. It is not a big concern to me as people who use non standard crypto should know what to expect. It is their funeral, we should not try to stop them attending. The much bigger concern for me is endorsement. The problem with having the IETF control the registry is that making an entry into the registry implies an endorsement. Like it or not, the IETF has effectively endorsed the use of GOST, a Soviet era crypto algorithm that is being promoted for specific political reasons that I believe to be contrary to the principles of an open Internet. The fact that the OID registry is open and has no gating factor is a good thing. No gate means no endorsement. If we had used ASN.1 OIDs to identify algorithms there would be no RFC 5933, there would be no mention of GOST in RFCs at all unless there was a decision to adopt it as a mandatory to implement algorithm (which the GRU would not want in any case since their whole purpose requires use of a different algorithm). On Wed, Jan 5, 2011 at 1:39 PM, Chris Thompson wrote: > On Jan 5 2011, Edward Lewis wrote: > >> I'd like to see this stated in DNS terms - i.e., the notion of strength = is >> not one of them. >> >> I would suggest that >> >> =A0- the authoritative set of the DS record SHOULD include a DS RR for e= ach >> key that is of the same hash algorithm as is used in the key and MAY hav= e >> other hashes (and MAY even have only other hashes[1]) >> >> [1] The parenthetical comment is redundant, put it there for emphasis. >> >> =A0- a validator SHOULD prefer the DS record of the same hash algorithm = over >> other hash algorithms for a key. > > You mean that a validator should prefer a digest type 1 (SHA-1) DS over > a type 2 (SHA-256) DS if the key to be validated uses algorithm RSASHA1? > This directly contradicts the SHOULD in RFC 4509 section 3, and also > doesn't seem too sensible to me. > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Prefer means that it SHOULD be the >> first tried and if it fails, the validator MAY declare failure without >> examining the other applicable hash algorithms. =A0A validator MUST NOT >> require that there be a hash of the same algorithm present, with require >> meaning - if such a hash is absent, failure is not automatic. >> >> You may note that I spec "the same hash algorithm" because I don't know = of >> any way to say if one hash algorithm is stronger than the next. =A0I.e.,= bit >> length might be an indicator but I bet it also isn't reliable. > > It's perfectly possible for an implementor, or an operator, to have > opinions about this, though. > > -- > Chris Thompson =A0 =A0 =A0 =A0 =A0 =A0 =A0 University of Cambridge Comput= ing Service, > Email: cet1@ucs.cam.ac.uk =A0 =A0New Museums Site, Cambridge CB2 3QH, > Phone: +44 1223 334715 =A0 =A0 =A0 United Kingdom. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --=20 Website: http://hallambaker.com/ From fweimer@bfk.de Fri Jan 7 07:13:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3383A68EC for ; Fri, 7 Jan 2011 07:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxr4ON6--lH5 for ; Fri, 7 Jan 2011 07:13:28 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 52BF93A68EA for ; Fri, 7 Jan 2011 07:13:26 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PbE2D-0000tH-Qx; Fri, 07 Jan 2011 15:15:27 +0000 Received: by bfk.de with local id 1PbE1l-0003Qk-SO; Fri, 07 Jan 2011 15:14:53 +0000 To: Phillip Hallam-Baker References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> From: Florian Weimer Date: Fri, 07 Jan 2011 15:14:53 +0000 In-Reply-To: (Phillip Hallam-Baker's message of "Fri\, 7 Jan 2011 09\:32\:56 -0500") Message-ID: <821v4oeoeq.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Edward Lewis , Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 15:13:29 -0000 * Phillip Hallam-Baker: > Work factor using known best attack is much better defined. Nope, because attacks tend to be theoretical, and it is hard to tell if the attacks could actually implemented as described in the technical reports, given sufficient resources. Things like communication overhead in a parallel implementation are difficult to estimate and often not taken into account. Even if this is resolved in some way (but it won't ever happen, I'm pretty sure), you have to deal with the question of trade-offs: how do you fold sizes and bandwidths of several types of storage, processing speeds and communication costs into a single number? If there are working attacks which you can run on real hardware, it makes sense to speak of work factors. But then, you don't want to use the algorithms anymore, so this isn't an interesting case, either. > But all this is really outside the parameters of what DNSEXT should > have to concern itself with. I agree. If there's a solution for this issue (due to very significant advances in cryptography, which are rather unlikely, given past performance), then the DNSSEC standards can use that knowledge. Right now, there is no such thing, at least in the public literature. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From alex@alex.org.uk Fri Jan 7 07:24:08 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCC223A68F1 for ; Fri, 7 Jan 2011 07:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOrI+bLoK-+G for ; Fri, 7 Jan 2011 07:24:07 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id B723A3A68F7 for ; Fri, 7 Jan 2011 07:24:07 -0800 (PST) Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 4210CC562F3; Fri, 7 Jan 2011 15:26:12 +0000 (GMT) Date: Fri, 07 Jan 2011 15:26:11 +0000 From: Alex Bligh To: Phillip Hallam-Baker , cet1@cam.ac.uk Message-ID: <359091FCD895EA0C271718D9@Ximines.local> In-Reply-To: References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> 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: Edward Lewis , Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 07 Jan 2011 15:24:08 -0000 --On 7 January 2011 09:32:56 -0500 Phillip Hallam-Baker wrote: > All non-mandatory crypto would use ASN.1 OIDs to declare the algorithm > type. In the case of DNSSEC this would require an approach similar to > the one that the OID based CERT type uses. There would be a code point > reserved for identifying the algorithm by ASN.1 oid and a defined > mechanism for squeezing in the OID as a prefix to the crypto material. ... > The only interoperability concern should be that applications that > support a common algorithm be able to use it to communicate. That > means that they all use the same code points to identify the same > algorithm. ... > The fact that the OID registry is open and has no gating factor is a > good thing. No gate means no endorsement. If we had used ASN.1 OIDs to > identify algorithms there would be no RFC 5933, there would be no > mention of GOST in RFCs at all unless there was a decision to adopt it > as a mandatory to implement algorithm (which the GRU would not want in > any case since their whole purpose requires use of a different > algorithm). Q: is there sufficient standardisation within the ASN.1 OIDs that if a new crypto type FOO comes along, then 2 implementations, working solely from the OID, they can necessarily interoperate? IE will they thoroughly specify whether FOO options X and Y have to be supported, wire format, etc? To illustrate what I mean, I include below a section from the OpenSSH-5.7 testing release notes. I know ssh != DNSSEC, but I suspect support for a new algorithm might not be as simply described as whether a single ID. -- Alex Bligh * Implement Elliptic Curve Cryptography modes for key exchange (ECDH) and host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA offer better performance than plain DH and DSA at the same equivalent symmetric key length, as well as much shorter keys. Only the mandatory sections of RFC5656 are implemented, specifically the three REQUIRED curves nistp256, nistp384 and nistp521 and only ECDH and ECDSA. Point compression (optional in RFC5656) is NOT implemented. Certificate host and user keys using the new ECDSA key types are supported - an ECDSA key may be certified, and an ECDSA key may act as a CA to sign certificates. ECDH in a 256 bit curve field is the preferred key agreement algorithm when both the client and server support it. ECDSA host keys are preferred when learning a host's keys for the first time. From hallam@gmail.com Fri Jan 7 07:25:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A863A690B for ; Fri, 7 Jan 2011 07:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.664 X-Spam-Level: X-Spam-Status: No, score=-3.664 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld4XJyifeqgP for ; Fri, 7 Jan 2011 07:25:53 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 309C23A6907 for ; Fri, 7 Jan 2011 07:25:53 -0800 (PST) Received: by gwj17 with SMTP id 17so9362761gwj.31 for ; Fri, 07 Jan 2011 07:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sQOwCiEtgI6o71IDAvWiveJIXi7om2L7QyjYCbsQetg=; b=m+M6FmjyCMRDjKWJCZk1fFSWgNkxoSpdYbJPQXqtkr+Sy0ojFeiDN4lt8qZxWIlJPC SHZnpOP7Do/VdoaBoqq9y1hICDB6enqGD1ckQLVZcu656cjMFDCgfigQhzakGFbA01Eo 3CWyznqgzCJ7B1x0B9GjLS+i349Z/UWTrQWYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YAVb1VlIxGGS18NfXDX1oKYFguZtQPfgvmMustIY61yqRcIdDUwHNSc6OBN0ky9M1y 6iDFrMG9CzaOGHPDfHE84AGEqPgoI89KKcu6/mWtg+RZwoN0fkEM2W+eW1vf1jmiNmNb YBFjgcptV6q+eSmQ4rdZSI+YpOCYMDBkDXUrw= MIME-Version: 1.0 Received: by 10.100.228.14 with SMTP id a14mr13670346anh.239.1294414079448; Fri, 07 Jan 2011 07:27:59 -0800 (PST) Received: by 10.100.31.8 with HTTP; Fri, 7 Jan 2011 07:27:59 -0800 (PST) In-Reply-To: <821v4oeoeq.fsf@mid.bfk.de> References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <821v4oeoeq.fsf@mid.bfk.de> Date: Fri, 7 Jan 2011 10:27:59 -0500 Message-ID: From: Phillip Hallam-Baker To: Florian Weimer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Edward Lewis , Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 15:25:54 -0000 Well if the attacks are not theoretical we should not be considering them at all. I would ignore communication for calculation of work factor. Shamir's TWIRL device shows one way of avoiding the communication issue. We are talking about worst case here and we are always going to have a significant degree of ambiguity. But even if you assume infinite memory and infinite communication bandwidth, you can arrive at a lower bound for the work factor. We can also impose reasonable memory constraints like limiting the number of storage locations to the number of atoms in the earth's crust or whatever. But the main point is that while everyone in the IETF is welcome to participate in such a discussion we should be having exactly one discussion, not one per WG. And we certainly should not be having different discussions leading to different conclusions. On Fri, Jan 7, 2011 at 10:14 AM, Florian Weimer wrote: > * Phillip Hallam-Baker: > >> Work factor using known best attack is much better defined. > > Nope, because attacks tend to be theoretical, and it is hard to tell > if the attacks could actually implemented as described in the > technical reports, given sufficient resources. =A0Things like > communication overhead in a parallel implementation are difficult to > estimate and often not taken into account. =A0Even if this is resolved > in some way (but it won't ever happen, I'm pretty sure), you have to > deal with the question of trade-offs: how do you fold sizes and > bandwidths of several types of storage, processing speeds and > communication costs into a single number? > > If there are working attacks which you can run on real hardware, it > makes sense to speak of work factors. =A0But then, you don't want to use > the algorithms anymore, so this isn't an interesting case, either. > >> But all this is really outside the parameters of what DNSEXT should >> have to concern itself with. > > I agree. =A0If there's a solution for this issue (due to very > significant advances in cryptography, which are rather unlikely, given > past performance), then the DNSSEC standards can use that knowledge. > Right now, there is no such thing, at least in the public literature. > > -- > Florian Weimer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > BFK edv-consulting GmbH =A0 =A0 =A0 http://www.bfk.de/ > Kriegsstra=DFe 100 =A0 =A0 =A0 =A0 =A0 =A0 =A0tel: +49-721-96201-1 > D-76133 Karlsruhe =A0 =A0 =A0 =A0 =A0 =A0 fax: +49-721-96201-99 > --=20 Website: http://hallambaker.com/ From paul.hoffman@vpnc.org Fri Jan 7 07:38:47 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 964183A690A for ; Fri, 7 Jan 2011 07:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.678 X-Spam-Level: X-Spam-Status: No, score=-101.678 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnkzqHK+yAfY for ; Fri, 7 Jan 2011 07:38:47 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id EB4DD3A6907 for ; Fri, 7 Jan 2011 07:38:46 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p07Feqd3032652 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 7 Jan 2011 08:40:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D273404.40700@vpnc.org> Date: Fri, 07 Jan 2011 07:40:52 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 15:38:47 -0000 On 1/7/11 6:32 AM, Phillip Hallam-Baker wrote: > Rather than using the term 'strength' I suggest we use the term 'work factor'. I suggest we do neither. This is not the correct WG to be discussing this. The proposal at hand adds two signature algorithms and one hash algorithm. This current thread started when one of the WG co-chairs innocently asked about adding another hash algorithm or replacing the one proposed with a new one. I responded with my reasoning (based on "strength" and/or "work factor"), but that wording *is not* expected to end up in the WG document. It is sufficient for us to define the use of strong algorithms and let operators use whatever input they want to choose which to use. --Paul Hoffman, Director --VPN Consortium From hallam@gmail.com Fri Jan 7 07:44:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC863A6903 for ; Fri, 7 Jan 2011 07:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.662 X-Spam-Level: X-Spam-Status: No, score=-3.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8e21tQ9UjGp for ; Fri, 7 Jan 2011 07:44:36 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 88BFD3A6905 for ; Fri, 7 Jan 2011 07:44:36 -0800 (PST) Received: by gwj17 with SMTP id 17so9369644gwj.31 for ; Fri, 07 Jan 2011 07:46:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kV+7q7oXG1PdfKBmNAasIfB0kdx3J3iuROl2WyIe+l4=; b=u4T/8obaaIF+eATgql8MDGQgPD7dAT4YIoZaJRl/5VVtDoIn3V9pQsg4sgw4rIqQ7s ye7xFJ9gj+avYqKARhJGNneXUz7J6V8r7XVOYMYl8TdIcRfQ8ampQCnXrKg6lXAmn961 cfdgvtZarTSG5zSIDlxG1U3VuYFDV7aPEe31g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YwzHzYeCOisEF4y1SF1DlALUv50PU/Q9Xb0o9ecy2G+aLJi9UvWnMukejBGdyjOO60 Nd0JHjkvgSq0IqS1oQkKzjQIMRxbNPflYaCmaKvlRjYE9sTv6xl7cvXhtfXcvLdFs/qL odI520W8Qg8aW7hyT+H4f30s07OB462PX6swY= MIME-Version: 1.0 Received: by 10.100.255.4 with SMTP id c4mr247814ani.205.1294415203086; Fri, 07 Jan 2011 07:46:43 -0800 (PST) Received: by 10.100.31.8 with HTTP; Fri, 7 Jan 2011 07:46:42 -0800 (PST) In-Reply-To: <359091FCD895EA0C271718D9@Ximines.local> References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <359091FCD895EA0C271718D9@Ximines.local> Date: Fri, 7 Jan 2011 10:46:42 -0500 Message-ID: From: Phillip Hallam-Baker To: Alex Bligh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Edward Lewis , Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 15:44:38 -0000 There are two issues here: 1) Different OIDs assigned to the same algorithm with the same parameters. 2) Algorithms that take parameters that lead to different OID assignments. In the first case we did at one point have an ambiguity where an IETF WG got the idea that it should ignore the existing OID assignments and assign OIDs in the IETF arc. It is now understood that that was a mistake and should not be repeated. If we moved to the scheme I propose it would make sense for the IETF to maintain a registry of mandated algorithms and the ASN.1 OIDs mandated for use in those protocols that use them. But part of the point of getting the IETF out of the business of registering code points for non-mandatory crypto would be to discourage use. In the second case we have frequently ended up with different OIDs for incompatible variations of the same algorithm. But this is exactly what we want. For example, we have had at least three different packaging formats for RSA signatures over the years. The packaging formats are incompatible and a verifier can only verify a signature if it supports the precise packaging format used to create the signature. So even though the public key algorithm is the same, the implementation is different and we need to use a different identifier if we are going to have interoperability. ECC is a little bit of a unique case since there are parameters and options and much more complexity than we have had to cope with in the past. But even so, I don't see a lot of value in having different protocols choose different sets of options. At the end of the day consistency is going to be far more useful than any benefit we might gain from those options. On Fri, Jan 7, 2011 at 10:26 AM, Alex Bligh wrote: > > > --On 7 January 2011 09:32:56 -0500 Phillip Hallam-Baker > wrote: > >> All non-mandatory crypto would use ASN.1 OIDs to declare the algorithm >> type. In the case of DNSSEC this would require an approach similar to >> the one that the OID based CERT type uses. There would be a code point >> reserved for identifying the algorithm by ASN.1 oid and a defined >> mechanism for squeezing in the OID as a prefix to the crypto material. > > ... >> >> The only interoperability concern should be that applications that >> support a common algorithm be able to use it to communicate. That >> means that they all use the same code points to identify the same >> algorithm. > > ... >> >> The fact that the OID registry is open and has no gating factor is a >> good thing. No gate means no endorsement. If we had used ASN.1 OIDs to >> identify algorithms there would be no RFC 5933, there would be no >> mention of GOST in RFCs at all unless there was a decision to adopt it >> as a mandatory to implement algorithm (which the GRU would not want in >> any case since their whole purpose requires use of a different >> algorithm). > > > Q: is there sufficient standardisation within the ASN.1 OIDs that if a ne= w > crypto type FOO comes along, then 2 implementations, working solely from > the OID, they can necessarily interoperate? IE will they thoroughly speci= fy > whether FOO options X and Y have to be supported, wire format, etc? To > illustrate what I mean, I include below a section from the OpenSSH-5.7 > testing release notes. I know ssh !=3D DNSSEC, but I suspect support for = a > new algorithm might not be as simply described as whether a single ID. > > -- > Alex Bligh > > > > > * Implement Elliptic Curve Cryptography modes for key exchange (ECDH) > =A0and host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA > =A0offer better performance than plain DH and DSA at the same equivalent > =A0symmetric key length, as well as much shorter keys. > > =A0Only the mandatory sections of RFC5656 are implemented, specifically > =A0the three REQUIRED curves nistp256, nistp384 and nistp521 and only > =A0ECDH and ECDSA. Point compression (optional in RFC5656) is NOT > =A0implemented. > > =A0Certificate host and user keys using the new ECDSA key types are > =A0supported - an ECDSA key may be certified, and an ECDSA key may act > =A0as a CA to sign certificates. > > =A0ECDH in a 256 bit curve field is the preferred key agreement > =A0algorithm when both the client and server support it. ECDSA host > =A0keys are preferred when learning a host's keys for the first time. > > --=20 Website: http://hallambaker.com/ From colm@allcosts.net Fri Jan 7 07:56:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B98A3A6912 for ; Fri, 7 Jan 2011 07:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356, SARE_SUB_8CONS_WORD=0.36] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOVoXYacoTNV for ; Fri, 7 Jan 2011 07:56:35 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 76DD53A6905 for ; Fri, 7 Jan 2011 07:56:35 -0800 (PST) Received: by qyj19 with SMTP id 19so18990769qyj.10 for ; Fri, 07 Jan 2011 07:58:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.95.11 with SMTP id b11mr22484246qcn.28.1294415921363; Fri, 07 Jan 2011 07:58:41 -0800 (PST) Received: by 10.229.222.196 with HTTP; Fri, 7 Jan 2011 07:58:40 -0800 (PST) In-Reply-To: <82r5coestv.fsf@mid.bfk.de> References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <4D24ADA3.20305@vpnc.org> <82r5coestv.fsf@mid.bfk.de> Date: Fri, 7 Jan 2011 07:58:40 -0800 Message-ID: From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Florian Weimer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Edward Lewis , Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] strngths, was Re: Adopting draft:... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 15:56:36 -0000 On Fri, Jan 7, 2011 at 5:39 AM, Florian Weimer wrote: > * Edward Lewis: > >> If I sign a single A record, how can a forgery be concocted to replace >> the set? =A0I don't mean 1 for 1 necessarily, maybe it would take 10 or >> so. =A0Is MD5 really broken within the confines of DNS? > > As far as I can tell, MD5 is only broken for hashing sufficiently > predictable messages supplied by non-trusted parties, and only for > certain message configurations. I think thinking about "degrees of broken" is dangerous. MD5 is broken, and it shouldn't be considered fit for purpose where security matters. It may have some use as a cheap integrity check, and in hash-tables, but not authenticity. But even IF we take the "supplied by third parties" issue. Imagine that I'm an evil Certificate Authority, I might give you a certificate that I know I can produce hash collisions for. (via a prefix attack). I could then successfully spoof DNS responses for a CERT rrset, by using your RRSIG, but my evil certificate. That's the really easy way. It turns out you don't even have to be the issuer though - it's relatively easy to just create a lot of certificates until you get one that matches. This is how the RapidSSL cert was successfully forged. http://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities --=20 Colm From jinmei@isc.org Fri Jan 7 15:14:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76313A69CF for ; Fri, 7 Jan 2011 15:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMWJA6iH5WCd for ; Fri, 7 Jan 2011 15:14:01 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 44F923A69BC for ; Fri, 7 Jan 2011 15:12:54 -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 0DCD65F985D; Fri, 7 Jan 2011 23:14:51 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:64:c62c:3ff:fe1f:6c75]) (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 8571D216C3F; Fri, 7 Jan 2011 23:14:49 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Fri, 07 Jan 2011 15:14:49 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: scottr.nist@gmail.com, wouter@nlnetlabs.nl User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: dnsext@ietf.org Subject: [dnsext] additional section processing for DNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 23:14:01 -0000 Hello, I have one quick question about draft-ietf-dnsext-rfc2672bis-dname-21. In its Section 3, the draft states: The DNAME RR causes type NS additional section processing. This refers to action at step 6 of the server algorithm outlined in section 3.2. And the "step 6" of section 3.2 is as follows: 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. It's not clear to me what these mean...what's "type NS additional section processing" (for DNAME RR) in the first place? Does this mean, for example, if an authoritative server of "example.com" has the following DNAME RR: dname.example.com. DNAME dname.example.org. and it also happens to have authoritative AAAA or A RRset of dname.example.org, then the server includes these AAAA/A RRsets in the additional section? This doesn't seem to make much sense to me, so I guess "type NS additional section processing" should mean something else, but I don't know what it is. Could you clarify what it is, and what it is for? Thanks, (p.s. I spent some time of googling to find the answer myself, and I noticed this change was introduced in rev 15 of this document around when there was a WG last call. So I suspect this is a response to a last call comment, but I couldn't find the relevant discussion. Hence this question, at the risk of asking something twice at the same place) --- JINMEI, Tatuya Internet Systems Consortium, Inc. From wouter@nlnetlabs.nl Sat Jan 8 01:55:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48FF3A69C4 for ; Sat, 8 Jan 2011 01:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52+eoToHeA9G for ; Sat, 8 Jan 2011 01:55:12 -0800 (PST) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by core3.amsl.com (Postfix) with ESMTP id EDC333A69C3 for ; Sat, 8 Jan 2011 01:55:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 815F358653; Sat, 8 Jan 2011 10:57:15 +0100 (CET) Received: from [192.168.254.2] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id CA37A585AD; Sat, 8 Jan 2011 10:57:08 +0100 (CET) Message-ID: <4D2834EC.20902@nlnetlabs.nl> Date: Sat, 08 Jan 2011 10:57:00 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11 MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at rotring X-Virus-Status: Clean Cc: scottr.nist@gmail.com, dnsext@ietf.org Subject: Re: [dnsext] additional section processing for DNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Jan 2011 09:55:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jinmei, On 01/08/2011 12:14 AM, JINMEI Tatuya / 神明é”哉 wrote: > It's not clear to me what these mean...what's "type NS additional > section processing" (for DNAME RR) in the first place? Does this > mean, for example, if an authoritative server of "example.com" has the > following DNAME RR: It is the same that is done for a query for type A. The step 6 is from 1034, http://tools.ietf.org/rfcmarkup?doc=1034#page-25 . This is not special to the DNAME type. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk0oNOwACgkQkDLqNwOhpPgOCACeMaruVRrBokkwp+n5+85YUbQC AUIAniqk1r6u9CyyKJ9NJBDMOx0YaJMb =nirD -----END PGP SIGNATURE----- From jinmei@isc.org Sat Jan 8 13:09:59 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01973A6836 for ; Sat, 8 Jan 2011 13:09:59 -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=[AWL=-0.001, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQXynfAyH8Mo for ; Sat, 8 Jan 2011 13:09:12 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 44A873A683A for ; Sat, 8 Jan 2011 13:09:09 -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 08CA1C941E; Sat, 8 Jan 2011 21:11:07 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (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 B7EAE216C3B; Sat, 8 Jan 2011 21:11:06 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Sat, 08 Jan 2011 13:11:06 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "W.C.A. Wijngaards" In-Reply-To: <4D2834EC.20902@nlnetlabs.nl> References: <4D2834EC.20902@nlnetlabs.nl> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: scottr.nist@gmail.com, dnsext@ietf.org Subject: Re: [dnsext] additional section processing for DNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Jan 2011 21:09:59 -0000 At Sat, 08 Jan 2011 10:57:00 +0100, "W.C.A. Wijngaards" wrote: > > It's not clear to me what these mean...what's "type NS additional > > section processing" (for DNAME RR) in the first place? Does this > > mean, for example, if an authoritative server of "example.com" has the > > following DNAME RR: > > It is the same that is done for a query for type A. The step 6 is from > 1034, http://tools.ietf.org/rfcmarkup?doc=1034#page-25 . This is not > special to the DNAME type. Thanks for the response, but it doesn't really clear my confused head. Could you show an example (like the one I used in my original question) of how "type NS additional section processing" could happen with DNAME (even if it's no different from type A query)? Meanwhile, I've got an off-list response to my original question, which says "providing NS/A glue like you would for a delegation." If this means the following scenario, I can see it as a consequence of the server algorithm described in Section 3.2 of rfc2672bis...: - there's an authoritative server for example.com and example.org - in example.com it has a DNAME: dname.example.com. DNAME dname.example.org. - in example.org it has a delegation by NS (and glue): dname.example.org. NS ns.dname.example.org. ns.dname.example.org. A 192.0.2.1 With this setup if we ask this server for www.dname.example.com, the server will include: - the DNAME (and synthesized CNAME) in the answer section - the NS in the authority section - the (glue) A in the additional section (this is, in fact, how BIND 9 and NSD behave in this situation, btw) ...however, if this is what "type NS additional section processing" of Section 3 means, I suspect it's very difficult for ordinary readers to reach the correct understanding (and I think we need more detailed and concrete explanation). Also, if this is what the draft means, referring to "step 6 of the server algorithm" doesn't seem to be correct, as this is actually a result of step 3-B. [besides, as far as I know the vast majority (if not all) of today's deployed recursive/caching servers will ignore such NS/A to prevent cache poisoning anyway, so it's mostly a waste in practice. But that's a different discussion] It's still quite likely that I misunderstand something very fundamental. If so, pointing it out with a concrete example of "type NS additional section processing" with DNAME would be very much appreciated. Thanks, --- JINMEI, Tatuya Internet Systems Consortium, Inc. From Ed.Lewis@neustar.biz Mon Jan 10 11:18:10 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0923A6B0C for ; Mon, 10 Jan 2011 11:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz+E+QSjTsCh for ; Mon, 10 Jan 2011 11:18:09 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id BB1223A6839 for ; Mon, 10 Jan 2011 11:18:08 -0800 (PST) Received: from shar-lt500.cis.neustar.com (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0AJKB6d028262; Mon, 10 Jan 2011 14:20:12 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.129] by shar-lt500.cis.neustar.com (PGP Universal service); Mon, 10 Jan 2011 14:20:20 -0500 X-PGP-Universal: processed; by shar-lt500.cis.neustar.com on Mon, 10 Jan 2011 14:20:20 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 10 Jan 2011 14:20:10 -0500 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-917435283==_ma============" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: scottr.nist@gmail.com, dnsext@ietf.org Subject: Re: [dnsext] additional section processing for DNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jan 2011 19:18:10 -0000 --============_-917435283==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 15:14 -0800 1/7/11, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >Could you clarify what it is, and what it is for? > >Thanks, > >(p.s. I spent some time of googling to find the answer myself, and I >noticed this change was introduced in rev 15 of this document around >when there was a WG last call. So I suspect this is a response to a >last call comment, but I couldn't find the relevant discussion. >Hence this question, at the risk of asking something twice at the same >place) I'm still puzzled by the question, especially the reference to a change "in rev 15". RFC 2672 has "The DNAME RR causes type NS additional section processing." Only the location of that comment has changed in the 22 versions of 2672bis. Is the original question "what's the significance/usefulness of the glue records in a DNAME-involved response?" Does the question apply against the original RFC too, or to something that has been changed in the draft? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Jan 10, 2011 - In regions with mm/dd/yy, it's "Binary Day" - 01/10/11 Happy Binary Day --============_-917435283==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] additional section processing for DNAME
At 15:14 -0800 1/7/11, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:

>Could you clarify what it is, and what it is for?
>
>Thanks,
>
>(p.s. I spent some time of googling to find the answer myself, and I
>noticed this change was introduced in rev 15 of this document around
>when there was a WG last call.  So I suspect this is a response to a
>last call comment, but I couldn't find the relevant discussion.
>Hence this question, at the risk of asking something twice at the same
>place)

I'm still puzzled by the question, especially the reference to a change "in rev 15".  RFC 2672 has "The DNAME RR causes type NS additional section processing."  Only the location of that comment has changed in the 22 versions of 2672bis.

Is the original question "what's the significance/usefulness of the glue records in a DNAME-involved response?"  Does the question apply against the original RFC too, or to something that has been changed in the draft?

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

Jan 10, 2011 - In regions with mm/dd/yy, it's "Binary Day" - 01/10/11
Happy Binary Day
--============_-917435283==_ma============-- From jinmei@isc.org Mon Jan 10 23:14:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB0D3A69B8 for ; Mon, 10 Jan 2011 23:14:56 -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=[AWL=-0.000, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG5SgDL2Vk9y for ; Mon, 10 Jan 2011 23:14:55 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 0B2EB3A6884 for ; Mon, 10 Jan 2011 23:14: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.pao1.isc.org (Postfix) with ESMTPS id 434C1C941E; Tue, 11 Jan 2011 07:17:01 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (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 EE1F1216C3B; Tue, 11 Jan 2011 07:17:00 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Mon, 10 Jan 2011 23:16:32 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Edward Lewis In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: scottr.nist@gmail.com, dnsext@ietf.org Subject: Re: [dnsext] additional section processing for DNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 11 Jan 2011 07:14:56 -0000 At Mon, 10 Jan 2011 14:20:10 -0500, Edward Lewis wrote: > >(p.s. I spent some time of googling to find the answer myself, and I > >noticed this change was introduced in rev 15 of this document around > >when there was a WG last call. So I suspect this is a response to a > >last call comment, but I couldn't find the relevant discussion. > >Hence this question, at the risk of asking something twice at the same > >place) > > I'm still puzzled by the question, especially the reference to a > change "in rev 15". RFC 2672 has "The DNAME RR causes type NS > additional section processing." Only the location of that comment > has changed in the 22 versions of 2672bis. > > Is the original question "what's the significance/usefulness of the > glue records in a DNAME-involved response?" Does the question apply > against the original RFC too, or to something that has been changed > in the draft? Ah, sorry for the confusing question. It applies to the original RFC2672, too. Actually I first had the question when I (re)read Section 3 of RFC2672: The DNAME RR causes type NS additional section processing. So I next checked the latest revision of the bis draft (rfc2672bis-dname-21) and found: The DNAME RR causes type NS additional section processing. This refers to action at step 6 of the server algorithm outlined in section 3.2. Since it was changed from the original RFC, I thought it was a result of an attempt of clarifying the original text, but it was still unclear to me (as I said in my original question message). So I next searched draft archives to identify when exactly the change was introduced. It was revision 15: https://tools.ietf.org/rfcdiff?url1=draft-ietf-dnsext-rfc2672bis-dname-14&difftype=--html&submit=Go!&url2=draft-ietf-dnsext-rfc2672bis-dname-15 But I still failed to understand the sense of the change, and what "type NS additional section processing" means wasn't still clear to me. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From Ed.Lewis@neustar.biz Tue Jan 11 18:53:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91ED73A688F for ; Tue, 11 Jan 2011 18:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.252 X-Spam-Level: X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKZc0VXz6lcG for ; Tue, 11 Jan 2011 18:53:32 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D94BA3A6853 for ; Tue, 11 Jan 2011 18:53:30 -0800 (PST) Received: from sper2-lt500.cis.neustar.com (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0C2te4w041500; Tue, 11 Jan 2011 21:55:40 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.19] by sper2-lt500.cis.neustar.com (PGP Universal service); Tue, 11 Jan 2011 21:55:47 -0500 X-PGP-Universal: processed; by sper2-lt500.cis.neustar.com on Tue, 11 Jan 2011 21:55:47 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 11 Jan 2011 21:55:38 -0500 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: scottr.nist@gmail.com, Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] additional section processing for DNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 02:53:33 -0000 At 23:16 -0800 1/10/11, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >But I still failed to understand the sense of the change, and what >"type NS additional section processing" means wasn't still clear to >me. Ahh, yes. Ok, I understand the question. And I agree it's not entirely clear. ;) (As in, "yes, I certainly understand the problem...") One of the issues in writing these updates (or alleged clarifications) I can mention from my experience in doing them is that the original text is so weak and thus interpreted so differently, someone will be unhappy. The safest thing to do is retain as much of the original text and slap on some supports where we can "get away with it." Perhaps this is a case of that. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Jan 11, 2011 - Either it's 1/11/11 or 11/1/11, "Junior Saint Broadcast day" (Nov 11 is senior...) From jinmei@isc.org Wed Jan 12 00:09:51 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5E9A3A6B07 for ; Wed, 12 Jan 2011 00:09:51 -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=[AWL=-0.000, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG9BWTxdAvU4 for ; Wed, 12 Jan 2011 00:09:51 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id CB1A03A6996 for ; Wed, 12 Jan 2011 00:09:50 -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 B9DF7C9424; Wed, 12 Jan 2011 08:11:58 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (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 7A858216C3F; Wed, 12 Jan 2011 08:11:58 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Wed, 12 Jan 2011 00:11:57 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Edward Lewis In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: scottr.nist@gmail.com, dnsext@ietf.org Subject: Re: [dnsext] additional section processing for DNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 08:09:51 -0000 At Tue, 11 Jan 2011 21:55:38 -0500, Edward Lewis wrote: > >But I still failed to understand the sense of the change, and what > >"type NS additional section processing" means wasn't still clear to > >me. > > Ahh, yes. Ok, I understand the question. And I agree it's not > entirely clear. ;) (As in, "yes, I certainly understand the > problem...") Okay, I'm glad to know it was not only me:-) > One of the issues in writing these updates (or alleged > clarifications) I can mention from my experience in doing them is > that the original text is so weak and thus interpreted so > differently, someone will be unhappy. The safest thing to do is > retain as much of the original text and slap on some supports where > we can "get away with it." Perhaps this is a case of that. Perhaps. Right now I just wonder about the meaning rather than agreeing or disagreeing with anything. Since the original text in question was (seemingly) intentionally updated, I'd at least like to know the intent of the update. Thanks, --- JINMEI, Tatuya Internet Systems Consortium, Inc. From gson@araneus.fi Wed Jan 12 00:29:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BCF03A69ED for ; Wed, 12 Jan 2011 00:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4WyeUbSdXKI for ; Wed, 12 Jan 2011 00:29:24 -0800 (PST) Received: from gusev.araneus.fi (gusev.araneus.fi [83.145.227.89]) by core3.amsl.com (Postfix) with ESMTP id E5BEC3A69E5 for ; Wed, 12 Jan 2011 00:29:23 -0800 (PST) Received: from guava.gson.org (guava.gson.org [83.145.227.105]) by gusev.araneus.fi (Postfix) with ESMTP id 4EB6A91EFC; Wed, 12 Jan 2011 10:31:41 +0200 (EET) Received: by guava.gson.org (Postfix, from userid 101) id BB87A75E40; Wed, 12 Jan 2011 10:31:40 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19757.26347.948711.659315@guava.gson.org> Date: Wed, 12 Jan 2011 10:31:39 +0200 To: JINMEI Tatuya In-Reply-To: References: X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf) From: Andreas Gustafsson Cc: scottr.nist@gmail.com, Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] additional section processing for DNAME X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 08:29:25 -0000 JINMEI Tatuya wrote: > Okay, I'm glad to know it was not only me:-) You may add me to the list of people who find the text confusing. Actually, I would go further than that and say that the text is not just confusing - it's simply wrong. > > One of the issues in writing these updates (or alleged > > clarifications) I can mention from my experience in doing them is > > that the original text is so weak and thus interpreted so > > differently, someone will be unhappy. The safest thing to do is > > retain as much of the original text and slap on some supports where > > we can "get away with it." Perhaps this is a case of that. > > Perhaps. Right now I just wonder about the meaning rather than > agreeing or disagreeing with anything. Since the original text in > question was (seemingly) intentionally updated, I'd at least like to > know the intent of the update. To me the update seems like an attempt to rationalize some text in the original RFC that never made sense in the first place. So, to summarize, I think the following text in the draft makes no sense, serves no useful purpose, and should be deleted: The DNAME RR causes type NS additional section processing. This refers to action at step 6 of the server algorithm outlined in section 3.2. -- Andreas Gustafsson, gson@araneus.fi From scott.rose@nist.gov Wed Jan 12 07:04:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7831628C126 for ; Wed, 12 Jan 2011 07:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.255 X-Spam-Level: X-Spam-Status: No, score=-5.255 tagged_above=-999 required=5 tests=[AWL=1.344, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOJvHHpKiWMU for ; Wed, 12 Jan 2011 07:04:12 -0800 (PST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id EDA8928C123 for ; Wed, 12 Jan 2011 07:04:11 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p0CF6Qxv004485 for ; Wed, 12 Jan 2011 10:06:26 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 12 Jan 2011 10:06:15 -0500 From: "Rose, Scott W." To: "dnsext@ietf.org" Date: Wed, 12 Jan 2011 10:06:20 -0500 Thread-Topic: Additional section processing for DNAME - question for WG Thread-Index: AcuyakHET5u9E41BQpaTgSlL/AH2bA== Message-ID: <606C034D-452F-4180-B21C-40D5BB5D0971@nist.gov> References: <19757.26347.948711.659315@guava.gson.org> In-Reply-To: <19757.26347.948711.659315@guava.gson.org> 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" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Subject: [dnsext] Additional section processing for DNAME - question for WG X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 15:04:13 -0000 Based on the discussion, is there any reason to keep the text below? If the consensus is "no", should it just be dropped completely, or should it be replaced with something stating (rough text): "The DNAME RR does not cause any additional section processing. This is a change from RFC 2762." Because this is another change from the original DNAME spec. Scott. On Jan 12, 2011, at 3:31 AM, Andreas Gustafsson wrote: > > So, to summarize, I think the following text in the draft makes > no sense, serves no useful purpose, and should be deleted: > > The DNAME RR causes type NS additional section processing. This > refers to action at step 6 of the server algorithm outlined in > section 3.2. > > -- > Andreas Gustafsson, gson@araneus.fi > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext =================================== Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== From Internet-Drafts@ietf.org Wed Jan 12 07:45:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56F33A6B35; Wed, 12 Jan 2011 07:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvkjvxW+ykF5; Wed, 12 Jan 2011 07:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060763A6B34; Wed, 12 Jan 2011 07:45:02 -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.10 Message-ID: <20110112154502.11352.39916.idtracker@localhost> Date: Wed, 12 Jan 2011 07:45:02 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-ecdsa-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 15:45:03 -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 : Elliptic Curve DSA for DNSSEC Author(s) : P. Hoffman, W. Wijngaards Filename : draft-ietf-dnsext-ecdsa-00.txt Pages : 8 Date : 2011-01-12 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-00.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-ecdsa-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-12073640.I-D@ietf.org> --NextPart-- From jinmei@isc.org Wed Jan 12 11:18:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6BC3A6A7E for ; Wed, 12 Jan 2011 11:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8rg96pnGsJj for ; Wed, 12 Jan 2011 11:18:02 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 4AFD63A6A75 for ; Wed, 12 Jan 2011 11:18:02 -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 910545F984C; Wed, 12 Jan 2011 19:20:07 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:65:daa2:5eff:fe93:e92c]) (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 76BB9216C3F; Wed, 12 Jan 2011 19:20:05 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Wed, 12 Jan 2011 11:20:05 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Rose, Scott W." In-Reply-To: <606C034D-452F-4180-B21C-40D5BB5D0971@nist.gov> References: <19757.26347.948711.659315@guava.gson.org> <606C034D-452F-4180-B21C-40D5BB5D0971@nist.gov> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Additional section processing for DNAME - question for WG X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 19:18:03 -0000 At Wed, 12 Jan 2011 10:06:20 -0500, "Rose, Scott W." wrote: > If the consensus is "no", should it just be dropped completely, or should it be replaced with something stating (rough text): > > "The DNAME RR does not cause any additional section processing. This is a change from RFC 2762." > > Because this is another change from the original DNAME spec. I don't have a strong opinion, but if there'll be a "changes from RFC2762" section in the final bis RFC, I'd simply remove the text from the body and note the fact in that section. BTW, not a strong opinion again, but I agree with dropping the statement about additional section processing in some way because the text didn't make sense to me and I cannot think of any existing deployment that relies on it (although, as with any compatibility related topic, I understand such a view could often be too optimistic). --- JINMEI, Tatuya Internet Systems Consortium, Inc. From krishnabirth@gmail.com Fri Jan 14 13:47:10 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F59E3A6C96 for ; Fri, 14 Jan 2011 13:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqMxcxtGa1VQ for ; Fri, 14 Jan 2011 13:47:09 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id D625C3A6C9A for ; Fri, 14 Jan 2011 13:47:08 -0800 (PST) Received: by wwa36 with SMTP id 36so3240532wwa.13 for ; Fri, 14 Jan 2011 13:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=OzYJzy3IHafKRp59GEiA3/9p2stnBmAminGNCkcajnM=; b=MhwBKIADV6/+yy/7lrls5Y4rsPHTEPdYGtsPAiz9H3heBebsMAMtEYQepIjCmDGg/Y zkbEcCHD00vhqA1gK/q0LzipsFH6X51iJ5vf49JLPM9rbPulHb3g00QlCHgAsUVTnq2H eSnh+5Qdx19YNOPTAP0LhyYgY+0IyRPwVWkSk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=K2edYhar0/A+4GlsGazO0BTcPUEyG8z9ShdPGfW2H7KS7JbBGX+P2z1p0mUbKYVIFd maJ7zgYMsP++Rfdgvc8cfeSW6XQ4aUeronhTcetzZU3xbd/Q6atvp7ENp1K7llgFkA36 EqLvJpZ+z+Nu3w0k61fbCSt3lDTKDlhQg7KJ0= MIME-Version: 1.0 Received: by 10.216.162.70 with SMTP id x48mr25621wek.4.1295041690108; Fri, 14 Jan 2011 13:48:10 -0800 (PST) Received: by 10.216.153.136 with HTTP; Fri, 14 Jan 2011 13:48:10 -0800 (PST) Date: Fri, 14 Jan 2011 21:48:10 +0000 Message-ID: From: Krishna Birth To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=001485f44f32e883780499d563b2 Subject: [dnsext] Increasing character limit for registration in internet domain names: 76 or 68 or 91 or 83 or 64 higher the better X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 21:47:10 -0000 --001485f44f32e883780499d563b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable After I had posted yesterday the following on the ietf@ietf.org mailing list, I was requested in an email to myself to put it also to this specific mailing list for discussion: (please view this email with UTF-8 enabled on your viewer) This is a request for internet engineers to increase the character limit fo= r registration in the various internet domain names (com, net, org, info etc) from 63 characters to more at least 76 or 68 or 91 or 83 or 64, the higher it is the better. I believe the raising the characters on the internet domain names will [be] very good from a spiritual perspective. I base thes= e figures on the spiritual prayer and chant: harekrishnaharekrishnakrishnakrishnahareharehareramahareramaramaramaharehar= e =3D 76 characters harekrsnaharekrsnakrsnakrsnahareharehareramahareramaramaramaharehare =3D 68 characters hare-krishna-hare-krishna-krishna-krishna-hare-hare-hare-rama-hare-rama-ram= a-rama-hare-hare =3D 91 characters hare-krsna-hare-krsna-krsna-krsna-hare-hare-hare-rama-hare-rama-rama-rama-h= are-hare =3D 83 characters harekrsnaharekrsnakrsnakrsnahareharehareramhareramramramharehare =3D 64 characters It would allow the Hare =E0=A4=95rishna Mahamantra, the great prayer for de= liverance in this Age to be fully put on an internet domain name. The chanting and recitation of the Mahamantra cleanses the heart of the impurities and pollution. Caitanya Mahaprabhu and incarnation of =E0=A4=95rishna, the Sup= reme Personality of Godhead Movement, popularised the chanting of the Mahamantra some 500 years ago and is meant for every town and village in the world. Now His Divine Grace A C Bha=E0=A4=95tivedanta Swami Prabhupada, Founder, = Eternal Di=E0=A4=95sa and Si=E0=A4=95sa Spiritual Master of the Hare =E0=A4=95rishn= a Movement in the chain of disciplic succession has popularised it in the West and continues to popularise. p.s. Some time ago I posted on the IETF mailing list via another email account. Best, Mee=E0=A4=95u --001485f44f32e883780499d563b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable After I had posted yesterday the following on the ietf@ietf.org mailing list, I was req= uested in an email to myself to put it also to this specific mailing list f= or discussion:=C2=A0=C2=A0


(please view this email with UTF-8 enabled on your viewer)

T= his is a request for internet engineers to increase the character limit for= registration in the various internet domain names (com, net, org, info etc= ) from 63 characters to more at least 76 or 68 or 91 or 83 or 64, the highe= r it is the better.=C2=A0 I believe the raising the characters on the inter= net domain names will [be] very good from a spiritual perspective.=C2=A0 I = base these figures on the spiritual prayer and chant:

harekrishnaharekrishnakrishnakrishnahareharehareramahareramaramaramahar= ehare =3D 76 characters

harekrsnaharekrsnakrsnakrsnaharehareharerama= hareramaramaramaharehare =3D 68 characters

hare-krishna-hare-krishna= -krishna-krishna-hare-hare-hare-rama-hare-rama-rama-rama-hare-hare =3D 91 c= haracters

hare-krsna-hare-krsna-krsna-krsna-hare-hare-hare-rama-hare-rama-rama-ra= ma-hare-hare =3D 83 characters

harekrsnaharekrsnakrsnakrsnaharehareh= areramhareramramramharehare =3D 64 characters


It would allow the= Hare =E0=A4=95rishna Mahamantra, the great prayer for deliverance in this = Age to be fully put on an internet domain name.=C2=A0 The chanting and reci= tation of the Mahamantra cleanses the heart of the impurities and pollution= .=C2=A0 Caitanya Mahaprabhu and incarnation of =E0=A4=95rishna, the Supreme= Personality of Godhead Movement, popularised the chanting of the Mahamantr= a some 500 years ago and is meant for every town and village in the world. =

Now His Divine Grace A C Bha=E0=A4=95tivedanta Swami=C2=A0 Prabhupada, = Founder, Eternal Di=E0=A4=95sa and Si=E0=A4=95sa Spiritual Master of the Ha= re =E0=A4=95rishna Movement in the chain of disciplic succession has popula= rised it in the West and continues to popularise.


p.s. Some time ago I posted on the IETF mailing list via another em= ail account.


Best,


Mee=E0=A4=95u
--001485f44f32e883780499d563b2-- From matthew@dempsky.org Fri Jan 14 16:15:53 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDDFB3A6CBC for ; Fri, 14 Jan 2011 16:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjNlyt2sxJ+k for ; Fri, 14 Jan 2011 16:15:52 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CFD263A6CB5 for ; Fri, 14 Jan 2011 16:15:52 -0800 (PST) Received: by iwn40 with SMTP id 40so3225818iwn.31 for ; Fri, 14 Jan 2011 16:18:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.13.201 with SMTP id d9mr1352170iba.124.1295050699412; Fri, 14 Jan 2011 16:18:19 -0800 (PST) Received: by 10.231.161.67 with HTTP; Fri, 14 Jan 2011 16:18:19 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Jan 2011 16:18:19 -0800 Message-ID: From: Matthew Dempsky To: Krishna Birth Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] Increasing character limit for registration in internet domain names: 76 or 68 or 91 or 83 or 64 higher the better X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jan 2011 00:15:53 -0000 On Fri, Jan 14, 2011 at 1:48 PM, Krishna Birth wrote: > After I had posted yesterday the following on the ietf@ietf.org mailing > list, I was requested in an email to myself to put it also to this specific > mailing list for discussion: Try twitter.com instead. They already support messages up to 140 characters. HTH From Internet-Drafts@ietf.org Sun Jan 16 14:00:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F903A6E3D; Sun, 16 Jan 2011 14:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFE+mBkZEXMe; Sun, 16 Jan 2011 14:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B953A67DF; Sun, 16 Jan 2011 14:00:02 -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.10 Message-ID: <20110116220002.22912.91963.idtracker@localhost> Date: Sun, 16 Jan 2011 14:00:02 -0800 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-5395bis-03.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 16 Jan 2011 22:00:04 -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 : Domain Name System (DNS) IANA Considerations Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-5395bis-03.txt Pages : 19 Date : 2011-01-16 This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-5395bis-03.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-5395bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-16135659.I-D@ietf.org> --NextPart-- From jay@nzrs.net.nz Sun Jan 16 17:22:40 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C443A6E64 for ; Sun, 16 Jan 2011 17:22:40 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTgbPwWA2Vgd for ; Sun, 16 Jan 2011 17:22:39 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id D78A33A6BA2 for ; Sun, 16 Jan 2011 17:22:38 -0800 (PST) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 1D74E2CE00E for ; Mon, 17 Jan 2011 14:25:13 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO7YqTsjr4bi for ; Mon, 17 Jan 2011 14:25:12 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id BA5A32CE00D for ; Mon, 17 Jan 2011 14:25:12 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Jay Daley In-Reply-To: Date: Mon, 17 Jan 2011 14:25:08 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <85D3CE2C-D7AE-4A06-8E5E-E24589387057@nzrs.net.nz> References: <2E9C54A5-0E2B-4AF9-960E-CE4CA9C1A7BE@nzrs.net.nz> <1A550BF6-9B35-4DE1-9A83-1CB486B12DA5@nzrs.net.nz> <4D186C11.3070306@nic.at> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1082) Subject: Re: [dnsext] Moving policy data away from DNS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 01:22:40 -0000 (back from vacation) On 28/12/2010, at 12:19 AM, Phillip Hallam-Baker wrote: > The principle objection to putting policy in the DNS seems to be that = doing so represents a slippery slope and that we might end up with = people putting so much information in their DNS that it 'breaks'. I was going a step further than that. I'm of the view that adding RRs to DNS that are protocol specific is = sub-optimal for a host of reasons (though I don't think they will = 'break' the DNS) and instead we should go for additions that have a = higher level of usage. For example: - RRs about the tree such as those that describe the tree or redirect = people around the tree - RRs that can be used by any protocol such as those that point to = policy or provide credentials Another way of putting it is creating a toolkit of RRs (using current = requirements) that other protocol developers can just use off the shelf = without any changes to DNS. What I would call a strategic plan. cheers Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From hallam@gmail.com Sun Jan 16 18:50:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DB273A6D63 for ; Sun, 16 Jan 2011 18:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4OHtvYxSst8 for ; Sun, 16 Jan 2011 18:50:24 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 252283A67C0 for ; Sun, 16 Jan 2011 18:50:24 -0800 (PST) Received: by yxt33 with SMTP id 33so2014269yxt.31 for ; Sun, 16 Jan 2011 18:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7jh+ko6N9Wp1Kl8K1clt5msFhy1noAavOuHD3pM9yiM=; b=KmqH8MqQt+vR0ACQ3qn8zBcyI81L2NydK9sBaKG0hU0TGNkE7x9rMeWdXUbZrYToqO HG4xB4VDLQNHhjLL1UwXBp5tB6xBveinxNDFhQhLC5y9wmZHA06MEKKR+UPPKjO4cy+H HwOFtPCuyWTXi41QJWCmJLRJXCCP7eYv8YIWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wZ8OhbwLwj7rZBxAe/X5AdJKAMb23lWhdZLTVOlmOu1RJ62eJ2hJMBc2wW7BlGqLfC AGP2e7mKeCrNzi2peR95wYMg/6LFNG51iEz00IEbW8Blc934dcn081BVY2MY2GR23UFR YKzqOC5bYa2JGtRI3rbvIkCpiFZJJ8dm/tsdQ= MIME-Version: 1.0 Received: by 10.100.153.17 with SMTP id a17mr2152691ane.239.1295232776817; Sun, 16 Jan 2011 18:52:56 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sun, 16 Jan 2011 18:52:56 -0800 (PST) In-Reply-To: <85D3CE2C-D7AE-4A06-8E5E-E24589387057@nzrs.net.nz> References: <2E9C54A5-0E2B-4AF9-960E-CE4CA9C1A7BE@nzrs.net.nz> <1A550BF6-9B35-4DE1-9A83-1CB486B12DA5@nzrs.net.nz> <4D186C11.3070306@nic.at> <85D3CE2C-D7AE-4A06-8E5E-E24589387057@nzrs.net.nz> Date: Sun, 16 Jan 2011 21:52:56 -0500 Message-ID: From: Phillip Hallam-Baker To: Jay Daley Content-Type: multipart/alternative; boundary=0016e644d5cc904dd6049a01e1d5 Cc: DNSEXT Working Group Subject: Re: [dnsext] Moving policy data away from DNS X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 02:50:25 -0000 --0016e644d5cc904dd6049a01e1d5 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 16, 2011 at 8:25 PM, Jay Daley wrote: > (back from vacation) > > On 28/12/2010, at 12:19 AM, Phillip Hallam-Baker wrote: > > > The principle objection to putting policy in the DNS seems to be that > doing so represents a slippery slope and that we might end up with people > putting so much information in their DNS that it 'breaks'. > > I was going a step further than that. > > I'm of the view that adding RRs to DNS that are protocol specific is > sub-optimal for a host of reasons (though I don't think they will 'break' > the DNS) and instead we should go for additions that have a higher level of > usage. For example: > Given that in the Web Services world we are going to have to deal with thousands of protocols, the DNS should not have protocol specific features. The discovery and policy mechanism should be independent of the protocol that is going to make use of it. Otherwise it would be like having a different way to look up IP addresses for HTTP to FTP. Another way of putting it is creating a toolkit of RRs (using current > requirements) that other protocol developers can just use off the shelf > without any changes to DNS. > > What I would call a strategic plan. > It is what architecture should be. -- Website: http://hallambaker.com/ --0016e644d5cc904dd6049a01e1d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jan 16, 2011 at 8:25 PM, Jay Dal= ey <jay@nzrs.net.nz= > wrote:
(back from vacation)

On 28/12/2010, at 12:19 AM, Phillip Hallam-Baker wrote:

> The principle objection to putting policy in the DNS seems to be that = doing so represents a slippery slope and that we might end up with people p= utting so much information in their DNS that it 'breaks'.

I was going a step further than that.

I'm of the view that adding RRs to DNS that are protocol specific is su= b-optimal for a host of reasons (though I don't think they will 'br= eak' the DNS) and instead we should go for additions that have a higher= level of usage. =A0For example:

Given that in the Web Services world we ar= e going to have to deal with thousands of protocols, the DNS should not hav= e protocol specific features.

The discovery and po= licy mechanism should be independent of the protocol that is going to make = use of it. Otherwise it would be like having a different way to look up IP = addresses for HTTP to FTP.

Another way of putting it is= creating a toolkit of RRs (using current requirements) that other protocol= developers can just use off the shelf without any changes to DNS.

What I would call a strategic plan.

It = is what architecture should be.
=A0
--
Website: http://hallambaker.com/

--0016e644d5cc904dd6049a01e1d5-- From fweimer@bfk.de Tue Jan 18 02:41:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBD803A6FDA for ; Tue, 18 Jan 2011 02:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxxrkuEGo1Y0 for ; Tue, 18 Jan 2011 02:41:32 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id B329B3A6FE2 for ; Tue, 18 Jan 2011 02:41:31 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Pf92k-0006zW-HV; Tue, 18 Jan 2011 10:44:06 +0000 Received: by bfk.de with local id 1Pf92k-0005Fn-9P; Tue, 18 Jan 2011 10:44:06 +0000 To: Krishna Birth References: From: Florian Weimer Date: Tue, 18 Jan 2011 10:44:06 +0000 In-Reply-To: (Krishna Birth's message of "Fri\, 14 Jan 2011 21\:48\:10 +0000") Message-ID: <82ei8afq4p.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Increasing character limit for registration in internet domain names: 76 or 68 or 91 or 83 or 64 higher the better X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 10:41:34 -0000 * Krishna Birth: > This is a request for internet engineers to increase the character limit = for > registration in the various internet domain names (com, net, org, info et= c) > from 63 characters to more at least 76 or 68 or 91 or 83 or 64, the higher > it is the better. I believe the raising the characters on the internet > domain names will [be] very good from a spiritual perspective. I base th= ese > figures on the spiritual prayer and chant: Something similar has already been tried: extended label types, as described in RFCs 2671 and 2673. I wasn't really around when the failure of this experiment was recognized. Is there a write-up somewhere explaining why this doesn't work as expected? (Without major protocol surgery, increasing the label length would share a similar fate.) --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From rdroms.ietf@gmail.com Mon Jan 17 20:43:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51E6628C107; Mon, 17 Jan 2011 20:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.27 X-Spam-Level: X-Spam-Status: No, score=-103.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNQV6B5vvESB; Mon, 17 Jan 2011 20:43:55 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 547D628C10E; Mon, 17 Jan 2011 20:43:55 -0800 (PST) Received: by pzk5 with SMTP id 5so1144329pzk.31 for ; Mon, 17 Jan 2011 20:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:references:to:message-id:mime-version:x-mailer; bh=jHR+tdMMMwIv6EKaIiKk1BeJQj7GCSmgAQFrD4jiaro=; b=Hbqg07uiDLkmLV+NheE8GTPRSNlBS+EFbjIO0SaZhV+ZBksXN4EgJVSoOh/IKe0eAy Xv+wLD5ZEo4nhDIvoNR8EX6qm0jFmxti7mtaWymrtCPwNBoUk3NRgFKZLFLktRZUw3VD uPHd5JG90mAxOhpzQMNKW5/fUjfREUzeFpSMY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; b=jo9+xOusvMSPtlHi56zSDHg/B7Qn8YhT2WDyjdLyWTrMCR3gsxRaKd7ZoBSJ6Me/tZ NZ0m5kHjis3oLb+Diy5bBgkRURtggWCwoBskCbTLbj8ZvN0ov1GMoBvFoZGYJfBWQc1c 9cUpOshuv8lZoe1BSmDlNYvNAZn1vz5b9ncgA= Received: by 10.143.7.17 with SMTP id k17mr1669837wfi.200.1295325990759; Mon, 17 Jan 2011 20:46:30 -0800 (PST) Received: from [10.21.108.112] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id o1sm7517214wfl.2.2011.01.17.20.46.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Jan 2011 20:46:29 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 20:46:28 -0800 References: <20110117230048.26192.84056.idtracker@localhost> To: IETF Directorate DNS , dnsext@ietf.org, dnsop@ietf.org Message-Id: <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Tue, 18 Jan 2011 04:51:41 -0800 Subject: [dnsext] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 04:43:56 -0000 FYI; review and comment requested... - Ralph Begin forwarded message: From: The IESG Date: January 17, 2011 3:00:48 PM PST To: IETF-Announce Subject: Last Call: = (Special-Use Domain Names) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Special-Use Domain Names' as a Proposed Standard Abstract This document describes what it means to say that a DNS name is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-14. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-cheshire-dnsext-special-names/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-cheshire-dnsext-special-names/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From vixie@vix.com Tue Jan 18 06:28:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D0928C119 for ; Tue, 18 Jan 2011 06:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05rgP2sK2Fkq for ; Tue, 18 Jan 2011 06:28:21 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 5D54728C10C for ; Tue, 18 Jan 2011 06:28:21 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 047F4A1054 for ; Tue, 18 Jan 2011 14:30:56 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Tue, 18 Jan 2011 10:44:06 GMT." <82ei8afq4p.fsf@mid.bfk.de> References: <82ei8afq4p.fsf@mid.bfk.de> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Tue, 18 Jan 2011 14:30:55 +0000 Message-ID: <85987.1295361055@nsa.vix.com> Sender: vixie@vix.com Subject: Re: [dnsext] Increasing character limit for registration in internet domain names: 76 or 68 or 91 or 83 or 64 higher the better X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 14:28:22 -0000 > From: Florian Weimer > Date: Tue, 18 Jan 2011 10:44:06 +0000 > > I wasn't really around when the failure of this experiment was > recognized. Is there a write-up somewhere explaining why this doesn't > work as expected? (Without major protocol surgery, increasing the > label length would share a similar fate.) no writeup. briefly, it only works if the full end-to-end path knows about each new label type. so adding each label type would require incrementing the EDNS version number. this was found to be impractical. From fweimer@bfk.de Tue Jan 18 06:53:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE3FD28C141 for ; Tue, 18 Jan 2011 06:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSR5Jf-pBiiW for ; Tue, 18 Jan 2011 06:53:00 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id A199528C13A for ; Tue, 18 Jan 2011 06:52:59 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PfCy7-0000Xl-JN for dnsext@ietf.org; Tue, 18 Jan 2011 14:55:35 +0000 Received: by bfk.de with local id 1PfCy7-00012k-Ag for dnsext@ietf.org; Tue, 18 Jan 2011 14:55:35 +0000 To: dnsext@ietf.org References: <82ei8afq4p.fsf@mid.bfk.de> <85987.1295361055@nsa.vix.com> From: Florian Weimer Date: Tue, 18 Jan 2011 14:55:35 +0000 In-Reply-To: <85987.1295361055@nsa.vix.com> (Paul Vixie's message of "Tue\, 18 Jan 2011 14\:30\:55 +0000") Message-ID: <82y66iclco.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] Increasing character limit for registration in internet domain names: 76 or 68 or 91 or 83 or 64 higher the better X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 14:53:01 -0000 * Paul Vixie: >> From: Florian Weimer >> Date: Tue, 18 Jan 2011 10:44:06 +0000 >>=20 >> I wasn't really around when the failure of this experiment was >> recognized. Is there a write-up somewhere explaining why this doesn't >> work as expected? (Without major protocol surgery, increasing the >> label length would share a similar fate.) > > no writeup. briefly, it only works if the full end-to-end path knows > about each new label type. so adding each label type would require=20 > incrementing the EDNS version number. this was found to be impractical. And "full path" has two meanings here, both the forwarders to the authoritative server, and the delegation path from the root to the authoritative servers. If no server is known for a particular subtree, the full QNAME is sent to the roots, then to the applicable TLD servers etc., so all your parents need to support such an extension before you can use it in your zone. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From jabley@hopcount.ca Tue Jan 18 07:06:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35B228C126; Tue, 18 Jan 2011 07:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnJXGrfLwHby; Tue, 18 Jan 2011 07:06:18 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 72B8728C0D9; Tue, 18 Jan 2011 07:06:18 -0800 (PST) Received: from [199.212.90.28] (helo=dh28.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PfDF6-000F8B-8Y; Tue, 18 Jan 2011 15:13:12 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/mixed; boundary=Apple-Mail-15--771451371 From: Joe Abley In-Reply-To: <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> Date: Tue, 18 Jan 2011 10:08:48 -0500 Message-Id: <769A53CB-E219-48DB-822A-492555F583A7@hopcount.ca> References: <20110117230048.26192.84056.idtracker@localhost> <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.28 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsop@ietf.org, IETF Directorate DNS , dnsext@ietf.org Subject: Re: [dnsext] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:06:20 -0000 --Apple-Mail-15--771451371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2011-01-17, at 23:46, Ralph Droms wrote: > FYI; review and comment requested... Comments below, in-line. > Special-Use Domain Names > draft-cheshire-dnsext-special-names-01 >=20 > Abstract >=20 > This document describes what it means to say that a DNS name is > reserved for special use, when reserving such a name is = appropriate, > and the procedure for doing so. The acronym DNS should perhaps be expanded upon first use. > 1. Introduction >=20 > Certain individual IP addresses and IP address ranges are treated > specially by network implementations, and consequently are not > suitable for use as unicast addresses. For example, IPv4 addresses > 224.0.0.0 to 239.255.255.255 are multicast addresses [RFC2606], = with > 224.0.0.1 being the "all hosts" multicast address [RFC1112] > [RFC5771]. Another example is 127.0.0.1, the IPv4 "local host" > address [RFC5735]. >=20 > Analogous to Special-Use IPv4 Addresses [RFC5735], DNS has its own > concept of reserved names, such as "example.com", "example.net", = and > "example.org", or any name falling under the top level = pseudo-domain > "invalid" [RFC2606]. However, "Reserved Top Level DNS Names" > [RFC2606] does not state whether implementations are expected to > treat such names differently, and if so, in what way. DNS could be expanded again, upon first use outside the abstract, and a = reference to 1034/1035 wouldn't hurt. I don't think special-use names are a concept of the DNS in the protocol = sense, but rather a set of administrative conventions. I think it's = fairly clear that 2606 does not specify a protocol restriction (and, = consequently, does not specify special handling in implementations); it = doesn't update 1034/1035, and the rationale given in section 2 suggests = normal handling in DNS software (it wouldn't be much of a test if your = test cases were all handled differently from production, non-reserved = names). The idea of creating an IANA registry of special-use names for ease of = reference by other documents seems worthwhile, however. > 2. Applicability >=20 > When IP multicast was created [RFC1112], implementations had to be > updated to understand what a multicast address means and what to do > with it. Adding IP multicast to a networking stack entailed more = than > merely adding the right routing table entries for those addresses. > Moreover, supporting IP multicast entails some level of commonality > that is consistent across all conformant hosts, independent of what > networks those hosts may be connected to. While it is possible to > build a private isolated network using whatever valid unicast IP > addresses and routing topology you choose (regardless of whether > those unicast IP addresses are already in use by other hosts on the > public Internet) the IPv4 multicast address 224.0.0.1 is always the > "all hosts" multicast address and that's not a local decision. The examples above are all those in which special implementation = decisions are required for handling special-use addresses. That covers = part of the story, but... > Similarly, if a domain name has special properties that affect the > way hardware and software implementations handle the name, which > apply universally regardless of what network the implementation may > be connected to, then that may be a candidate for having the IETF > declare the name to be a Special-Use Domain Name and specify what > special treatment implementations should give to that name. If > declaring a given name to be special would result in no change to = any > implementations, then that suggests that the name may not be = special > in any material way, and it may be more appropriate to use the > existing DNS mechanisms [RFC1034] to provide the desired = delegation, > data, or lack-of-data for the name in question. Where the desired > behaviour can be achieved via the existing domain name registration > processes, that process should be used. Reservation of a = Special-Use > Domain Names is not a mechanism for circumventing normal domain = name > registration processes. ... I disagree with the characterisation that follows. Just because = there is no intended special handling required for INVALID as a TLD = doesn't make INVALID less special in the operational sense; implications = remain for root zone management (i.e. the label INVALID should not = appear) that can't be signalled using resource records. EXAMPLE.COM and = friends are delegated, and require no special handling in DNS software, = but those names remain special in the sense that they have specific = application in documentation. > 3. Procedure >=20 > If it is determined that special handling of a name is required in > order to implement some desired new functionality, then an IETF > "Standards Action" RFC [RFC5226] needs to be published describing = the > new functionality, and: If the criteria for expansion of the IANA registry is a standards = action, then that detail belongs in the IANA Considerations section. See = below for more on that. > o The RFC needs to state how implementations determine that the > special handling is required for any given name. This is = typically > done by stating that any fully-qualified domain names ending in = a > certain suffix (i.e. falling within a specified parent pseudo- > domain) will receive the special behaviour. In effect this = carves > off a sub-tree of the DNS namespace in which the modified name > treatment rules apply, analogous to how IP multicast [RFC1112] = or > IP link-local addresses [RFC3927] [RFC4862] carve off chunks of > the IP address space in which their respective modified address > treatment rules apply. I think the description above is largely implicit in the word "domain", = which means a sub-tree of the namespace anchored at a particular domain = name. > o The RFC needs to state, in each of the seven categories below, > what special treatment, if any, is to be applied. If the answer = in > all seven categories is "none", then possibly no special = treatment > is required and requesting reservation of a Special-Use Domain > Name may not be appropriate. This direction contains vaguely normative-sounding language ("needs") = but it's not clear what that means in practice. I think this advice = cannot be normative, but really seeks to give guidance much as RFC 3552 = and RFC 2434 do. This document would be easier to put in context if it = did similarly, I think. If there are hard requirements for updating the = IANA registry that this document also specifies be created then they = belong in the IANA Considerations section, since in effect they are = directions to the IANA for maintaining that registry. The text which = follows in section 4 looks like guidance to me, however. > 4. Domain Name Reservation Considerations >=20 > An IETF "Standards Action" RFC specifying some new naming = behaviour, > which requires a Special-Use Domain Name be reserved to implement > this desired new behaviour, needs to contain a "Domain Name > Reservation Considerations" section giving answers in the following > seven categories: I am not sure that instantiating a new named document section is = practical or necessary, and certainly seems destined to delay this = document's progress as there's little recent precedent for it. Modifying = the review and publication process for the RFC Editor will likely also = require IAB review. Most of the considerations that are described in the rest of this = section look entirely reasonable, but perhaps it's not an exhaustive = list. There's no discussion of the applicability of DNSSEC for the = domains concerned, for example -- it might be beneficial for some = applications to specify that zones not be signed, for some reason, or = that the zone in which a definitively non-existent name does not exist = is signed in order to provide cryptographic confidence in its = non-existence. This one, however, touches on policy that I might argue is effectively = outside the realm of IETF specifications: > 7. DNS Registrars: >=20 > How should DNS Registrars treat requests to register this = reserved > domain name? Should such requests be denied? Should such = requests > be allowed, but only to a specially-designated entity? (For > example, the name "www.example.org" is reserved for = documentation > examples and is not available for registration; however, the = name > is in fact registered; and there is even a web site at that = name, > which states circularly that the name is reserved for use in > documentation and cannot be registered!) EXAMPLE.ORG is in fact reserved as described; the implementation of that = reservation is an entry in the ORG registry, but the effect is as = intended. Domain Name:EXAMPLE.ORG Created On:31-Aug-1995 04:00:00 UTC Last Updated On:27-Jul-2010 20:57:51 UTC Expiration Date:30-Aug-2010 04:00:00 UTC Sponsoring Registrar:Internet Assigned Numbers Authority (IANA) = (R193-LROR) Status:DELETE PROHIBITED Status:RENEW PROHIBITED Status:TRANSFER PROHIBITED Status:UPDATE PROHIBITED > 5. Security Considerations >=20 > This document outlines the circumstances in which reserving a = domain > name for special-use is appropriate, and the procedure for having > that Special-Use Domain Name recorded by IANA. Any document > requesting such a Special-Use Domain Name needs to contain an > appropriate "Security Considerations" section which describes any > security issues relevant to that special use. This seems like an additional guideline that would more usefully belong = in section 4. This document doesn't seem to me to have any security = considerations, but a back-reference to guidance in section 4 doesn't = seem unreasonable. > 6. IANA Considerations >=20 > IANA needs to create a new registry of Special-Use Domain Names. >=20 > When IANA receives a request to record a new "Special-Use Domain > Name" it should verify that the IETF "Standards Action" RFC = [RFC5226] > includes the required "Domain Name Reservation Considerations" > section stating how the special meaning of this name affects the > behaviour of hardware, software, and humans in the seven = categories, > and if so, record in the registry the Special-Use Domain Name and a > reference to the RFC that documents it. I don't pretend to speak authoritatively for Michelle and her team, but = this seems almost unimplementable as-written. It would be much easier = for IANA staff to handle this direction if it included more explicit = instructions such as specifying the registry name and the circumstances = in which entries in the registry are to be added, deleted and changed, = and gave clearer instructions (rows, columns) on how the registry was to = be created. An initial set of data for the registry to contain would = also be useful to mention. For what it's worth I drafted a document some time ago with similar = objectives, but without the useful guidance that this document includes. = I've attached a copy to further illustrate my thoughts above. Perhaps = it's not unreasonable to split the content of this document into two = I-Ds, one which specifies the registry and a second which gives guidance = to future document authors who seek to make use of it. Joe --Apple-Mail-15--771451371 Content-Disposition: attachment; filename=draft-jabley-reserved-domain-names.txt Content-Type: text/plain; name="draft-jabley-reserved-domain-names.txt" Content-Transfer-Encoding: quoted-printable Network Working Group J. Abley Internet-Draft ICANN Intended status: BCP October 18, 2010 Expires: April 21, 2011 Reserved Domain Names draft-jabley-reserved-domain-names-00 Abstract The Domain Name System (DNS) makes use of a hierarchical naming scheme. The validity of a particular name in the DNS is governed by protocol, operational and policy considerations. The IETF has identified particular domain names to have special considerations associated with their use. These domain names have been identified in various documents in the RFC series. This document describes the creation of an IANA registry to catalogue such domain names and provides direction about how this registry should be maintained. This document does not identify any new domain name as having special considerations associated with its use. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 21, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Abley Expires April 21, 2011 [Page 1] =0C Internet-Draft Reserved Domain Names October 2010 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abley Expires April 21, 2011 [Page 2] =0C Internet-Draft Reserved Domain Names October 2010 1. Introduction The Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. The DNS makes use of a hierarchical naming scheme. The validity of a particular name in the DNS is governed by protocol, operational and policy considerations. The IETF has identified particular domain names to have special considerations associated with their use. Examples of such domain names are "LOCALHOST" and "EXAMPLE.ORG" which are discussed in [RFC2606], and "LOCAL" and "254.169.IN-ADDR.ARPA" which are described in [I-D.cheshire-dnsext-multicastdns]. This document describes the creation of an IANA registry to catalogue such domain names and provides direction about how this registry should be maintained. This document does not identify any new domain name as having special considerations associated with its use. Abley Expires April 21, 2011 [Page 3] =0C Internet-Draft Reserved Domain Names October 2010 2. IANA Considerations This document directs the IANA to create a registry as follows: +-------------------------+--------------------------------------+ | Parameter | Value | +-------------------------+--------------------------------------+ | Registry Name | Reserved Domain Names | | | | | Reference | This document (RFCXXXX) | | | | | Registration Procedures | Document Published with IAB Approval | +-------------------------+--------------------------------------+ The initial registry contents should be as follows: +-------------+-----------------------------------------+-----------+ | Domain Name | Description | Reference | +-------------+-----------------------------------------+-----------+ | TEST | Recommended for use in testing of | [RFC2606] | | | current or new DNS related code | | | | | | | EXAMPLE | Recommended for use in documentation or | [RFC2606] | | | as examples | | | | | | | INVALID | Recommended for use in documentation or | [RFC2606] | | | as examples | | | | | | | LOCALHOST | Traditionally statically defined in | [RFC2606] | | | host DNS implementations as having an A | | | | record pointing to the loop back IP | | | | address, and reserved for such use | | | | | | | EXAMPLE.COM | Available for use as examples | [RFC2606] | | | | | | EXAMPLE.NET | Available for use as examples | [RFC2606] | | | | | | EXAMPLE.ORG | Available for use as examples | [RFC2606] | +-------------+-----------------------------------------+-----------+ Abley Expires April 21, 2011 [Page 4] =0C Internet-Draft Reserved Domain Names October 2010 3. Security Considerations This document poses no new security issues. Abley Expires April 21, 2011 [Page 5] =0C Internet-Draft Reserved Domain Names October 2010 4. Informative References [I-D.cheshire-dnsext-multicastdns] Cheshire, S. and M. Krochmal, "Multicast DNS", draft-cheshire-dnsext-multicastdns-11 (work in progress), March 2010. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. Abley Expires April 21, 2011 [Page 6] =0C Internet-Draft Reserved Domain Names October 2010 Appendix A. Editorial Notes This section (and sub-sections) to be removed prior to publication. A.1. Change History 00 Initial draft. Abley Expires April 21, 2011 [Page 7] =0C Internet-Draft Reserved Domain Names October 2010 Author's Address Joe Abley ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 USA Phone: +1 519 670 9327 Email: joe.abley@icann.org Abley Expires April 21, 2011 [Page 8] =0C --Apple-Mail-15--771451371-- From fweimer@bfk.de Tue Jan 18 07:15:08 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08DB3A6E53; Tue, 18 Jan 2011 07:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoAqAJCaes6T; Tue, 18 Jan 2011 07:15:08 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id C7C393A6C5D; Tue, 18 Jan 2011 07:15:07 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PfDJW-0003HG-T1; Tue, 18 Jan 2011 15:17:42 +0000 Received: by bfk.de with local id 1PfDJW-0006Lf-ND; Tue, 18 Jan 2011 15:17:42 +0000 To: Joe Abley References: <20110117230048.26192.84056.idtracker@localhost> <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> <769A53CB-E219-48DB-822A-492555F583A7@hopcount.ca> From: Florian Weimer Date: Tue, 18 Jan 2011 15:17:42 +0000 In-Reply-To: <769A53CB-E219-48DB-822A-492555F583A7@hopcount.ca> (Joe Abley's message of "Tue\, 18 Jan 2011 10\:08\:48 -0500") Message-ID: <82k4i2ckbt.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsop@ietf.org, dnsext@ietf.org, Ralph Droms , IETF Directorate DNS Subject: Re: [dnsext] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:15:08 -0000 * Joe Abley: > I don't think special-use names are a concept of the DNS in the > protocol sense, but rather a set of administrative conventions. LOCAL. is very much protocol-enshrined, but I think it has been reserved neither by IETF nor IANA. Would any other reserved name share a similar fate? Then you might be right in the sense that the IETF cannot set aside names for use at the protocol level. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From jabley@hopcount.ca Tue Jan 18 07:18:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B07928C15A; Tue, 18 Jan 2011 07:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEqOAcCC3bzc; Tue, 18 Jan 2011 07:18:25 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id A17C828C125; Tue, 18 Jan 2011 07:18:25 -0800 (PST) Received: from [199.212.90.28] (helo=dh28.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PfDQq-000FZa-Rp; Tue, 18 Jan 2011 15:25:19 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <82k4i2ckbt.fsf@mid.bfk.de> Date: Tue, 18 Jan 2011 10:20:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3F32DBBE-6CAD-45EE-9215-2C5022566139@hopcount.ca> References: <20110117230048.26192.84056.idtracker@localhost> <2A149A97-3B0A-49AA-88CA-9741F88B9274@gmail.com> <769A53CB-E219-48DB-822A-492555F583A7@hopcount.ca> <82k4i2ckbt.fsf@mid.bfk.de> To: Florian Weimer X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.28 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsop@ietf.org, dnsext@ietf.org, Ralph Droms , IETF Directorate DNS Subject: Re: [dnsext] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:18:26 -0000 On 2011-01-18, at 10:17, Florian Weimer wrote: > * Joe Abley: >=20 >> I don't think special-use names are a concept of the DNS in the >> protocol sense, but rather a set of administrative conventions. >=20 > LOCAL. is very much protocol-enshrined, but I think it has been > reserved neither by IETF nor IANA. Would any other reserved name > share a similar fate? Then you might be right in the sense that the > IETF cannot set aside names for use at the protocol level. You're right. I was actually referring to special-use names which have = been specified at the IETF to date rather than those that are in the = process of being specified, but that wasn't clear in the words I used. (I appreciate that in the sense of widespread deployment and = implementation bonjour is clearly extremely specified, but in an IETF = context the work is still ongoing, I think). Joe= From ogud@ogud.com Tue Jan 18 07:26:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F5128C125 for ; Tue, 18 Jan 2011 07:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LuJh85K4roA for ; Tue, 18 Jan 2011 07:26:07 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id EE5AF28C158 for ; Tue, 18 Jan 2011 07:26: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 p0IFShah096962 for ; Tue, 18 Jan 2011 10:28:43 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D35B1AB.3090201@ogud.com> Date: Tue, 18 Jan 2011 10:28:43 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <82ei8afq4p.fsf@mid.bfk.de> <85987.1295361055@nsa.vix.com> In-Reply-To: <85987.1295361055@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dnsext] Increasing character limit for registration in internet domain names: 76 or 68 or 91 or 83 or 64 higher the better X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:26:08 -0000 On 18/01/2011 9:30 AM, Paul Vixie wrote: >> From: Florian Weimer >> Date: Tue, 18 Jan 2011 10:44:06 +0000 >> >> I wasn't really around when the failure of this experiment was >> recognized. Is there a write-up somewhere explaining why this doesn't >> work as expected? (Without major protocol surgery, increasing the >> label length would share a similar fate.) > > no writeup. briefly, it only works if the full end-to-end path knows > about each new label type. so adding each label type would require > incrementing the EDNS version number. this was found to be impractical. > http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-04#section-5 Olafur From hallam@gmail.com Tue Jan 18 08:02:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7962728C151 for ; Tue, 18 Jan 2011 08:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzndTyUd5Br8 for ; Tue, 18 Jan 2011 08:02:12 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id C34BB28C102 for ; Tue, 18 Jan 2011 08:02:11 -0800 (PST) Received: by yxt33 with SMTP id 33so2647994yxt.31 for ; Tue, 18 Jan 2011 08:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=2EzEAa69j7zgUtMODp2Nx5dhG9vfngbBZbf6tB7zw0g=; b=cZn3x2e+mce6AzAC/Ye6PJ8o6wkK9NMuk2BnNJOit1i7NWF63ZHpuD1qARySis4ZaS lfiEHdPVkoD5yR1erGnvirkpbQSVbaq/RjNkdb42rXGx/GVuKG3BWdYjQBcJNKPGYvwb j7R+jqjoG42XjzYOznppJOqmMA+5XmpGEOU6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jbTCytLikxP1QLnywayapzVyHTihgPqNIFk71b2jRTjHzJpoXtDCiJ2bYfTLtXpuFm HDou4DGwVCmPUbqHErrzVis5vc5WFWBtH8MBA61SikAoCqFujm72foKO6Dy3EpnTvZk9 ne2r9ESGAXFALRkOGHnyVNUIEBpiNxDmsvUNI= MIME-Version: 1.0 Received: by 10.101.67.16 with SMTP id u16mr3606096ank.1.1295366688870; Tue, 18 Jan 2011 08:04:48 -0800 (PST) Received: by 10.100.31.8 with HTTP; Tue, 18 Jan 2011 08:04:48 -0800 (PST) Date: Tue, 18 Jan 2011 11:04:48 -0500 Message-ID: From: Phillip Hallam-Baker To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=00163662e65b581501049a210f9d Subject: [dnsext] Current status of SRV prefix registry X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 16:02:13 -0000 --00163662e65b581501049a210f9d Content-Type: text/plain; charset=ISO-8859-1 What is the current status of the SRV prefix registry proposal? It seems that people make suggestions from time to time but these do not seem to have led to a concrete result. It is clear that there are a lot of protocols making use of SRV, only some of which are tracked by IANA. As a result there is the possibility of assignments of multiple code points for the same protocol and multiple protocols to the same code point. There is also a lack of transparency. The need for such a registry is evidenced by the fact that several other people have started registries. While these are better than nothing, I would prefer that type of function to be performed by IANA. I would like to suggest that we initiate a new IANA registry to track use of code points by SRV, NAPTR and all other prefixed protocols. As such there would be a very low barrier to entry. Certainly no higher than is required for port number assignments. In fact to encourage conservation of port numbers I would like the rules to be looser than for port numbers. Most probably first-come-first served. At present SRV attempts to re-use the IANA port number assignment registry by making use of the protocol identifier field to form the protocol label and adding either _tcp or _udp to disambiguate protocols that can be used over either transport. I don't think this structure is very useful since it pre-supposes the assignment of a port number and one of the most important advantages of SRV type discovery is to avoid the need for a dedicated port assignment. I have never been fond of the _tcp and _udp thing either, the number of cases of ambiguity is so small as to be insignificant and it is really a property that should have appeared on the right hand side of the production along with the port number. But at this point it is really too late to change. This leads me to suggest a registry that is essentially flat with _tcp and _udp reserved for use with protocols that have assigned port numbers and all other values would be open for assignment with no particular semantics attached. In other words, I don't want to get into the business of registering new transport protocols for SOAP and Web Services and the like. Nor do I particularly want to get into the business of having IANA create and maintain separate subregistries if that can be avoided. I would like maintenance of the registry to be totally decoupled from IETF working groups and process. Over the next few years I anticipate there being thousands of new Web Service protocols emerging. I don't think it is going to be at all helpful to have anyone try to act as an intermediator. The prefix registry space is essentially infinite and there is no harm caused by injudicious assignments. There might be an interest in separate registries for other standards organizations (_w3c, _oasis). Which might make sense if it would encourage use of extended discovery. But that would create additional administration overhead and I can't see any real return. We might want to make provision for new subregistries that would have specific assignment requirements but I would prefer to just have a flat space. All that really mattered with port numbers was that they were distinct. We did not attempt to impose hierarchy there, there does not seem to be any problem with a lack. Cleaning up the registry would be a necessary but not sufficient criteria for moving to an enhanced discovery scheme based on DNS prefixing. -- Website: http://hallambaker.com/ --00163662e65b581501049a210f9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What is the current status of the SRV prefix registry proposal? It seems th= at people make suggestions from time to time but these do not seem to have = led to a concrete result.

It is clear that there are a l= ot of protocols making use of SRV, only some of which are tracked by IANA. = As a result there is the possibility of assignments of multiple code points= for the same protocol and multiple protocols to the same code point. There= is also a lack of transparency.

The need for such a registry is evidenced by the fact t= hat several other people have started registries. While these are better th= an nothing, I would prefer that type of function to be performed by IANA.


I would like to suggest that we initiate= a new IANA registry to track use of code points by SRV, NAPTR and all othe= r prefixed protocols. As such there would be a very low barrier to entry. C= ertainly no higher than is required for port number assignments. In fact to= encourage conservation of port numbers I would like the rules to be looser= than for port numbers. Most probably first-come-first served.=A0

At present SRV attempts to re-use the IANA port number = assignment registry by making use of the protocol identifier field to form = the protocol label and adding either _tcp or _udp to disambiguate protocols= that can be used over either transport.

I don't think this structure is very useful since i= t pre-supposes the assignment of a port number and one of the most importan= t advantages of SRV type discovery is to avoid the need for a dedicated por= t assignment.

I have never been fond of the _tcp and _udp thing eithe= r, the number of cases of ambiguity is so small as to be insignificant and = it is really a property that should have appeared on the right hand side of= the production along with the port number. But at this point it is really = too late to change.


This leads me to suggest a registry that= is essentially flat with _tcp and _udp reserved for use with protocols tha= t have assigned port numbers and all other values would be open for assignm= ent with no particular semantics attached.

In other words, I don't want to get into the busine= ss of registering new transport protocols for SOAP and Web Services and the= like. Nor do I particularly want to get into the business of having IANA c= reate and maintain separate subregistries if that can be avoided.

I would like maintenance of the registry to be totally = decoupled from IETF working groups and process. Over the next few years I a= nticipate there being thousands of new Web Service protocols emerging. I do= n't think it is going to be at all helpful to have anyone try to act as= an intermediator. The prefix registry space is essentially infinite and th= ere is no harm caused by injudicious assignments.


There might be an interest in separate r= egistries for other standards organizations (_w3c, _oasis). Which might mak= e sense if it would encourage use of extended discovery. But that would cre= ate additional administration overhead and I can't see any real return.= We might want to make provision for new subregistries that would have spec= ific assignment requirements but I would prefer to just have a flat space.<= /div>

All that really mattered with port numbers was that the= y were distinct. We did not attempt to impose hierarchy there, there does n= ot seem to be any problem with a lack.


Cleaning up the registry would be a necessary but not sufficient crite= ria for moving to an enhanced discovery scheme based on DNS prefixing. --00163662e65b581501049a210f9d-- From johnl@iecc.com Tue Jan 18 08:17:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6213A702D for ; Tue, 18 Jan 2011 08:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.669 X-Spam-Level: X-Spam-Status: No, score=-110.669 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXj+IwXnDxYP for ; Tue, 18 Jan 2011 08:17:33 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 155693A7021 for ; Tue, 18 Jan 2011 08:17:31 -0800 (PST) Received: (qmail 30659 invoked from network); 18 Jan 2011 16:20:08 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 18 Jan 2011 16:20:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=c1de.4d35bdb8.k1101; i=johnl@user.iecc.com; bh=14sIjBmFzcoAUWdyLnA+oUljT7hw10kFT337ZLIRNHs=; b=MUvasA6cf82RfAxw8v7h8oqDU3rsLdhxkJ7OxXqeIgv1IWNCIiPwvciaRtltfrD14PsKGCypHkwZnEytn3vMTmgV0DeGybqgtFMXga9m3A2nLyzDc6CNuLvfg8bJKSER8rGI7ekPBm48yxFrJbRpeZCKeaLwI1xj4nVyTpTHAu4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Jan 2011 16:20:08 -0000 Message-ID: <20110118162008.49629.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Current status of SRV prefix registry X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 16:17:34 -0000 >I would like to suggest that we initiate a new IANA registry to track use of >code points by SRV, NAPTR and all other prefixed protocols. http://tools.ietf.org/html/draft-levine-reserved-names-registry-01 See section 2.4. Never got much traction. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Tue Jan 18 08:18:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7193A703C for ; Tue, 18 Jan 2011 08:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.677 X-Spam-Level: X-Spam-Status: No, score=-110.677 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0-pJUKKz1Jj for ; Tue, 18 Jan 2011 08:18:21 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 1374E3A703B for ; Tue, 18 Jan 2011 08:18:20 -0800 (PST) Received: (qmail 31557 invoked from network); 18 Jan 2011 16:20:57 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 18 Jan 2011 16:20:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=c2bc.4d35bde8.k1101; i=johnl@user.iecc.com; bh=5+6X9QvO3awX7DZ9ICZ5UC0zbTMqx6R3bGupc8PGuiw=; b=dLW/ZJ//NrZqqHY6vn9t9wlfSV/QttPvTU/LunwBAmQIqeq+Mz68IAA1p+7oXSfgpiPP+++98id7UTy6y88udCC/mZr3nO4XYIe1f6QXek+rVu9o3BJg1r2VuIY4BNBqtRTLLt80soczLtSc+3PI6T4IVne+ZaIkpCf7DFU/KhY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Jan 2011 16:20:56 -0000 Message-ID: <20110118162056.49851.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <82k4i2ckbt.fsf@mid.bfk.de> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 16:18:22 -0000 >LOCAL. is very much protocol-enshrined, but I think it has been >reserved neither by IETF nor IANA. Would any other reserved name >share a similar fate? Then you might be right in the sense that the >IETF cannot set aside names for use at the protocol level. http://tools.ietf.org/html/draft-levine-reserved-names-registry-01 See section 2.1.4. Never got much traction, either. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From ogud@ogud.com Tue Jan 18 08:31:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B8A28C17F for ; Tue, 18 Jan 2011 08:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7UZmzZXbl8B for ; Tue, 18 Jan 2011 08:31:05 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 036F728C190 for ; Tue, 18 Jan 2011 08:31:04 -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 p0IGXfPg097537 for ; Tue, 18 Jan 2011 11:33:42 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4D35C0E5.4070901@ogud.com> Date: Tue, 18 Jan 2011 11:33:41 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110118162008.49629.qmail@joyce.lan> In-Reply-To: <20110118162008.49629.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dnsext] Current status of SRV prefix registry X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 16:31:06 -0000 On 18/01/2011 11:20 AM, John Levine wrote: >> I would like to suggest that we initiate a new IANA registry to track use of >> code points by SRV, NAPTR and all other prefixed protocols. > > http://tools.ietf.org/html/draft-levine-reserved-names-registry-01 > > See section 2.4. Never got much traction. > Following drafts are addressing this: http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports-09 http://tools.ietf.org/id/draft-gudmundsson-dnsext-srv-clarify-02.txt Olafur From brian.peter.dickson@gmail.com Tue Jan 18 08:52:55 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F63728C1F3 for ; Tue, 18 Jan 2011 08:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEu+WKnYdj+s for ; Tue, 18 Jan 2011 08:52:53 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7C2AA28C166 for ; Tue, 18 Jan 2011 08:52:53 -0800 (PST) Received: by fxm9 with SMTP id 9so8122568fxm.31 for ; Tue, 18 Jan 2011 08:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cMhx8bmYZZSr0rpvMBTOWKMb0zUVT8BaKrEPipQbquI=; b=dj5gyfnK7SjJpkoWtpY7lpIXsWIs9Y9CpmZz2vTheHzanrKyrt1Ry8uQAZkDihm83O IP536ZF9bGgh02zWpEAOQsxBSBpwMZDdRY1EWGebvlSzUi+mDkTqGlGRGjGD/m5v2Tfl gcbNGgRsr/IKW+7qchA7EEbxmKX7GielAyHAE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VE6aBljt72VU5yQFq4qJwesCqvnShgHTcwTIiSi/eyK7PJVPts/zwU6SdmdepueWl/ vUeT6FpT5a7K//qHyp+cEveIlXL5vz8LOZDB+SJoQpueZ7XhwcF3H+d1g6rvpDCgDYuq NEF9Rs3KOiQTHDzjl7+S5d9JqRDtgFMA93lWs= MIME-Version: 1.0 Received: by 10.223.104.145 with SMTP id p17mr6521541fao.105.1295369704445; Tue, 18 Jan 2011 08:55:04 -0800 (PST) Received: by 10.223.111.142 with HTTP; Tue, 18 Jan 2011 08:55:04 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Jan 2011 12:55:04 -0400 Message-ID: From: Brian Dickson To: Krishna Birth Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Increasing character limit for registration in internet domain names: 76 or 68 or 91 or 83 or 64 higher the better X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 16:52:55 -0000 Hi, Krishna, An "internet domain name" is also known as a "fully qualified domain name", or FQDN. An FQDN can be up to 255 characters in length. The limit of 63 characters is on the individual components of that name, or "labels". Breaking up the prayer words with hyphens between words, and "." between phrases, works nicely, without changing the current limits: "hare-krishna.hare-krishna.krishna-krishna.hare-hare.hare-rama.hare-rama.ra= ma-rama.hare-hare" which would probably need to be underneath hare-krishna.org or something suitable, like: hare-krishna.hare-krishna.krishna-krishna.hare-hare.hare-rama.hare-rama.ram= a-rama.hare-hare.hare-krishna.org. You're welcome, Brian On Fri, Jan 14, 2011 at 5:48 PM, Krishna Birth wro= te: > After I had posted yesterday the following on the ietf@ietf.org mailing > list, I was requested in an email to myself to put it also to this specif= ic > mailing list for discussion: > > > (please view this email with UTF-8 enabled on your viewer) > > This is a request for internet engineers to increase the character limit = for > registration in the various internet domain names (com, net, org, info et= c) > from 63 characters to more at least 76 or 68 or 91 or 83 or 64, the highe= r > it is the better.=C2=A0 I believe the raising the characters on the inter= net > domain names will [be] very good from a spiritual perspective.=C2=A0 I ba= se these > figures on the spiritual prayer and chant: > > harekrishnaharekrishnakrishnakrishnahareharehareramahareramaramaramahareh= are > =3D 76 characters > > harekrsnaharekrsnakrsnakrsnahareharehareramahareramaramaramaharehare =3D = 68 > characters > > hare-krishna-hare-krishna-krishna-krishna-hare-hare-hare-rama-hare-rama-r= ama-rama-hare-hare > =3D 91 characters > > hare-krsna-hare-krsna-krsna-krsna-hare-hare-hare-rama-hare-rama-rama-rama= -hare-hare > =3D 83 characters > > harekrsnaharekrsnakrsnakrsnahareharehareramhareramramramharehare =3D 64 > characters > > > It would allow the Hare =E0=A4=95rishna Mahamantra, the great prayer for = deliverance > in this Age to be fully put on an internet domain name.=C2=A0 The chantin= g and > recitation of the Mahamantra cleanses the heart of the impurities and > pollution.=C2=A0 Caitanya Mahaprabhu and incarnation of =E0=A4=95rishna, = the Supreme > Personality of Godhead Movement, popularised the chanting of the Mahamant= ra > some 500 years ago and is meant for every town and village in the world. > > Now His Divine Grace A C Bha=E0=A4=95tivedanta Swami=C2=A0 Prabhupada, Fo= under, Eternal > Di=E0=A4=95sa and Si=E0=A4=95sa Spiritual Master of the Hare =E0=A4=95ris= hna Movement in the chain > of disciplic succession has popularised it in the West and continues to > popularise. > > > p.s. Some time ago I posted on the IETF mailing list via another email > account. > > > Best, > > > Mee=E0=A4=95u > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > From marka@isc.org Tue Jan 18 15:49:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6DA28C15C for ; Tue, 18 Jan 2011 15:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhXpRTLnOe5d for ; Tue, 18 Jan 2011 15:49:41 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 9140F28C128 for ; Tue, 18 Jan 2011 15:49:41 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7DB1F5F9863; Tue, 18 Jan 2011 23:52:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 5F0AAE6030; Tue, 18 Jan 2011 23:52:02 +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 864BE8E3A2B; Wed, 19 Jan 2011 10:51:59 +1100 (EST) To: Paul Vixie From: Mark Andrews References: <82ei8afq4p.fsf@mid.bfk.de> <85987.1295361055@nsa.vix.com> In-reply-to: Your message of "Tue, 18 Jan 2011 14:30:55 -0000." <85987.1295361055@nsa.vix.com> Date: Wed, 19 Jan 2011 10:51:59 +1100 Message-Id: <20110118235159.864BE8E3A2B@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Increasing character limit for registration in internet domain names: 76 or 68 or 91 or 83 or 64 higher the better X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 23:49:42 -0000 In message <85987.1295361055@nsa.vix.com>, Paul Vixie writes: > > From: Florian Weimer > > Date: Tue, 18 Jan 2011 10:44:06 +0000 > > > > I wasn't really around when the failure of this experiment was > > recognized. Is there a write-up somewhere explaining why this doesn't > > work as expected? (Without major protocol surgery, increasing the > > label length would share a similar fate.) > > no writeup. briefly, it only works if the full end-to-end path knows > about each new label type. so adding each label type would require > incrementing the EDNS version number. this was found to be impractical. The problem is worse than that. All the parent server need to be able to parse the QNAME to be able to issue a referral. You can't find the OPT record to do EDNS version processing. I don't know why we are talking about this at all. I've see no evidence that 63 characters is not enough space for any label people are likely to be typing in even with IDN. this-is-a-very-long-hostname-that-I-would-never-use-in-practice.isc.org An entire sentence is encoded in that label. If you need to encode longer sentences into labels for a database stored in the DNS then I suggest that you use a cryptographic hash, base32 encode the result and do collision detection. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ahu@xs.powerdns.com Wed Jan 19 11:01:08 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990083A719D for ; Wed, 19 Jan 2011 11:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+H9mxCLuPHB for ; Wed, 19 Jan 2011 11:01:08 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by core3.amsl.com (Postfix) with ESMTP id 957623A7195 for ; Wed, 19 Jan 2011 11:01:07 -0800 (PST) Received: from ahu by xs.powerdns.com with local (Exim 4.69) (envelope-from ) id 1PfdJq-0003dj-S8 for dnsext@ietf.org; Wed, 19 Jan 2011 20:03:46 +0100 Date: Wed, 19 Jan 2011 20:03:46 +0100 From: bert hubert To: dnsext@ietf.org Message-ID: <20110119190346.GA13422@xs.powerdns.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:01:08 -0000 Hi everybody, PowerDNSSEC turns out to be confused by spaces in the database (or zone file) in the DS digest. It terminates the digest at the first non-hex character. The venerable 'dig' tool emits DS digest type 2 with spaces: powerdns.nl. 7200 IN NS powerdnssec2.ds9a.nl. powerdns.nl. 7200 IN NS powerdnssec1.ds9a.nl. powerdns.nl. 7200 IN DS 7354 8 2 F238862D8DFCB5C837D33E28C0D318191DBA76FFC87C6F053D2AD67E 22BF1D7C RFC 3658 says: 'The presentation format of the DS record consists of three numbers (key tag, algorithm, and digest type) followed by the digest itself presented in hex' It says nothing about spaces in the hex. Of course we could be liberal in what we accept, however, there is also the NSEC3 and NSEC3PARAM which store the salt.. in hex. RFC5155 says: The Salt field is represented as a sequence of case-insensitive hexadecimal digits. Whitespace is not allowed within the sequence. Finally, SSHFP is the third type that encodes hex blobs, and RFC 4255 states: 'The RDATA of the presentation format of the SSHFP resource record consists of two numbers (algorithm and fingerprint type) followed by the fingerprint itself, presented in hex" Sadly this breaks the nice symmetry where we had only one 'hexBlob', one that terminates at the first space. Because 'dig' is so widely distributed, I'm afraid we'll have no choice but to butcher PowerDNS into dealing with the spaces, but what do people think? Do spaces belong in hex blobs, and in the DS specifically? Bert From alex@alex.org.uk Wed Jan 19 11:09:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715323A714F for ; Wed, 19 Jan 2011 11:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r6peI-TdcRV for ; Wed, 19 Jan 2011 11:09:02 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id A51E63A7077 for ; Wed, 19 Jan 2011 11:09:02 -0800 (PST) Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 8DA58C56489; Wed, 19 Jan 2011 19:11:41 +0000 (GMT) Date: Wed, 19 Jan 2011 19:11:40 +0000 From: Alex Bligh To: bert hubert , dnsext@ietf.org Message-ID: <8B3DA173C962A2F23ED0E3D6@Ximines.local> In-Reply-To: <20110119190346.GA13422@xs.powerdns.com> References: <20110119190346.GA13422@xs.powerdns.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jan 2011 19:09:03 -0000 --On 19 January 2011 20:03:46 +0100 bert hubert wrote: > what do people think? dig bug -- Alex Bligh From paul@xelerance.com Wed Jan 19 11:27:06 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714CF3A71AA for ; Wed, 19 Jan 2011 11:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAwismqI53B2 for ; Wed, 19 Jan 2011 11:27:04 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 0EAB73A71A9 for ; Wed, 19 Jan 2011 11:27:04 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 8FC5EC51C; Wed, 19 Jan 2011 14:29:42 -0500 (EST) Date: Wed, 19 Jan 2011 14:29:42 -0500 (EST) From: Paul Wouters To: bert hubert In-Reply-To: <20110119190346.GA13422@xs.powerdns.com> Message-ID: References: <20110119190346.GA13422@xs.powerdns.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:27:06 -0000 On Wed, 19 Jan 2011, bert hubert wrote: > The venerable 'dig' tool emits DS digest type 2 with spaces: > powerdns.nl. 7200 IN NS powerdnssec2.ds9a.nl. > powerdns.nl. 7200 IN NS powerdnssec1.ds9a.nl. > powerdns.nl. 7200 IN DS 7354 8 2 > F238862D8DFCB5C837D33E28C0D318191DBA76FFC87C6F053D2AD67E 22BF1D7C It really differs for which dig. Eg this older one shows: openswan.nl. 7200 IN DS 42018 5 2 ( 8DB5704A28E9F583E0E6AB41EED3BCF2613E2AD4BDC3 69C64A395F2F5EA16917 ) I'd say this is a dig specific issue. Paul From hallam@gmail.com Wed Jan 19 11:36:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98CD43A71B9 for ; Wed, 19 Jan 2011 11:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BVKWUBKg8df for ; Wed, 19 Jan 2011 11:36:09 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D467D3A71BC for ; Wed, 19 Jan 2011 11:36:08 -0800 (PST) Received: by gwj17 with SMTP id 17so518810gwj.31 for ; Wed, 19 Jan 2011 11:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8P0NODur+Zp1k/7Y2zRsuGU49En01gHb19mvt9BGdSY=; b=O7/2mn5Kb+VOXoP2kHSi9XN6Q/SEnxEz6l3EH1+on+h1MSzm2goHpQATdKrzE1JYA7 x9PNzzgXGMAJVvp14fzBGifdVkPMBpgHaCB+Tz45xmjohMHyH8n46CYszRerx9R6VYHx OZasVEAmT95G1ffI5pmMu2oaHkkM7hsM4KXaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bvDi6GtkQdusm/llt8KAT6DVJtAj/Dl6yZi5phdR6U8zRYguwrrKIb+mlbpPK/iBjN 4QYI9V66FRuHbbqNUi0dfcqngaoOqoG4ZNwY1q/F8p0e9MdDY0k2xYNAMEJeKBs22uNM LRnmAIRoiwy30Pj8Mm67F0Xhh//k7hgZugFis= MIME-Version: 1.0 Received: by 10.100.154.2 with SMTP id b2mr796032ane.154.1295465928932; Wed, 19 Jan 2011 11:38:48 -0800 (PST) Received: by 10.100.201.18 with HTTP; Wed, 19 Jan 2011 11:38:48 -0800 (PST) In-Reply-To: <20110119190346.GA13422@xs.powerdns.com> References: <20110119190346.GA13422@xs.powerdns.com> Date: Wed, 19 Jan 2011 14:38:48 -0500 Message-ID: From: Phillip Hallam-Baker To: bert hubert Content-Type: multipart/alternative; boundary=0016e644ddf08342e7049a382a40 Cc: dnsext@ietf.org Subject: Re: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:36:11 -0000 --0016e644ddf08342e7049a382a40 Content-Type: text/plain; charset=ISO-8859-1 Didn't we move to a view that presentation format is not part of the DNS specification and hence later drafts have 'suggested' presentation formats? It gets a bit problematic because there is a presumption of interoperability in the configuration file format even though that is never exchanged as bits on the wire. On Wed, Jan 19, 2011 at 2:03 PM, bert hubert wrote: > Hi everybody, > > PowerDNSSEC turns out to be confused by spaces in the database (or zone > file) in the DS digest. It terminates the digest at the first non-hex > character. > > The venerable 'dig' tool emits DS digest type 2 with spaces: > powerdns.nl. 7200 IN NS powerdnssec2.ds9a.nl. > powerdns.nl. 7200 IN NS powerdnssec1.ds9a.nl. > powerdns.nl. 7200 IN DS 7354 8 2 > F238862D8DFCB5C837D33E28C0D318191DBA76FFC87C6F053D2AD67E 22BF1D7C > > RFC 3658 says: > > 'The presentation format of the DS record consists of three numbers > (key tag, algorithm, and digest type) followed by the digest itself > presented in hex' > > It says nothing about spaces in the hex. Of course we could be liberal in > what we accept, however, there is also the NSEC3 and NSEC3PARAM which store > the salt.. in hex. > > RFC5155 says: > > The Salt field is represented as a sequence of case-insensitive > hexadecimal digits. Whitespace is not allowed within the > sequence. > > Finally, SSHFP is the third type that encodes hex blobs, and RFC 4255 > states: > > 'The RDATA of the presentation format of the SSHFP resource record > consists of two numbers (algorithm and fingerprint type) followed by > the fingerprint itself, presented in hex" > > Sadly this breaks the nice symmetry where we had only one 'hexBlob', one > that terminates at the first space. > > Because 'dig' is so widely distributed, I'm afraid we'll have no choice but > to butcher PowerDNS into dealing with the spaces, but what do people think? > Do spaces belong in hex blobs, and in the DS specifically? > > Bert > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --0016e644ddf08342e7049a382a40 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Didn't we move to a view that presentation format is not part of the DN= S specification and hence later drafts have 'suggested' presentatio= n formats?

It gets a bit problematic because there is a = presumption of interoperability in the configuration file format even thoug= h that is never exchanged as bits on the wire.


On Wed, Jan 19, 2011 at 2:03 PM, be= rt hubert <bert.hubert@netherlabs.nl> wrote:
Hi everybody,

PowerDNSSEC turns out to be confused by spaces in the database (or zone
file) in the DS digest. It terminates the digest at the first non-hex
character.

The venerable 'dig' tool emits DS digest type 2 with spaces:
powerdns.nl. =A0 =A0 = =A0 =A0 =A0 =A07200 =A0 =A0IN =A0 =A0 =A0NS =A0 =A0 =A0powerdnssec2.ds9a.nl.
powerdns.nl. =A0 =A0 = =A0 =A0 =A0 =A07200 =A0 =A0IN =A0 =A0 =A0NS =A0 =A0 =A0powerdnssec1.ds9a.nl.
powerdns.nl. =A0 =A0 = =A0 =A0 =A0 =A07200 =A0 =A0IN =A0 =A0 =A0DS =A0 =A0 =A07354 8 2
F238862D8DFCB5C837D33E28C0D318191DBA76FFC87C6F053D2AD67E 22BF1D7C

RFC 3658 says:

=A0'The presentation format of the DS record consists of three numbers<= br> =A0(key tag, algorithm, and digest type) followed by the digest itself
=A0presented in hex'

It says nothing about spaces in the hex. Of course we could be liberal in what we accept, however, there is also the NSEC3 and NSEC3PARAM which store=
the salt.. in hex.

RFC5155 says:

=A0 =A0 =A0 =A0The Salt field is represented as a sequence of case-insensi= tive
=A0 =A0 =A0 =A0hexadecimal digits. =A0Whitespace is not allowed within the=
=A0 =A0 =A0 =A0sequence.

Finally, SSHFP is the third type that encodes hex blobs, and RFC 4255
states:

=A0 'The RDATA of the presentation format of the SSHFP resource record=
=A0 consists of two numbers (algorithm and fingerprint type) followed by =A0 the fingerprint itself, presented in hex"

Sadly this breaks the nice symmetry where we had only one 'hexBlob'= , one
that terminates at the first space.

Because 'dig' is so widely distributed, I'm afraid we'll ha= ve no choice but
to butcher PowerDNS into dealing with the spaces, but what do people think?=
Do spaces belong in hex blobs, and in the DS specifically?

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



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

--0016e644ddf08342e7049a382a40-- From fanf2@hermes.cam.ac.uk Wed Jan 19 11:39:10 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6143A7038 for ; Wed, 19 Jan 2011 11:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99AywKOf7T84 for ; Wed, 19 Jan 2011 11:39:09 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 8E95C3A6F6C for ; Wed, 19 Jan 2011 11:39:09 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:49174) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Pfdue-0006Xl-rW (Exim 4.72) (return-path ); Wed, 19 Jan 2011 19:41:48 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Pfdue-0000e6-In (Exim 4.67) (return-path ); Wed, 19 Jan 2011 19:41:48 +0000 Date: Wed, 19 Jan 2011 19:41:48 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: bert hubert In-Reply-To: <20110119190346.GA13422@xs.powerdns.com> Message-ID: References: <20110119190346.GA13422@xs.powerdns.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] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:39:10 -0000 On Wed, 19 Jan 2011, bert hubert wrote: > Do spaces belong in hex blobs, and in the DS specifically? The example in RFC 4034 section 5.4 has whitespace inside the hex blob. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From reed@reedmedia.net Wed Jan 19 11:40:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCDC03A7063 for ; Wed, 19 Jan 2011 11:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQE1HC0BF42H for ; Wed, 19 Jan 2011 11:40:43 -0800 (PST) Received: from c-0500.emailmediator.com (c-0500.emailmediator.com [64.85.162.118]) by core3.amsl.com (Postfix) with ESMTP id 0B6003A6F6C for ; Wed, 19 Jan 2011 11:40:43 -0800 (PST) Received: from pool-71-164-190-204.dllstx.fios.verizon.net ([71.164.190.204] helo=reedmedia.net) by c-0500.emailmediator.com with esmtpa (Exim 4.69) (envelope-from ) id 1PfdwA-0001iq-L5; Wed, 19 Jan 2011 14:43:22 -0500 Received: from reed@reedmedia.net by reedmedia.net with local (mailout 0.17) id 28962-1295466202; Wed, 19 Jan 2011 13:43:23 -0600 Date: Wed, 19 Jan 2011 13:43:22 -0600 (CST) From: "Jeremy C. Reed" X-X-Sender: reed@t1.m.reedmedia.net To: bert hubert In-Reply-To: <20110119190346.GA13422@xs.powerdns.com> Message-ID: References: <20110119190346.GA13422@xs.powerdns.com> User-Agent: Alpine 2.01 (NEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: dnsext@ietf.org Subject: Re: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:40:43 -0000 On Wed, 19 Jan 2011, bert hubert wrote: > PowerDNSSEC turns out to be confused by spaces in the database (or zone > file) in the DS digest. It terminates the digest at the first non-hex > character. > > The venerable 'dig' tool emits DS digest type 2 with spaces: > powerdns.nl. 7200 IN NS powerdnssec2.ds9a.nl. > powerdns.nl. 7200 IN NS powerdnssec1.ds9a.nl. > powerdns.nl. 7200 IN DS 7354 8 2 > F238862D8DFCB5C837D33E28C0D318191DBA76FFC87C6F053D2AD67E 22BF1D7C > > RFC 3658 says: > > 'The presentation format of the DS record consists of three numbers > (key tag, algorithm, and digest type) followed by the digest itself > presented in hex' > > It says nothing about spaces in the hex. Of course we could be liberal in > what we accept, however, there is also the NSEC3 and NSEC3PARAM which store > the salt.. in hex. 3658 is obsoleted by 4033. RFC 4033 says "Whitespace is allowed within the hexadecimal text." From roy@nominet.org.uk Wed Jan 19 11:42:46 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCE33A7063 for ; Wed, 19 Jan 2011 11:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snvHlsU6msqT for ; Wed, 19 Jan 2011 11:42:44 -0800 (PST) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by core3.amsl.com (Postfix) with ESMTP id 0D3F13A7038 for ; Wed, 19 Jan 2011 11:42:43 -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: MIME-Version; b=vH8SYy+xr8NjO3mPMACIpmKPavOUkLYC57K85chvmHptsFFxe1fbRvED 1vKBAKTMjFp6RmvLaC5okPEsM6cR/P8MiV1pnYvQXJp7z1k3cQNaGTXUe dJXgU2ZekUjF0EW; 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=1295466325; x=1327002325; 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]=20spaces=20in=20hex=20DS=20digest,=20NSEC3 =20salt=20and=20SSHFP|Date:=20Wed,=2019=20Jan=202011=2019 :45:13=20+0000|Message-ID:=20<6488638E-BBC4-4DBF-B127-262 BB4208275@nominet.org.uk>|To:=20Phillip=20Hallam-Baker=20 |CC:=20bert=20hubert=20,=20"dnsext@ietf.org"=0D=0A=09|MIME-Version:=201.0|In-Reply-To:=20|References:=20 <20110119190346.GA13422@xs.powerdns.com>=0D=0A=20; bh=K07WOZNw4Sd3yzABO4m6E/c2kYCXz9TwXjCoCg6njts=; b=JAewr6/mlxNf9zFSwY6zVj5QTHcFdk3EkD0mHHZYqv7s7Zfd/00F2cvn CftnmSwIOXbUkBy3y+49XYco/y7VC2BoHtgu4ju4SEGITN4M54ZbFj4/u 4HGwcr9entD81v6; X-IronPort-AV: E=Sophos;i="4.60,345,1291593600"; d="scan'208,217";a="30372612" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 19 Jan 2011 19:45:23 +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, 19 Jan 2011 19:45:15 +0000 From: Roy Arends To: Phillip Hallam-Baker Thread-Topic: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP Thread-Index: AQHLuAulh7GHFCbBV0+/6UvPRMqJwpPYsOQAgAABy2w= Date: Wed, 19 Jan 2011 19:45:13 +0000 Message-ID: <6488638E-BBC4-4DBF-B127-262BB4208275@nominet.org.uk> References: <20110119190346.GA13422@xs.powerdns.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6488638EBBC44DBFB127262BB4208275nominetorguk_" MIME-Version: 1.0 Cc: "dnsext@ietf.org" , bert hubert Subject: Re: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:42:46 -0000 --_000_6488638EBBC44DBFB127262BB4208275nominetorguk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't recall that. RFC1035 defines Master Files Format in section 5. Hope this helps. Roy Sent from my iPhone On 19 Jan 2011, at 19:39, "Phillip Hallam-Baker" > wrote: Didn't we move to a view that presentation format is not part of the DNS sp= ecification and hence later drafts have 'suggested' presentation formats? It gets a bit problematic because there is a presumption of interoperabilit= y in the configuration file format even though that is never exchanged as b= its on the wire. On Wed, Jan 19, 2011 at 2:03 PM, bert hubert <bert.hubert@netherlabs.nl> wrote: Hi everybody, PowerDNSSEC turns out to be confused by spaces in the database (or zone file) in the DS digest. It terminates the digest at the first non-hex character. The venerable 'dig' tool emits DS digest type 2 with spaces: powerdns.nl. 7200 IN = NS powerdnssec2.ds9a.nl. powerdns.nl. 7200 IN = NS powerdnssec1.ds9a.nl. powerdns.nl. 7200 IN = DS 7354 8 2 F238862D8DFCB5C837D33E28C0D318191DBA76FFC87C6F053D2AD67E 22BF1D7C RFC 3658 says: 'The presentation format of the DS record consists of three numbers (key tag, algorithm, and digest type) followed by the digest itself presented in hex' It says nothing about spaces in the hex. Of course we could be liberal in what we accept, however, there is also the NSEC3 and NSEC3PARAM which store the salt.. in hex. RFC5155 says: The Salt field is represented as a sequence of case-insensitive hexadecimal digits. Whitespace is not allowed within the sequence. Finally, SSHFP is the third type that encodes hex blobs, and RFC 4255 states: 'The RDATA of the presentation format of the SSHFP resource record consists of two numbers (algorithm and fingerprint type) followed by the fingerprint itself, presented in hex" Sadly this breaks the nice symmetry where we had only one 'hexBlob', one that terminates at the first space. Because 'dig' is so widely distributed, I'm afraid we'll have no choice but to butcher PowerDNS into dealing with the spaces, but what do people think? Do spaces belong in hex blobs, and in the DS specifically? Bert _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/= listinfo/dnsext -- Website: http://hallambaker.com/ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --_000_6488638EBBC44DBFB127262BB4208275nominetorguk_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I don't recall that. RFC1035 defines Master = Files Format in section 5.

Hope this helps.
<= div>
Roy

Sent from my iPhone

On 1= 9 Jan 2011, at 19:39, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:

Didn't we move to a view that presentation = format is not part of the DNS specification and hence later drafts have 'su= ggested' presentation formats?

It gets a bit problematic= because there is a presumption of interoperability in the configuration fi= le format even though that is never exchanged as bits on the wire.


On Wed, Jan 19, 2011 at 2:03 PM, be= rt hubert <bert.hubert@netherlabs.nl> wrote:
Hi everybody,

PowerDNSSEC turns out to be confused by spaces in the database (or zone
file) in the DS digest. It terminates the digest at the first non-hex
character.

The venerable 'dig' tool emits DS digest type 2 with spaces:
powerdns.nl.            7200 &nb= sp;  IN      NS      powerdnssec2.ds9a.nl.
powerdns.nl.            7200 &nb= sp;  IN      NS      powerdnssec1.ds9a.nl.
powerdns.nl.            7200 &nb= sp;  IN      DS      7354 8 2
F238862D8DFCB5C837D33E28C0D318191DBA76FFC87C6F053D2AD67E 22BF1D7C

RFC 3658 says:

 'The presentation format of the DS record consists of three numbers  (key tag, algorithm, and digest type) followed by the digest itself<= br>  presented in hex'

It says nothing about spaces in the hex. Of course we could be liberal in what we accept, however, there is also the NSEC3 and NSEC3PARAM which store=
the salt.. in hex.

RFC5155 says:

       The Salt field is represented as a sequence of = case-insensitive
       hexadecimal digits.  Whitespace is not all= owed within the
       sequence.

Finally, SSHFP is the third type that encodes hex blobs, and RFC 4255
states:

  'The RDATA of the presentation format of the SSHFP resource record<= br>   consists of two numbers (algorithm and fingerprint type) followed b= y
  the fingerprint itself, presented in hex"

Sadly this breaks the nice symmetry where we had only one 'hexBlob', one that terminates at the first space.

Because 'dig' is so widely distributed, I'm afraid we'll have no choice but=
to butcher PowerDNS into dealing with the spaces, but what do people think?=
Do spaces belong in hex blobs, and in the DS specifically?

       Bert
_______________________________________________
dnsext mailing list
dnsex= t@ietf.org
= https://www.ietf.o= rg/mailman/listinfo/dnsext



--
Website: http://hallambake= r.com/

___________________= ____________________________
dnsext mailing list
= dnsext@ietf.org
https://www.ietf= .org/mailman/listinfo/dnsext
= --_000_6488638EBBC44DBFB127262BB4208275nominetorguk_-- From davidb@verisign.com Wed Jan 19 11:42:58 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282AA3A71A8 for ; Wed, 19 Jan 2011 11:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvZBOYnzYZ5u for ; Wed, 19 Jan 2011 11:42:57 -0800 (PST) Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by core3.amsl.com (Postfix) with ESMTP id 272693A71B9 for ; Wed, 19 Jan 2011 11:42:57 -0800 (PST) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p0JJfuLe030020; Wed, 19 Jan 2011 14:41:56 -0500 Received: from dul1dblacka-m2.vcorp.ad.vrsn.com ([10.131.29.13]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 14:45:35 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-15--668444561; protocol="application/pkcs7-signature"; micalg=sha1 From: David Blacka In-Reply-To: <20110119190346.GA13422@xs.powerdns.com> Date: Wed, 19 Jan 2011 14:45:35 -0500 Message-Id: <2B87697D-60FA-4035-9164-B3BD444D5DE9@verisign.com> References: <20110119190346.GA13422@xs.powerdns.com> To: bert hubert X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 19 Jan 2011 19:45:35.0530 (UTC) FILETIME=[70B8B8A0:01CBB811] Cc: dnsext@ietf.org Subject: Re: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:42:58 -0000 --Apple-Mail-15--668444561 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 19, 2011, at 2:03 PM, bert hubert wrote: > Hi everybody, >=20 > PowerDNSSEC turns out to be confused by spaces in the database (or = zone > file) in the DS digest. It terminates the digest at the first non-hex > character. >=20 > The venerable 'dig' tool emits DS digest type 2 with spaces: > powerdns.nl. 7200 IN NS powerdnssec2.ds9a.nl. > powerdns.nl. 7200 IN NS powerdnssec1.ds9a.nl. > powerdns.nl. 7200 IN DS 7354 8 2 > F238862D8DFCB5C837D33E28C0D318191DBA76FFC87C6F053D2AD67E 22BF1D7C >=20 > RFC 3658 says:=20 >=20 > 'The presentation format of the DS record consists of three numbers > (key tag, algorithm, and digest type) followed by the digest itself > presented in hex' >=20 > It says nothing about spaces in the hex. Of course we could be liberal = in > what we accept, however, there is also the NSEC3 and NSEC3PARAM which = store > the salt.. in hex. >=20 > RFC5155 says: >=20 > The Salt field is represented as a sequence of case-insensitive > hexadecimal digits. Whitespace is not allowed within the > sequence. The reason why whitespace wasn't allowed for the salt was to prevent = ambiguity in parsing the zone file format. The other records with blobs = can have whitespace without ambiguity because those records have a fixed = number of fields and the hex/base64 encoded field is last. Therefore a = parser can be reasonably expected to know that it is parsed the prior = two (e.g.) fields (which couldn't have whitespaces) and then conclude = that the rest of the record is the final field, whitespace and all. > Finally, SSHFP is the third type that encodes hex blobs, and RFC 4255 > states: >=20 > 'The RDATA of the presentation format of the SSHFP resource record > consists of two numbers (algorithm and fingerprint type) followed by > the fingerprint itself, presented in hex" >=20 > Sadly this breaks the nice symmetry where we had only one 'hexBlob', = one > that terminates at the first space. >=20 > Because 'dig' is so widely distributed, I'm afraid we'll have no = choice but > to butcher PowerDNS into dealing with the spaces, but what do people = think? > Do spaces belong in hex blobs, and in the DS specifically? "belong" isn't the correct term, "allowed" is. And spaces aren't = disallowed, thus are implicitly allowed. Thus, you have to deal with it = somehow. Sorry. -- David Blacka =20 Principal Engineer Verisign Platform Product Development --Apple-Mail-15--668444561 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcDCCBhow 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 rYgwfjsT08wUtdampqUUPcljHG4SzDCCBk4wggU2oAMCAQICEHA2PF81xBuwutVrTjzgsK0wDQYJ KoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNz IDIgRW1wbG95ZWUgQ0EgLSBHMzAeFw0xMDA0MTUwMDAwMDBaFw0xMTA0MTUwMDAwMDBaMGsxaTAQ BgNVBAsUCVZDT1JQIFVBUzAUBgNVBAMTDUJsYWNrYSwgRGF2aWQwHQYDVQQKFBZWZXJpU2lnbiBJ bmMuIFZDT1JQVUFTMCAGCSqGSIb3DQEJARYTZGF2aWRiQHZlcmlzaWduLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALZI7pt+S0lW25EIKZ2/LUTx2Q4pqP/3EHp060he2VselhTZ UaRSZOFxCzT8vSLs+po5PY4/c2dRX3ERY8L+/wrzvTa6QKHCE9QhHPGC3z/DClP3CMsQxWXvUrUM AkFV31zRsGsMzHlmT1LDfvVfbXrBKMc2QWj/fAdi5BrI6tMVdw8hdt9wyOySEAbRBFkFvYD9fXf8 O5NXlI+2i0bwf7f+EFYTdAbujNQ6afmXRqRCvnR1RglbdcgR3BQKTthSfadawSn63xlMH28knBi2 UvZoDjqL5XaBhHqsZzCmdBfj3HkIxF7oonSv46urooHco/6tjk+8mKcvapwi9Z1ocR8CAwEAAaOC AqYwggKiMAkGA1UdEwQCMAAwSAYDVR0RBEEwP4ETZGF2aWRiQHZlcmlzaWduLmNvbaAoBgorBgEE AYI3FAIDoBoMGGRhdmlkYkB2Y29ycC5hZC52cnNuLmNvbTAmBgkrBgEEAYI3FQcEGTAXBg9ghkgB hvhFAQ0EiGeB6AUCAWQCAQMwYQYDVR0fBFowWDBWoFSgUoZQaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vY2FfMzBlMmNkOGJhMjkzMDljYTAyMDJkMTVkNGJjZGYzZjAvTGF0ZXN0Q1JMLmNy bAAwggEGBgNVHSMEgf4wgfuAFNUflKY7btbbpLSxcKJ6iIpWIW8VoYHQpIHNMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQFzQC+mm3q9P0olYAouwpMDBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBEBgkqhkiG9w0BCQ8ENzA1 MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwDQYJ KoZIhvcNAQEFBQADggEBAAr+tpyZBAk7UyR3cFR0UysDA24YyKeIF/l5Z5S8AtkQLzY5NXGe2y7h wGl5VjtlfRXFPxUGrmHGKjXU3WE5GAkiw5DO0Iymnz2/+aviH5idTyC7WftvRrEraTlA16eUUjVe +RkyuSaylkomBmRzxXVbf5HU8L0K4x6z/mzROwSuEeInByCqvfkUpYOEaL+1+P9nrdJ1ifk2hPHX F3llzAFBUOcB56CECfAZkKPqKjYjJaorVqbkXKXlruKets4qQrGy8qwQKHXI4FCjzfQn/1bGOfnd Le68sffwnBIB3lYDyWvqk/vVcAVfMCldT2R+TK0VqDtTBAkp5+cTexI3KxYxggQCMIID/gIBATCB xTCBsDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwOTEqMCgGA1UEAxMhVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3ll ZSBDQSAtIEczAhBwNjxfNcQbsLrVa0484LCtMAkGBSsOAwIaBQCgggIRMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDExOTE5NDUzNVowIwYJKoZIhvcNAQkEMRYE FGREYtwM5D0eCsjoRhwebrZ27JxfMIHWBgkrBgEEAYI3EAQxgcgwgcUwgbAxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMwIQcDY8XzXE G7C61WtOPOCwrTCB2AYLKoZIhvcNAQkQAgsxgciggcUwgbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UE CxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxKjAo BgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMwIQcDY8XzXEG7C61WtOPOCw rTANBgkqhkiG9w0BAQEFAASCAQB8OOHc7qw+noGE546QKQcOeoo1K46Cn70sRc4M+UlhdB3Ccgy7 kuuIzFJtQsAWdsS3Zw0nhsTFKGwLtUlm8Lui1FWbln6XmyGiT/PRtCQcBeoDoyeShf+qAoJeA8zA U1bg6KpwDEWtCrzEOd96LSOkMssffSzqDKBPbphAlL9NaNXSQOHfV6SQBhNQenn6aLcpnKm8OGWJ GB+SqhVDaULnR1er5HoquR5tFY1vxluXkLirdmM6X5rN8Eqx/zCRStY2JjPXNDbykS3kqiKPqUgX njzyNQD+DYFWRrcYfw+afF3Qyi2IbXxCsYz5majySUBzm9z0qDdnPfNevUWSknbzAAAAAAAA --Apple-Mail-15--668444561-- From cet1@hermes.cam.ac.uk Wed Jan 19 11:51:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72EE83A6F54 for ; Wed, 19 Jan 2011 11:51:26 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV1iWEYQvgYA for ; Wed, 19 Jan 2011 11:51:25 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id 3D9923A7019 for ; Wed, 19 Jan 2011 11:51:25 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42412) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:cet1) id 1Pfe6T-0005zt-XO (Exim 4.72) (return-path ); Wed, 19 Jan 2011 19:54:01 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1Pfe6T-00022e-Av (Exim 4.67) (return-path ); Wed, 19 Jan 2011 19:54:01 +0000 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.3); 19 Jan 2011 19:54:01 +0000 Date: 19 Jan 2011 19:54:01 +0000 From: Chris Thompson To: "Jeremy C. Reed" Message-ID: In-Reply-To: References: <20110119190346.GA13422@xs.powerdns.com> X-Mailer: Prayer v1.3.3 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: dnsext@ietf.org, bert hubert Subject: Re: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:51:26 -0000 On Jan 19 2011, Jeremy C. Reed wrote: >3658 is obsoleted by 4033. RFC 4033 says "Whitespace is allowed within >the hexadecimal text." I think you mean 4034 (section 5.3, just before to the example in section 5.4 quoted by Tony Finch), but the same remark applies. -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From ahu@xs.powerdns.com Wed Jan 19 11:59:00 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330FA3A71B5 for ; Wed, 19 Jan 2011 11:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=1.230, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQTvIgLFsoOh for ; Wed, 19 Jan 2011 11:58:59 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by core3.amsl.com (Postfix) with ESMTP id CACBC3A7198 for ; Wed, 19 Jan 2011 11:58:58 -0800 (PST) Received: from ahu by xs.powerdns.com with local (Exim 4.69) (envelope-from ) id 1PfeDp-0004mm-OU; Wed, 19 Jan 2011 21:01:37 +0100 Date: Wed, 19 Jan 2011 21:01:37 +0100 From: bert hubert To: David Blacka Message-ID: <20110119200137.GA17580@xs.powerdns.com> References: <20110119190346.GA13422@xs.powerdns.com> <2B87697D-60FA-4035-9164-B3BD444D5DE9@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B87697D-60FA-4035-9164-B3BD444D5DE9@verisign.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:59:00 -0000 On Wed, Jan 19, 2011 at 02:45:35PM -0500, David Blacka wrote: > disallowed, thus are implicitly allowed. Thus, you have to deal with it > somehow. Sorry. Well, we got it - http://wiki.powerdns.com/trac/changeset/1900 However, I'd like to say that I find remarks that RFCs do not specify the representation format to be somewhat worrying. It smells of a cop out. If RFCs don't specify a canonical textual representation format, they are not as useful as they could be. Other posters remarked that DNS representations never hit the wire, but in reality this is very untrue. DNS in most large settings is not provisioned via 'vi' but via an API that fills out a backend. Such an API needs a representation too. I can understand that an RFC should not *mandate* a storage format, but it would be useful to specificy a 'canonical textual representation'. If only because people like to copy/paste dig output. Bert From davidb@verisign.com Wed Jan 19 12:07:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A2928C0CE for ; Wed, 19 Jan 2011 12:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vde66sjgk7zX for ; Wed, 19 Jan 2011 12:07:30 -0800 (PST) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id EADF83A7198 for ; Wed, 19 Jan 2011 12:07:29 -0800 (PST) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p0JK5cne007112; Wed, 19 Jan 2011 15:05:38 -0500 Received: from dul1dblacka-m2.vcorp.ad.vrsn.com ([10.131.29.13]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 15:10:10 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-17--666969933; protocol="application/pkcs7-signature"; micalg=sha1 From: David Blacka In-Reply-To: <20110119200137.GA17580@xs.powerdns.com> Date: Wed, 19 Jan 2011 15:10:09 -0500 Message-Id: <2E737793-1643-4D0B-BF05-89B46FA74EA7@verisign.com> References: <20110119190346.GA13422@xs.powerdns.com> <2B87697D-60FA-4035-9164-B3BD444D5DE9@verisign.com> <20110119200137.GA17580@xs.powerdns.com> To: "bert hubert" X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 19 Jan 2011 20:10:10.0484 (UTC) FILETIME=[DFDCD740:01CBB814] Cc: dnsext@ietf.org Subject: Re: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 20:07:31 -0000 --Apple-Mail-17--666969933 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 19, 2011, at 3:01 PM, bert hubert wrote: > On Wed, Jan 19, 2011 at 02:45:35PM -0500, David Blacka wrote: >> disallowed, thus are implicitly allowed. Thus, you have to deal with = it >> somehow. Sorry. >=20 > Well, we got it - http://wiki.powerdns.com/trac/changeset/1900 >=20 > However, I'd like to say that I find remarks that RFCs do not specify = the > representation format to be somewhat worrying. It smells of a cop out. My real point wasn't really about how the RFCs were written. It was = more on the order of "this behavior exists in the wild, so you have to = handle it." The idea that it wasn't disallowed by the RFC just means = you don't have a standards-based justification to not handle it. But, I was wrong. It isn't that whitespace was implicitly allowed. As = others who bother to look at the RFCs pointed out, it is explictly = allowed. -- David Blacka =20 Principal Engineer Verisign Platform Product Development --Apple-Mail-17--666969933 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMcDCCBhow 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 rYgwfjsT08wUtdampqUUPcljHG4SzDCCBk4wggU2oAMCAQICEHA2PF81xBuwutVrTjzgsK0wDQYJ KoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNz IDIgRW1wbG95ZWUgQ0EgLSBHMzAeFw0xMDA0MTUwMDAwMDBaFw0xMTA0MTUwMDAwMDBaMGsxaTAQ BgNVBAsUCVZDT1JQIFVBUzAUBgNVBAMTDUJsYWNrYSwgRGF2aWQwHQYDVQQKFBZWZXJpU2lnbiBJ bmMuIFZDT1JQVUFTMCAGCSqGSIb3DQEJARYTZGF2aWRiQHZlcmlzaWduLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALZI7pt+S0lW25EIKZ2/LUTx2Q4pqP/3EHp060he2VselhTZ UaRSZOFxCzT8vSLs+po5PY4/c2dRX3ERY8L+/wrzvTa6QKHCE9QhHPGC3z/DClP3CMsQxWXvUrUM AkFV31zRsGsMzHlmT1LDfvVfbXrBKMc2QWj/fAdi5BrI6tMVdw8hdt9wyOySEAbRBFkFvYD9fXf8 O5NXlI+2i0bwf7f+EFYTdAbujNQ6afmXRqRCvnR1RglbdcgR3BQKTthSfadawSn63xlMH28knBi2 UvZoDjqL5XaBhHqsZzCmdBfj3HkIxF7oonSv46urooHco/6tjk+8mKcvapwi9Z1ocR8CAwEAAaOC AqYwggKiMAkGA1UdEwQCMAAwSAYDVR0RBEEwP4ETZGF2aWRiQHZlcmlzaWduLmNvbaAoBgorBgEE AYI3FAIDoBoMGGRhdmlkYkB2Y29ycC5hZC52cnNuLmNvbTAmBgkrBgEEAYI3FQcEGTAXBg9ghkgB hvhFAQ0EiGeB6AUCAWQCAQMwYQYDVR0fBFowWDBWoFSgUoZQaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vY2FfMzBlMmNkOGJhMjkzMDljYTAyMDJkMTVkNGJjZGYzZjAvTGF0ZXN0Q1JMLmNy bAAwggEGBgNVHSMEgf4wgfuAFNUflKY7btbbpLSxcKJ6iIpWIW8VoYHQpIHNMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQFzQC+mm3q9P0olYAouwpMDBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBEBgkqhkiG9w0BCQ8ENzA1 MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwDQYJ KoZIhvcNAQEFBQADggEBAAr+tpyZBAk7UyR3cFR0UysDA24YyKeIF/l5Z5S8AtkQLzY5NXGe2y7h wGl5VjtlfRXFPxUGrmHGKjXU3WE5GAkiw5DO0Iymnz2/+aviH5idTyC7WftvRrEraTlA16eUUjVe +RkyuSaylkomBmRzxXVbf5HU8L0K4x6z/mzROwSuEeInByCqvfkUpYOEaL+1+P9nrdJ1ifk2hPHX F3llzAFBUOcB56CECfAZkKPqKjYjJaorVqbkXKXlruKets4qQrGy8qwQKHXI4FCjzfQn/1bGOfnd Le68sffwnBIB3lYDyWvqk/vVcAVfMCldT2R+TK0VqDtTBAkp5+cTexI3KxYxggQCMIID/gIBATCB xTCBsDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwOTEqMCgGA1UEAxMhVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3ll ZSBDQSAtIEczAhBwNjxfNcQbsLrVa0484LCtMAkGBSsOAwIaBQCgggIRMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDExOTIwMTAxMFowIwYJKoZIhvcNAQkEMRYE FIWo2lq5DYkCBv4tn1wqeTnj/9k8MIHWBgkrBgEEAYI3EAQxgcgwgcUwgbAxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMwIQcDY8XzXE G7C61WtOPOCwrTCB2AYLKoZIhvcNAQkQAgsxgciggcUwgbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UE CxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxKjAo BgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMwIQcDY8XzXEG7C61WtOPOCw rTANBgkqhkiG9w0BAQEFAASCAQAfRl6J8VYIhTXNMDk80F7JCRszuyNH0gXlP6RMMq8Z/cMrrD9Q Ne9W0uGBByGPkcc4qqdNnlKRHyp0ga3WZlef+r0CGFRbI2DAz7hholKHDWnVzsx/oe6bxSFr6tpW rx5bAzK/d21vUtXkoBxfboZpxoGw5oFSBTN2HBT+CzpCuoieO2maFaFpCsErFFtNHJAh6MzTtQOt xP2fiECgAtfmJMdxAfpCWW1ZmrEjK2qNM3i7phIXi89ibJTGQ6EbHSDcZeeU17fk0JAhj23l5m/T T7iVMWX82bQ/1gUwCUrbYpeOJ3gDRgwR5euezZQLGukf1hTdCMbRnVpU8gsTsZMaAAAAAAAA --Apple-Mail-17--666969933-- From brian.peter.dickson@gmail.com Wed Jan 19 12:15:53 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F1593A7060 for ; Wed, 19 Jan 2011 12:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.758 X-Spam-Level: X-Spam-Status: No, score=-2.758 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TDPlRA3yLro for ; Wed, 19 Jan 2011 12:15:52 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7877A3A71AF for ; Wed, 19 Jan 2011 12:15:52 -0800 (PST) Received: by fxm9 with SMTP id 9so1307713fxm.31 for ; Wed, 19 Jan 2011 12:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cwoLeET46wZSNFXyeM89BdR4KzB0O90cgmlTfzcArMw=; b=Rek4zUTCKtRg7XMX8/p4W+4sro93raOlWdmjZjAkfJBpekRYYR25jgonqE81yJdP5U WYNV7QPOZRgw1Qk/ZCVZexrZue+eaLmltB86RLA1zCdZtOdIRS7sPVpRpgqvTBqM356B hFfMuRDDh9U2D4DXg21XCXskULzArN/zIraxs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WnwKfIrK5TnhiYJQ5OehH+FYQLTdUY37mjt5Q7rR+lSTeX3B9k+pl3qlJE1xBcClYq oK4YRo+9iLTEMoSOEg9QoCHZFenoCQw6W4v9WWniNKehaX/l/q6Ud16Lx+UGrNXXDTbr sjljcm9DfEK9SJYajH1bwpEY9oKcBJmkiUaz4= MIME-Version: 1.0 Received: by 10.223.79.13 with SMTP id n13mr1185495fak.48.1295468312796; Wed, 19 Jan 2011 12:18:32 -0800 (PST) Received: by 10.223.111.142 with HTTP; Wed, 19 Jan 2011 12:18:32 -0800 (PST) In-Reply-To: <20110119190346.GA13422@xs.powerdns.com> References: <20110119190346.GA13422@xs.powerdns.com> Date: Wed, 19 Jan 2011 16:18:32 -0400 Message-ID: From: Brian Dickson To: bert hubert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 20:15:53 -0000 Hi, Bert, I'd say that whatever you do, if you are breaking up a "blob", you should stick by RFC 1035, and put it inside parentheses "()". The parentheses indicate that line breaks in the parentheses should be ignored; this could/should extend to whitespace as appropriate. Brian On Wed, Jan 19, 2011 at 3:03 PM, bert hubert wr= ote: > Hi everybody, > > PowerDNSSEC turns out to be confused by spaces in the database (or zone > file) in the DS digest. It terminates the digest at the first non-hex > character. > > The venerable 'dig' tool emits DS digest type 2 with spaces: > powerdns.nl. =A0 =A0 =A0 =A0 =A0 =A07200 =A0 =A0IN =A0 =A0 =A0NS =A0 =A0 = =A0powerdnssec2.ds9a.nl. > powerdns.nl. =A0 =A0 =A0 =A0 =A0 =A07200 =A0 =A0IN =A0 =A0 =A0NS =A0 =A0 = =A0powerdnssec1.ds9a.nl. > powerdns.nl. =A0 =A0 =A0 =A0 =A0 =A07200 =A0 =A0IN =A0 =A0 =A0DS =A0 =A0 = =A07354 8 2 > F238862D8DFCB5C837D33E28C0D318191DBA76FFC87C6F053D2AD67E 22BF1D7C > > RFC 3658 says: > > =A0'The presentation format of the DS record consists of three numbers > =A0(key tag, algorithm, and digest type) followed by the digest itself > =A0presented in hex' > > It says nothing about spaces in the hex. Of course we could be liberal in > what we accept, however, there is also the NSEC3 and NSEC3PARAM which sto= re > the salt.. in hex. > > RFC5155 says: > > =A0 =A0 =A0 =A0The Salt field is represented as a sequence of case-insens= itive > =A0 =A0 =A0 =A0hexadecimal digits. =A0Whitespace is not allowed within th= e > =A0 =A0 =A0 =A0sequence. > > Finally, SSHFP is the third type that encodes hex blobs, and RFC 4255 > states: > > =A0 'The RDATA of the presentation format of the SSHFP resource record > =A0 consists of two numbers (algorithm and fingerprint type) followed by > =A0 the fingerprint itself, presented in hex" > > Sadly this breaks the nice symmetry where we had only one 'hexBlob', one > that terminates at the first space. > > Because 'dig' is so widely distributed, I'm afraid we'll have no choice b= ut > to butcher PowerDNS into dealing with the spaces, but what do people thin= k? > Do spaces belong in hex blobs, and in the DS specifically? > > =A0 =A0 =A0 =A0Bert > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From marka@isc.org Wed Jan 19 13:38:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D347B28C11E for ; Wed, 19 Jan 2011 13:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UZZLFOk5rHh for ; Wed, 19 Jan 2011 13:38:34 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id EF65128C107 for ; Wed, 19 Jan 2011 13:38:33 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7F5155F9891; Wed, 19 Jan 2011 21:41:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 7E6B9E6030; Wed, 19 Jan 2011 21:40:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 19D69900F1A; Thu, 20 Jan 2011 08:40:55 +1100 (EST) To: Brian Dickson From: Mark Andrews References: <20110119190346.GA13422@xs.powerdns.com> In-reply-to: Your message of "Wed, 19 Jan 2011 16:18:32 EDT." Date: Thu, 20 Jan 2011 08:40:55 +1100 Message-Id: <20110119214055.19D69900F1A@drugs.dv.isc.org> Cc: dnsext@ietf.org, bert hubert Subject: Re: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 21:38:34 -0000 In message , Bria n Dickson writes: > Hi, Bert, > > I'd say that whatever you do, if you are breaking up a "blob", you > should stick by RFC 1035, and put it inside parentheses "()". > > The parentheses indicate that line breaks in the parentheses should be > ignored; this could/should extend to whitespace as appropriate. No. We should not change the meaning of parentheses. As for masterfile format. It is standardised interchange format and all nameserver packages SHOULD be able to read it. There is no requirement to use it internally. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_hare@lavabit.com Wed Jan 19 16:36:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4118B28C13B for ; Wed, 19 Jan 2011 16:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOqT76UDETZW for ; Wed, 19 Jan 2011 16:36:28 -0800 (PST) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by core3.amsl.com (Postfix) with ESMTP id 44E8828C12A for ; Wed, 19 Jan 2011 16:36:28 -0800 (PST) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id AEBCD11B850 for ; Wed, 19 Jan 2011 18:39:09 -0600 (CST) Received: from lavabit.com (cpc10-watf10-2-0-cust121.15-2.cable.virginmedia.com [86.19.224.122]) by lavabit.com with ESMTP id Z05DGLHDOMT6 for ; Wed, 19 Jan 2011 18:39:09 -0600 Received: from 86.19.224.122 (SquirrelMail authenticated user hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_r ama_hare_hare@lavabit.com) by lavabit.com with HTTP; Wed, 19 Jan 2011 19:39:09 -0500 (EST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=g2BsNM+/cXlF2c/SJsWNf0bvQvg7FfeqOzvR7D29X20dg/7d/LAL8JUyMxe5r+Z/+RDz8MnVKdQM1pOqTkWdb8w4CkDnXF1s/A8Fs9DPs8iEj0iFryi6HE07bYjb49tBOApFBGV4PrWdfx6egTwH13zN6YAsQP4gDM2x0Cir1s8=; h=Message-ID:Date:Subject:From:To:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; Message-ID: <33236.86.19.224.122.1295483949.squirrel@lavabit.com> Date: Wed, 19 Jan 2011 19:39:09 -0500 (EST) From: hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_hare@lavabit.com To: dnsext@ietf.org User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [dnsext] Increasing character limit for registration in internet domain names: 76 or 68 or 91 or 83 or 64 higher the better X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 07:18:56 -0000 (this is mailing list email from Meeकu who started this thread. I am sending this email to prove that some free email services (very few at this time) allow big email addresses.) Certain member participation web services that have increased character length feature built-in are few at this time. E.g. Email hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_hare -at- lavabit.com E.g. Website http://sites.google.com/site/36o1o8/hare/krsna/hare/krsna/krsna/krsna/hare/hare/hare/rama/hare/rama/rama/rama/hare/hare Finding a free website service that allows big subdomains to the left of the @ (at) sign for free website is proving to be difficult. Best, Meeकu From hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_hare@lavabit.com Thu Jan 20 13:00:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C94CE3A683D for ; Thu, 20 Jan 2011 13:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECMbQ271yomb for ; Thu, 20 Jan 2011 13:00:30 -0800 (PST) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by core3.amsl.com (Postfix) with ESMTP id 8941B3A6827 for ; Thu, 20 Jan 2011 13:00:30 -0800 (PST) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 4EBBC11B962; Thu, 20 Jan 2011 15:03:14 -0600 (CST) Received: from lavabit.com (cpc10-watf10-2-0-cust121.15-2.cable.virginmedia.com [86.19.224.122]) by lavabit.com with ESMTP id TVE5QAKGAILL; Thu, 20 Jan 2011 15:03:14 -0600 Received: from 86.19.224.122 (SquirrelMail authenticated user hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_r ama_hare_hare@lavabit.com) by lavabit.com with HTTP; Thu, 20 Jan 2011 16:03:14 -0500 (EST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=Bbvvrftt+mlbBxtBJMikq0ig2dn/QNmetBRGDhut7Xkzs3w4NwgRf1+SCDvszYswu1PssPijVy7iyJRCXlQ3bwBJet9ltIRccgD0VdobSiPiLDXUpgYN9uMYmHRlDVOY+aRp7mhEUPkN2phluZiv4r2RsMwdt/sQAJyEsMxFlyU=; h=Message-ID:In-Reply-To:References:Date:Subject:From:To:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; Message-ID: <52627.86.19.224.122.1295557394.squirrel@lavabit.com> In-Reply-To: <201101201421.19216.plewis@aur.archlinux.org> References: <40546.86.19.224.122.1295516412.squirrel@lavabit.com> <201101201421.19216.plewis@aur.archlinux.org> Date: Thu, 20 Jan 2011 16:03:14 -0500 (EST) From: hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_hare@lavabit.com To: "General Discussion about Arch Linux" , dnsext@ietf.org User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [dnsext] [arch-general] Rail Model font for coders X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 21:00:31 -0000 > Heh - but that is one cool email address. Meeku: Nice thought and grateful for your words. hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_hare is the Mahamantra, the great chant for deliverance in this Age. When I searched for a free webmail service, it was not easy to find webmail allowing big character numbers as most free webmail providers allow only small character numbers at this time. It has some relation/bearing to the small character numbers 'rule' (63 characters) allowed for internet domain names which don't allow the Mahamantra character numbers (68 or 91 or 83 or 64). Thus this practise of not allowing big email addresses has developed in the internet sector. It could be said that this is unwritten IETF led being used by others in the 'trade'. I have requested on the IETF mailing list/s that the existing internet domain names character number be extended from 63 characters to more at least 76 or 68 or 91 or 83 or 64, the higher it is the better for the Mahamantra character numbers at least: http://www.ietf.org/mail-archive/web/dnsext/current/msg10342.html From iesg-secretary@ietf.org Fri Jan 21 11:03:34 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315393A6A86; Fri, 21 Jan 2011 11:03:34 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI2TI07+u8WD; Fri, 21 Jan 2011 11:03:33 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2023A6A87; Fri, 21 Jan 2011 11:03:33 -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.10 Message-ID: <20110121190333.32696.91842.idtracker@localhost> Date: Fri, 21 Jan 2011 11:03:33 -0800 Cc: dnsext chair , Internet Architecture Board , dnsext mailing list , RFC Editor Subject: [dnsext] Protocol Action: 'Domain Name System (DNS) IANA Considerations' to BCP (draft-ietf-dnsext-5395bis-03.txt) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 19:03:34 -0000 The IESG has approved the following document: - 'Domain Name System (DNS) IANA Considerations' (draft-ietf-dnsext-5395bis-03.txt) as a BCP This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-5395bis/ Technical Summary This RFC obsoletes [RFC5395]; however, the only significant change is the change is the public review mailing list to dnsext@ietf.org. Working Group Summary There were no comments during an abbreviated working group last call. Document Quality The only significant action in this document is to change the public review mailing list to dnsext@ietf.org Personnel Olafur Gudmundsson (ogud@ogud.com) is the document shepherd. Ralph Droms (rdroms.ietf@gmail.com) is the responsible AD. From Francis.Dupont@fdupont.fr Fri Jan 21 11:28:59 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CE83A6A8D for ; Fri, 21 Jan 2011 11:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyRPBif57JhT for ; Fri, 21 Jan 2011 11:28:58 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id E04D23A67B8 for ; Fri, 21 Jan 2011 11:28:57 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p0LJVipg035741; Fri, 21 Jan 2011 20:31:44 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101211931.p0LJVipg035741@givry.fdupont.fr> From: Francis Dupont To: bert hubert In-reply-to: Your message of Wed, 19 Jan 2011 20:03:46 +0100. <20110119190346.GA13422@xs.powerdns.com> Date: Fri, 21 Jan 2011 20:31:44 +0100 Sender: Francis.Dupont@fdupont.fr Cc: dnsext@ietf.org Subject: Re: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 19:28:59 -0000 IMHO it is a problem of length, i.e., if the hex digest can be long then one should be allowed to cut it to make it more readable. Of course this includes spaces. Note this argument applies only to DS, not to NSEC3 salt which is BTW not the last field, i.e., a space makes the RR ambiguous. About SSHFP I think it should be handled in same way than DS. Regards Francis.Dupont@fdupont.fr From prvs=000347a12d=namedroppers+phil@spodhuis.org Fri Jan 21 17:09:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466FB28C0DC for ; Fri, 21 Jan 2011 17:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em4r2HKjKoKI for ; Fri, 21 Jan 2011 17:09:47 -0800 (PST) Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) by core3.amsl.com (Postfix) with ESMTP id D7E9228B797 for ; Fri, 21 Jan 2011 17:09:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d200912; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=lPmxfRmUUvWkrHSVBGfvOUyIMWCKvmUQhXOHZ3q1J9w=; b=xSGPcwDu6xzEgSUVGmkUKYezxBVnGGu3CrEusF/egWyk0hLPaGEdMafMIxcRr3YxGmkWZNkCfzPETToUjzlkDxRGASJCWVDhqGeD5T7Qf6D8mSKsbt0T8ZourG7o6k2G0SfBgG3kgS8EHeEnD76ziNkdKI1uJjQ5C8CfjMoRSwQ=; Received: by smtp.spodhuis.org with local id 1PgS1o-00006Q-Fs; Sat, 22 Jan 2011 01:12:32 +0000 Date: Fri, 21 Jan 2011 20:12:32 -0500 From: Phil Pennock To: dnsext@ietf.org Message-ID: <20110122011232.GA117@redoubt.spodhuis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [dnsext] Compression labels & rrtype partitioning X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Jan 2011 01:09:48 -0000 My understanding is that the biggest problem with introducing new RRTYPEs that contain names is that existing resolvers won't know to use compression for the names and so libraries for applications to use do not expose decent interfaces and it's hard to provide validation and inspection for data with such new types. So we get left with people using existing RRs with special resource names in DNS, co-opting part of the namespace. If the standard changes to fix this, then existing resolvers won't handle it, but if nothing changes then we're stuck with a broken situation forever and just a lot of unproductive acrimony between those just wanting to get a product out and those wanting to keep a clean system. If we make a change, then it will take a while to percolate out, but a sufficiently simple change stands a strong chance of being adopted by the resolvers and as the years go by, it will become easier for people to do The Right Thing, adding a new rrtype which uses label compression. I'll emphasise that this is entirely about rules for new allocations, to make them easier to support, and absolutely NOT about any kind of renumbering for existing allocations. So, flaky proposal 1 for people to consider: RRTYPE 0x8000 - 0x8FFF SHALL be used only for records where the RDATA consists entirely of a DNS name, with compression semantics. Resolvers may evaluate ((rrtype & 0xF000) == 0x8000) and for all matching RRTYPEs apply this rule. New RRTYPE allocation where the data is a DNS name SHOULD be assigned from this range. Resolvers which do not follow this specification will not be any worse off than they already are, so no harm done. As an experiment, this buys 4096 values which have clear semantics and let us figure out if this is useful. If more space is needed, the mask can be adjusted to expand the assignment range and we should know in plenty of time if this is proving likely to ever be needed. If the experiment fails, it's "only" 1/16th of the space wasted. Then, flaky proposal 2 for consideration: RRTYPE 0xC000 - 0xCFFF SHALL only be used for records where a trailing portion of the RDATA consists of a DNS name, with compression semantics. The second octet SHALL encode how many leading octets of the RDATA are non-NAME binary data not subject to encoding. The third and fourth octets shall provide the option space. Thus the 0xC0hh range is equivalent to 0x8hhh in semantics; a new record with the same layout as an SRV record would be assigned an RRTYPE from the 0xC6hh range, as 6 leading octets of the RDATA would be for Priority, Weight and Port, at 2 octets each, with the rest of the RDATA payload being subject to compression semantics. Again, resolvers which don't follow this specification will not be any worse off than they already are. This "only" buys us 256 RRTYPEs for each layout, but again at a cost of only 1/16th of the option space. Both proposals together use 1/8th of the option space; current assignments are consuming less than 1/256th of the option space, so this does not appear to be dangerous. Is this sufficiently non-crazy that it's worth putting together a draft? Constructive feedback welcome, -Phil From marka@isc.org Fri Jan 21 18:43:31 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3BE3A68E5 for ; Fri, 21 Jan 2011 18:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-7hh4zDOqcE for ; Fri, 21 Jan 2011 18:43:30 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 696643A6896 for ; Fri, 21 Jan 2011 18:43:30 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id A821CC941E; Sat, 22 Jan 2011 02:46:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 4BC5BE6030; Sat, 22 Jan 2011 02:46:06 +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 0ED079139AB; Sat, 22 Jan 2011 13:46:04 +1100 (EST) To: Phil Pennock From: Mark Andrews References: <20110122011232.GA117@redoubt.spodhuis.org> In-reply-to: Your message of "Fri, 21 Jan 2011 20:12:32 CDT." <20110122011232.GA117@redoubt.spodhuis.org> Date: Sat, 22 Jan 2011 13:46:03 +1100 Message-Id: <20110122024604.0ED079139AB@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Compression labels & rrtype partitioning X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Jan 2011 02:43:31 -0000 In message <20110122011232.GA117@redoubt.spodhuis.org>, Phil Pennock writes: > My understanding is that the biggest problem with introducing new > RRTYPEs that contain names is that existing resolvers won't know to use > compression for the names and so libraries for applications to use do > not expose decent interfaces and it's hard to provide validation and > inspection for data with such new types. No. The biggest problem is people not applying for types. The nameservers will handle them. The resolvers will handle them. The applications will handle them. We realised a decade ago that compression of new types doesn't work without signalling and even if you have signaling you need to do lossless compression by preserving case. As a consequence compression is banned in all new types. There is a short list of types where compression is allowed. We can always add hop-by-hop signalling in the future if we want to but there really isn't any need to. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@iecc.com Fri Jan 21 20:04:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565B73A6ABE for ; Fri, 21 Jan 2011 20:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.607 X-Spam-Level: X-Spam-Status: No, score=-110.607 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ma-OUFLLFOS for ; Fri, 21 Jan 2011 20:04:10 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 1A4C33A6AA7 for ; Fri, 21 Jan 2011 20:04:09 -0800 (PST) Received: (qmail 11001 invoked from network); 22 Jan 2011 04:06:57 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 22 Jan 2011 04:06:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=1312d.4d3a57e1.k1101; i=johnl@user.iecc.com; bh=XneE0DoPwaih8a6LA7yEHL0rFBwh2Q9xbGA9UWmTco8=; b=AfgrCc6Ulfj/pZdIwvK3G1MtYa3MUiNVl/rz71/XqYXctjkrK1Ne87FCg0ckkIjUUkIIxr+u/cjR2qwcAMrdyqNcU7Z94o7dUtohhBGxzZOjDaPT1xo9c7MUU2k1yxwOXDpCcEZJMsi+SneRSd8rbSoYNT/XRWUJ8sNZCoH96X8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 22 Jan 2011 04:06:57 -0000 Message-ID: <20110122040657.78124.qmail@joyce.lan> From: John Levine To: dnsext@ietf.org In-Reply-To: <20110122024604.0ED079139AB@drugs.dv.isc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Compression labels & rrtype partitioning X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Jan 2011 04:04:11 -0000 >No. The biggest problem is people not applying for types. The >nameservers will handle them. The resolvers will handle them. The >applications will handle them. Partly that, partly the provisioning systems. Even if your copy of BIND is ready to support a new RR type, you still can't do it if your user friendly web front end doesn't let you create the new records. When we were setting up DKIM, I was surprised how much trouble people had adding TXT records with underscores in the names, because cruddy provisioning systems "knew" you weren't supposed to do that. R's, John From marka@isc.org Sat Jan 22 04:31:53 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35C7D3A68F1 for ; Sat, 22 Jan 2011 04:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuQpIjCN4ZCW for ; Sat, 22 Jan 2011 04:31:52 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 4CCA73A6862 for ; Sat, 22 Jan 2011 04:31:52 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id C6D26C9422; Sat, 22 Jan 2011 12:34:28 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 695C9E60B3; Sat, 22 Jan 2011 12:34:28 +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 4340191440D; Sat, 22 Jan 2011 23:34:24 +1100 (EST) To: John Levine From: Mark Andrews References: <20110122040657.78124.qmail@joyce.lan> In-reply-to: Your message of "22 Jan 2011 04:06:57 -0000." <20110122040657.78124.qmail@joyce.lan> Date: Sat, 22 Jan 2011 23:34:24 +1100 Message-Id: <20110122123424.4340191440D@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Compression labels & rrtype partitioning X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 22 Jan 2011 12:31:53 -0000 In message <20110122040657.78124.qmail@joyce.lan>, John Levine writes: > >No. The biggest problem is people not applying for types. The > >nameservers will handle them. The resolvers will handle them. The > >applications will handle them. > > Partly that, partly the provisioning systems. Even if your copy of > BIND is ready to support a new RR type, you still can't do it if your > user friendly web front end doesn't let you create the new records. Well complain to the administrators of the front end. There has been as standardised representation for unknown records for nearly a decade now. > When we were setting up DKIM, I was surprised how much trouble people > had adding TXT records with underscores in the names, because cruddy > provisioning systems "knew" you weren't supposed to do that. > > R's, > John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Miek.Gieben@sidn.nl Mon Jan 24 06:06:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164333A6AC9 for ; Mon, 24 Jan 2011 06:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZXUxA+8QlOi for ; Mon, 24 Jan 2011 06:06:41 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by core3.amsl.com (Postfix) with ESMTP id 150AC3A6ACB for ; Mon, 24 Jan 2011 06:06:40 -0800 (PST) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p0OE9YJr013955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Mon, 24 Jan 2011 15:09:34 +0100 Received: from login.sidn.nl (94.198.155.36) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server id 14.0.702.0; Mon, 24 Jan 2011 15:09:34 +0100 Date: Mon, 24 Jan 2011 15:09:33 +0100 From: Miek Gieben To: dnsext List Message-ID: <20110124140933.GA12071@login.sidn.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Vim/Mutt/Linux Subject: [dnsext] nsec3 and wildcards X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jan 2011 14:07:31 -0000 Hello, I was wondering if there was a way to limit the amount of nsec3s that are returned for name-error responses. Right now, one of the nsec3s is there to signal that there is no wildcard present. Would it be possible to use the flags field (in the remaining nsec3s) to signal 'oh, and btw, there also wasn't a wildcard'? Somehow this shouldn't work, but I cannot see why... Kind regards, -- Miek From Ed.Lewis@neustar.biz Mon Jan 24 06:21:51 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFE473A68E3 for ; Mon, 24 Jan 2011 06:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.042 X-Spam-Level: X-Spam-Status: No, score=-101.042 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_20=-0.74, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfhTrFZ54ETM for ; Mon, 24 Jan 2011 06:21:51 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id F0AEC3A68ED for ; Mon, 24 Jan 2011 06:21:50 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0OEOc2N047061; Mon, 24 Jan 2011 09:24:38 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.112] by Work-Laptop-2.local (PGP Universal service); Mon, 24 Jan 2011 09:24:44 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 24 Jan 2011 09:24:44 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110124140933.GA12071@login.sidn.nl> References: <20110124140933.GA12071@login.sidn.nl> Date: Mon, 24 Jan 2011 09:24:36 -0500 To: Miek Gieben From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext List Subject: Re: [dnsext] nsec3 and wildcards X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jan 2011 14:21:52 -0000 At 15:09 +0100 1/24/11, Miek Gieben wrote: >Hello, > >I was wondering if there was a way to limit the amount of nsec3s that >are returned for name-error responses. Right now, one of the nsec3s is there >to signal that there is no wildcard present. > >Would it be possible to use the flags field (in the remaining nsec3s) to >signal 'oh, and btw, there also wasn't a wildcard'? > >Somehow this shouldn't work, but I cannot see why... Hey Miek, long time, no hear.... The top limit is 3 now (no more than 3 nsec3's per response). And if a nsec3 can prove more than one "point" the number will be less. I say this to estimate if this endeavor would be worth it. The problem with using a flag for this is... ...if a wildcard is added to the zone, all NSEC3's in place would have to be changed (and signed and all this propagated). ...a cached NSEC3 could be misleading. (I'm just saying, cached data could always be out of date.) ...we don't have a flags field now, so we'd be "borrowing" from the type-bit map. So servers would have to know about this special processing. (Since an authority server doesn't know how "old" a cache is, the authority won't know when to add the bit and not send the 3rd NSEC3, etc...) Just some thoughts.... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 With a week old newborn at home, I've discovered that the only difference between him and me is that I have to go to work daily. That's not fair! Ma! From Miek.Gieben@sidn.nl Mon Jan 24 06:29:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ADEB3A68F1 for ; Mon, 24 Jan 2011 06:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeeZKUMcbR6u for ; Mon, 24 Jan 2011 06:29:51 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by core3.amsl.com (Postfix) with ESMTP id 164BF3A68E6 for ; Mon, 24 Jan 2011 06:29:50 -0800 (PST) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p0OEWj8o014437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Mon, 24 Jan 2011 15:32:45 +0100 Received: from login.sidn.nl (94.198.155.36) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server id 14.0.702.0; Mon, 24 Jan 2011 15:32:45 +0100 Date: Mon, 24 Jan 2011 15:32:45 +0100 From: Miek Gieben To: dnsext List Message-ID: <20110124143245.GA12521@login.sidn.nl> Mail-Followup-To: dnsext List References: <20110124140933.GA12071@login.sidn.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux Subject: Re: [dnsext] nsec3 and wildcards X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jan 2011 14:29:52 -0000 [ Quoting Edward Lewis in "Re: [dnsext] nsec3 and wildcards"... ] > >Would it be possible to use the flags field (in the remaining nsec3s) to > >signal 'oh, and btw, there also wasn't a wildcard'? > > > >Somehow this shouldn't work, but I cannot see why... > > Hey Miek, long time, no hear.... yes, I'm sort of back in the DNS game :-) > The top limit is 3 now (no more than 3 nsec3's per response). And > if a nsec3 can prove more than one "point" the number will be less. > I say this to estimate if this endeavor would be worth it. > > The problem with using a flag for this is... > > ...if a wildcard is added to the zone, all NSEC3's in place would > have to be changed (and signed and all this propagated). > > ...a cached NSEC3 could be misleading. (I'm just saying, cached > data could always be out of date.) > > ...we don't have a flags field now, so we'd be "borrowing" from the > type-bit map. So servers would have to know about this special > processing. (Since an authority server doesn't know how "old" a > cache is, the authority won't know when to add the bit and not send > the 3rd NSEC3, etc...) > > Just some thoughts.... Correct me if I'm mistaken, but there is a flag field, RFC 5155: 3.1.2. Flags The Flags field contains 8 one-bit flags that can be used to indicate different processing. All undefined flags must be zero. The only flag defined by this specification is the Opt-Out flag. We do have to define a *new* flag. grtz, Miek From Ed.Lewis@neustar.biz Mon Jan 24 06:48:57 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE723A68E9 for ; Mon, 24 Jan 2011 06:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0+mZaC5qNUO for ; Mon, 24 Jan 2011 06:48:57 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D6D8A3A68E3 for ; Mon, 24 Jan 2011 06:48:56 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0OEpipT047238; Mon, 24 Jan 2011 09:51:44 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.112] by Work-Laptop-2.local (PGP Universal service); Mon, 24 Jan 2011 09:51:51 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 24 Jan 2011 09:51:51 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110124143245.GA12521@login.sidn.nl> References: <20110124140933.GA12071@login.sidn.nl> <20110124143245.GA12521@login.sidn.nl> Date: Mon, 24 Jan 2011 09:51:39 -0500 To: Miek Gieben From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext List Subject: Re: [dnsext] nsec3 and wildcards X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jan 2011 14:48:58 -0000 At 15:32 +0100 1/24/11, Miek Gieben wrote: >Correct me if I'm mistaken, but there is a flag field, RFC 5155: > >3.1.2. Flags > > The Flags field contains 8 one-bit flags that can be used to indicate > different processing. All undefined flags must be zero. The only > flag defined by this specification is the Opt-Out flag. > >We do have to define a *new* flag. Ah, I'd forgotten. But you still have the issue of an upgraded server not knowing if the requestor understands the flag so the extra NSEC3 is still needed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 With a week old newborn at home, I've discovered that the only difference between him and me is that I have to go to work daily. That's not fair! Ma! From miekg@atoom.net Mon Jan 24 07:04:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4C7D3A68E5 for ; Mon, 24 Jan 2011 07:04:01 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZPYAoXAZoHN for ; Mon, 24 Jan 2011 07:04:01 -0800 (PST) Received: from elektron.atoom.net (124-71-223.ftth.xms.internl.net [85.223.71.124]) by core3.amsl.com (Postfix) with ESMTP id E6D7B3A68D5 for ; Mon, 24 Jan 2011 07:04:00 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id 972603FEE9; Mon, 24 Jan 2011 16:06:54 +0100 (CET) Date: Mon, 24 Jan 2011 16:06:54 +0100 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20110124150654.GA22802@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <20110124140933.GA12071@login.sidn.nl> <20110124143245.GA12521@login.sidn.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl Subject: Re: [dnsext] nsec3 and wildcards X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jan 2011 15:04:01 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting Edward Lewis in "Re: [dnsext] nsec3 and wildcards"... ] > But you still have the issue of an upgraded server not knowing if > the requestor understands the flag so the extra NSEC3 is still > needed. True.=20 But to come back to my original question: Would it be possible to use the flags field (in the remaining nsec3s) to signal 'oh, and btw, there also wasn't a wildcard'? You are not denying that this could work...? grtz, Miek --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk09lY4ACgkQJYuFzziA0PbAPQCfXubDtc37vw6pVrnEnqVHpKWj Vi0An2QFp0/LU2wA8EJbGHgX5RveQTkV =d0ob -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From george.barwood@blueyonder.co.uk Mon Jan 24 07:04:27 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793A83A68EA for ; Mon, 24 Jan 2011 07:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, J_CHICKENPOX_41=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phFbRCE8eboM for ; Mon, 24 Jan 2011 07:04:26 -0800 (PST) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by core3.amsl.com (Postfix) with ESMTP id 778CD3A68D5 for ; Mon, 24 Jan 2011 07:04:26 -0800 (PST) Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1PhO0m-00069l-BT; Mon, 24 Jan 2011 15:07:20 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PhO0M-00070Y-J9; Mon, 24 Jan 2011 15:06:54 +0000 Message-ID: <5EB68CBF1ECE4B0E823C58C1EA540B2C@local> From: "George Barwood" To: "Miek Gieben" , "dnsext List" References: <20110124140933.GA12071@login.sidn.nl> Date: Mon, 24 Jan 2011 15:07:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: Re: [dnsext] nsec3 and wildcards X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jan 2011 15:04:27 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1pZWsgR2llYmVuIiA8bWll ay5naWViZW5Ac2lkbi5ubD4NClRvOiAiZG5zZXh0IExpc3QiIDxkbnNleHRAaWV0Zi5vcmc+DQpT ZW50OiBNb25kYXksIEphbnVhcnkgMjQsIDIwMTEgMjowOSBQTQ0KU3ViamVjdDogW2Ruc2V4dF0g bnNlYzMgYW5kIHdpbGRjYXJkcw0KDQoNCj4gSGVsbG8sDQo+IA0KPiBJIHdhcyB3b25kZXJpbmcg aWYgdGhlcmUgd2FzIGEgd2F5IHRvIGxpbWl0IHRoZSBhbW91bnQgb2YgbnNlYzNzIHRoYXQNCj4g YXJlIHJldHVybmVkIGZvciBuYW1lLWVycm9yIHJlc3BvbnNlcy4gUmlnaHQgbm93LCBvbmUgb2Yg dGhlIG5zZWMzcyBpcyB0aGVyZQ0KPiB0byBzaWduYWwgdGhhdCB0aGVyZSBpcyBubyB3aWxkY2Fy ZCBwcmVzZW50Lg0KPiANCj4gV291bGQgaXQgYmUgcG9zc2libGUgdG8gdXNlIHRoZSBmbGFncyBm aWVsZCAoaW4gdGhlIHJlbWFpbmluZyBuc2VjM3MpIHRvDQo+IHNpZ25hbCAnb2gsIGFuZCBidHcs IHRoZXJlIGFsc28gd2Fzbid0IGEgd2lsZGNhcmQnPw0KPiANCj4gU29tZWhvdyB0aGlzIHNob3Vs ZG4ndCB3b3JrLCBidXQgSSBjYW5ub3Qgc2VlIHdoeS4uLg0KDQpXZWxsIHRoZSBxdWVzdGlvbiB3 b3VsZCBiZSAid2hhdCB3aWxkY2FyZCI/DQoNClJlbWVtYmVyIHRoZXJlIGFyZSBhIChwcmFjdGlj YWxseSkgdW5saW1pdGVkIG51bWJlciBvZiBxdWVyaWVzLCB3aGljaCB0aGUgc2VydmVyIGFuc3dl cnMNCnVzaW5nIGEgcmVsYXRpdmVseSBzbWFsbCBudW1iZXIgb2Ygc2lnbmVkIHJlY29yZHMuIFRo ZSBkZXNpZ24gIGNob2ljZSB3YXMgdG8gbWluaW1pc2UgdGhlIG51bWJlciBvZiBSUnNldHMNCnRo YXQgaGF2ZSB0byBiZSBzaWduZWQuIEl0IG1pZ2h0IGhhdmUgYmVlbiBwb3NzaWJsZSB0byBoYXZl IGEgZGlmZmVyZW50IGRlc2lnbiB3aXRoIGEgbGFyZ2VyIG51bWJlcg0Kb2YgdGhpbmdzIHRvIGJl IHNpZ25lZCBidXQgc21hbGxlciByZXNwb25zZXMgKCB3aXRoIGxlc3Mgc2lnbmF0dXJlcyApLg0K DQpSZWdhcmRzLA0KR2VvcmdlDQoNCj4gS2luZCByZWdhcmRzLA0KPiANCj4gLS0NCj4gTWllaw0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkbnNl eHQgbWFpbGluZyBsaXN0DQo+IGRuc2V4dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Ruc2V4dA== From paul@xelerance.com Tue Jan 25 09:50:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28B43A6825 for ; Tue, 25 Jan 2011 09:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGnlGeQ7ZfLP for ; Tue, 25 Jan 2011 09:50:15 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 379173A680E for ; Tue, 25 Jan 2011 09:50:15 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 0A78AC535 for ; Tue, 25 Jan 2011 12:53:12 -0500 (EST) Date: Tue, 25 Jan 2011 12:53:11 -0500 (EST) From: Paul Wouters To: dnsext List Message-ID: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jan 2011 17:50:17 -0000 A very large router vendor is about to make it mandatory that new devices they produce use dnssec by default. One issue that comes up with that is what happens if these devices were off long enough for a rollover to have happened and the RFC5011 bit/key has been retired. Are there plans to create a zone with all old root keys, that all sign the DNSKEY RRset (eg rootkeys.root-servers.net) so that having ANY one old root key could lead you to get a signed version of the latest root key? This way you could disable DNSSEC to resolve rootkeys.root-servers.net, use your current key to confirm the latest key, configure it, and drop the cache, and you're golden. Is something like this even possible? I'm not sure what happens to the root private keys once they are retired... Paul From stephan.lagerholm@secure64.com Tue Jan 25 09:59:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9523A687A for ; Tue, 25 Jan 2011 09:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fEWaSKA2xvP for ; Tue, 25 Jan 2011 09:59:04 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by core3.amsl.com (Postfix) with ESMTP id 1A2CF3A683E for ; Tue, 25 Jan 2011 09:59:04 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 84AC5B8318; Tue, 25 Jan 2011 10:56:58 -0700 (MST) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDXsJBIHppcG; Tue, 25 Jan 2011 10:56:58 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 06593B82D0; Tue, 25 Jan 2011 10:56:58 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1295978218; bh=LIzLcyKxiCwH7EokpvecLRdqehKbmkdAcyUPfn3g0nM=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To; b=f+c+reVSxfgk62748gMhu xiy3Zz0EZE8jkrLLYXZqwMOwvCUrA2jHFIIJw2eJ4DqMzZTf2jCq6iGFbaneT1om57d b0xUovJjer2VwvCT8amqvktxEJVHFchwRqlftMOD4jpB94K+3+PS5iXm0n4KLzeyS9m WiHixpM6Va7mbbbQ= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jan 2011 11:01:58 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] historal root keys for upgrade path? Thread-Index: Acu8uKFlHXAvzR3bSr+5dw+T1d7IAwAARHGg References: From: "Stephan Lagerholm" To: "Paul Wouters" , "dnsext List" Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jan 2011 17:59:05 -0000 Paul, See: draft-wijngaards-dnsop-trust-history-02 Abstract: When DNS validators have trusted keys, but have been offline for a longer period, key rollover will fail and they are stuck with stale trust anchors. History service allows validators to query for older DNSKEY RRsets and pick up the rollover trail where they left off. /S ---------------------------------------------------------------------- Stephan Lagerholm Senior DNS Architect, M.Sc. ,CISSP Secure64 Software Corporation, www.secure64.com Cell: 469-834-3940 -----Original Message----- From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf Of Paul Wouters Sent: Tuesday, January 25, 2011 11:53 AM To: dnsext List Subject: [dnsext] historal root keys for upgrade path? A very large router vendor is about to make it mandatory that new devices they produce use dnssec by default. One issue that comes up with that is what happens if these devices were off long enough for a rollover to have happened and the RFC5011 bit/key has been retired. Are there plans to create a zone with all old root keys, that all sign the DNSKEY RRset (eg rootkeys.root-servers.net) so that having ANY one old root key could lead you to get a signed version of the latest root key? This way you could disable DNSSEC to resolve rootkeys.root-servers.net, use your current key to confirm the latest key, configure it, and drop the cache, and you're golden. Is something like this even possible? I'm not sure what happens to the root private keys once they are retired... Paul _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From ajs@shinkuro.com Tue Jan 25 10:26:30 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDBEE3A6403 for ; Tue, 25 Jan 2011 10:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0gL+6kYsZhP for ; Tue, 25 Jan 2011 10:26:28 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 534E23A6849 for ; Tue, 25 Jan 2011 10:26:28 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id ED3E91ECB421 for ; Tue, 25 Jan 2011 18:29:25 +0000 (UTC) Date: Tue, 25 Jan 2011 13:29:24 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110125182924.GG5011@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jan 2011 18:26:30 -0000 On Tue, Jan 25, 2011 at 12:53:11PM -0500, Paul Wouters wrote: > Are there plans to create a zone with all old root keys, that all sign the > DNSKEY RRset (eg rootkeys.root-servers.net) so that having ANY one old root > key could lead you to get a signed version of the latest root key? This way > you could disable DNSSEC to resolve rootkeys.root-servers.net, use your > current key to confirm the latest key, configure it, and drop the cache, > and you're golden. I think the answer is http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02 (and the opposition it has faced). A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From paul@xelerance.com Tue Jan 25 10:28:15 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514473A6853 for ; Tue, 25 Jan 2011 10:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUmfX1utSCe8 for ; Tue, 25 Jan 2011 10:28:14 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 80B743A6403 for ; Tue, 25 Jan 2011 10:28:14 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 19361BF8B; Tue, 25 Jan 2011 13:31:12 -0500 (EST) Date: Tue, 25 Jan 2011 13:31:11 -0500 (EST) From: Paul Wouters To: Stephan Lagerholm In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext List Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jan 2011 18:28:15 -0000 On Tue, 25 Jan 2011, Stephan Lagerholm wrote: > See: draft-wijngaards-dnsop-trust-history-02 > > Abstract: > When DNS validators have trusted keys, but have been offline for a > longer period, key rollover will fail and they are stuck with stale > trust anchors. History service allows validators to query for older > DNSKEY RRsets and pick up the rollover trail where they left off. Ok, so the next question is, can and will the root implement this? Because that's really the main key that needs this. Paul From paul.hoffman@vpnc.org Tue Jan 25 11:20:44 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61CB3A6816 for ; Tue, 25 Jan 2011 11:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.435 X-Spam-Level: X-Spam-Status: No, score=-101.435 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_61=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIQM+QQv5D2C for ; Tue, 25 Jan 2011 11:20:42 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A0D713A6838 for ; Tue, 25 Jan 2011 11:20:42 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0PJNeJk044405 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 25 Jan 2011 12:23:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3F233C.7000900@vpnc.org> Date: Tue, 25 Jan 2011 11:23:40 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jan 2011 19:20:44 -0000 On 1/25/11 9:53 AM, Paul Wouters wrote: > > A very large router vendor is about to make it mandatory that new devices > they produce use dnssec by default. One issue that comes up with that > is what happens if these devices were off long enough for a rollover to > have happened and the RFC5011 bit/key has been retired. > > Are there plans to create a zone with all old root keys, that all sign the > DNSKEY RRset (eg rootkeys.root-servers.net) so that having ANY one old root > key could lead you to get a signed version of the latest root key? This way > you could disable DNSSEC to resolve rootkeys.root-servers.net, use your > current key to confirm the latest key, configure it, and drop the cache, > and you're golden. > > Is something like this even possible? I'm not sure what happens to the > root private keys once they are retired... It is possible, but not in the way you seem to be thinking. If you trusted that hardware/software vendor to securely populate your trust anchor store originally, you can trust them to do so in the future as well. One simple method would be, when you see you have a stale trust anchor and no way to use 5011 to get a fresher one, to securely ask the vendor for the new trust anchor out of band (that is, not using the DNS). There are lots of ways to do this, and none need to be standardized. One simple method is to do a HTTP-over-TLS query to a pre-loaded IP address that is controlled by the vendor, and validate the session with a certificate that is not tied to the DNS. Another simple(r?) method is SSH to an IP address controlled by the vendor (and so on). Bootstrapping is hard, but once you have done it, you can reuse the trust logic you used to do it again. --Paul Hoffman From paul@xelerance.com Tue Jan 25 12:09:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D305D3A687F for ; Tue, 25 Jan 2011 12:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm4a1NmDmZBh for ; Tue, 25 Jan 2011 12:09:07 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id EB4123A685C for ; Tue, 25 Jan 2011 12:09:06 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 72E3CBF8B; Tue, 25 Jan 2011 15:12:04 -0500 (EST) Date: Tue, 25 Jan 2011 15:12:04 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4D3F233C.7000900@vpnc.org> Message-ID: References: <4D3F233C.7000900@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jan 2011 20:09:07 -0000 On Tue, 25 Jan 2011, Paul Hoffman wrote: >> Is something like this even possible? I'm not sure what happens to the >> root private keys once they are retired... > > It is possible, but not in the way you seem to be thinking. If you trusted > that hardware/software vendor to securely populate your trust anchor store > originally, you can trust them to do so in the future as well. Well, this is the vendor asking "do we really need to build something ourselves" The anser seems to be "yes". It also means that some devices will fail due to firewall rules if this updating happens outside of the DNS scope. > Bootstrapping is hard, but once you have done it, you can reuse the trust > logic you used to do it again. Not neccessarilly. Bootstreap happens on a desk at the sysadmin office, not neccessarilly on the switch in the production environment.... Paul From paul.hoffman@vpnc.org Tue Jan 25 12:25:58 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49DCC3A6889 for ; Tue, 25 Jan 2011 12:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.736 X-Spam-Level: X-Spam-Status: No, score=-101.736 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIcA9l3RT8qv for ; Tue, 25 Jan 2011 12:25:57 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CD8233A6869 for ; Tue, 25 Jan 2011 12:25:56 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0PKSsF1048003 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 25 Jan 2011 13:28:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3F3286.8040102@vpnc.org> Date: Tue, 25 Jan 2011 12:28:54 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D3F233C.7000900@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jan 2011 20:25:58 -0000 On 1/25/11 12:12 PM, Paul Wouters wrote: > On Tue, 25 Jan 2011, Paul Hoffman wrote: > >>> Is something like this even possible? I'm not sure what happens to the >>> root private keys once they are retired... >> >> It is possible, but not in the way you seem to be thinking. If you >> trusted that hardware/software vendor to securely populate your trust >> anchor store originally, you can trust them to do so in the future as >> well. > > Well, this is the vendor asking "do we really need to build something > ourselves" > > The anser seems to be "yes". It also means that some devices will fail > due to > firewall rules if this updating happens outside of the DNS scope. I don't understand this. I proposed that the updating procedure use fixed IP addresses; are you saying that there are firewalls that prevent such communication unless there was a DNS lookup first? >> Bootstrapping is hard, but once you have done it, you can reuse the >> trust logic you used to do it again. > > Not neccessarilly. Bootstreap happens on a desk at the sysadmin office, not > neccessarilly on the switch in the production environment.... There is no reason why it can't happen at the switch itself, assuming that you have not turned off the "trust the vendor to bootstrap DNSSEC" option in the switch's config. From paul@xelerance.com Tue Jan 25 12:44:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E363A685C for ; Tue, 25 Jan 2011 12:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouvNs9wWi65x for ; Tue, 25 Jan 2011 12:44:13 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 89AB33A6875 for ; Tue, 25 Jan 2011 12:44:13 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id BBF56BF8B; Tue, 25 Jan 2011 15:47:10 -0500 (EST) Date: Tue, 25 Jan 2011 15:47:10 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4D3F3286.8040102@vpnc.org> Message-ID: References: <4D3F233C.7000900@vpnc.org> <4D3F3286.8040102@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jan 2011 20:44:14 -0000 On Tue, 25 Jan 2011, Paul Hoffman wrote: >> The anser seems to be "yes". It also means that some devices will fail >> due to >> firewall rules if this updating happens outside of the DNS scope. > > I don't understand this. I proposed that the updating procedure use fixed IP > addresses; are you saying that there are firewalls that prevent such > communication unless there was a DNS lookup first? I dount many switches/routers deployed at $customer can just access a random $vendor IP, yes. >>> Bootstrapping is hard, but once you have done it, you can reuse the >>> trust logic you used to do it again. >> >> Not neccessarilly. Bootstreap happens on a desk at the sysadmin office, not >> neccessarilly on the switch in the production environment.... > > There is no reason why it can't happen at the switch itself, assuming that > you have not turned off the "trust the vendor to bootstrap DNSSEC" option in > the switch's config. But dong tftp,http or even ssh is a much different ACL then "doing more DNS through the $company assigned forwarder". Paul From brian.peter.dickson@gmail.com Tue Jan 25 13:56:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27903A68AA for ; Tue, 25 Jan 2011 13:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.771 X-Spam-Level: X-Spam-Status: No, score=-2.771 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyTx5zOjS5+E for ; Tue, 25 Jan 2011 13:56:32 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 9FF543A6890 for ; Tue, 25 Jan 2011 13:56:31 -0800 (PST) Received: by fxm9 with SMTP id 9so293115fxm.31 for ; Tue, 25 Jan 2011 13:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vX8B2BND9cpPmFwoUPgDVBEhoQV0DyKu6DoBpIbQrbs=; b=NlpICCykkzcdHYoPPNtsSWGxxhaTMZfO2AfxYOPrNlCFxQ6FXaw4BJ4k/9EfeV8nXP gV0yKWFkNiWf4gGyEOvYuhPZYMbeVwTpy0Gpz+7KDowtbPw/5Y7jTx6NzOs6ZBZixisH mWBYjOetPzwdjj183Ut8aD4bfgHhQklbM2cm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mMvgI+te/y558QzBnaIST4liH1ffLNOfUAK+tWKktufcCw9LO1TfREHoRwE2N6cRZl P7p8U8UHiDCjJwu4Y/DTc+5yHk1ABamQu+1P+r+0m/nR1QBKKAW3jZOgjllMCrON7RGL gitHQD9JHNpPI/C+4R105nLOy9BOk2gpdoW50= MIME-Version: 1.0 Received: by 10.223.93.139 with SMTP id v11mr6273771fam.132.1295992133999; Tue, 25 Jan 2011 13:48:53 -0800 (PST) Received: by 10.223.108.71 with HTTP; Tue, 25 Jan 2011 13:48:53 -0800 (PST) In-Reply-To: References: <4D3F233C.7000900@vpnc.org> <4D3F3286.8040102@vpnc.org> Date: Tue, 25 Jan 2011 17:48:53 -0400 Message-ID: From: Brian Dickson To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jan 2011 21:56:32 -0000 Here's an idea, which relies on "conventions" rather than "standards". I.e. can be implemented unilaterally by $vendor, independent of anything else. The basic idea is that DNSSEC relies on verification, and doesn't *really* care where the answer itself comes from. And thus, anyone can run their own "copy" of any zone, even the root zone, just by mirroring/copying/caching. The scheme is, have copies of the root zone at $IPn inside $vendor's IP space. Whenever the root zone key rolls, increment the last octet of $IPn (thus $IP(n+1) = $IPn + 1). The old root zone copy authenticates okay, and this creates a suitable trust anchor for rootzone.$vendor.$tld. The content of rootzone.$vendor.$tld is a set of new hints and copy of the root zone trust anchor. Following the new hints to $IPn+1 permits the new trust anchor to be verified. I'm not sure, but I *think* this works (modulo errors or omissions). It might be necessary to have the bootstrap start with a static trust anchor and set of root hints inside rootzone.$vendor.$tld... Brian On Tue, Jan 25, 2011 at 4:47 PM, Paul Wouters wrote: > On Tue, 25 Jan 2011, Paul Hoffman wrote: > >>> The anser seems to be "yes". It also means that some devices will fail >>> due to >>> firewall rules if this updating happens outside of the DNS scope. >> >> I don't understand this. I proposed that the updating procedure use fixed >> IP addresses; are you saying that there are firewalls that prevent such >> communication unless there was a DNS lookup first? > > I dount many switches/routers deployed at $customer can just access a random > $vendor IP, yes. > >>>> Bootstrapping is hard, but once you have done it, you can reuse the >>>> trust logic you used to do it again. >>> >>> Not neccessarilly. Bootstreap happens on a desk at the sysadmin office, >>> not >>> neccessarilly on the switch in the production environment.... >> >> There is no reason why it can't happen at the switch itself, assuming that >> you have not turned off the "trust the vendor to bootstrap DNSSEC" option in >> the switch's config. > > But dong tftp,http or even ssh is a much different ACL then "doing more DNS > through the $company assigned forwarder". > > Paul > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From fanf2@hermes.cam.ac.uk Wed Jan 26 06:41:51 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8173A657C for ; Wed, 26 Jan 2011 06:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYty-mk7w8Pf for ; Wed, 26 Jan 2011 06:41:50 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 719E13A6405 for ; Wed, 26 Jan 2011 06:41: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-1.csi.cam.ac.uk ([131.111.8.51]:48116) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Pi6c4-0000kC-pl (Exim 4.72) (return-path ); Wed, 26 Jan 2011 14:44:48 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Pi6c4-0007CE-1A (Exim 4.67) (return-path ); Wed, 26 Jan 2011 14:44:48 +0000 Date: Wed, 26 Jan 2011 14:44:48 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: <4D3F233C.7000900@vpnc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 14:41:51 -0000 On Tue, 25 Jan 2011, Paul Wouters wrote: > > The anser seems to be "yes". It also means that some devices will fail due to > firewall rules if this updating happens outside of the DNS scope. You probably want to implement the bootstrap using a very long-lived trust anchor for a fixed vendor zone on a fixed IP address. Many vendors will have to support their bootstrap anchors for about ten years! Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From hallam@gmail.com Wed Jan 26 06:54:27 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DADA3A67A4 for ; Wed, 26 Jan 2011 06:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pMc07xsM+dV for ; Wed, 26 Jan 2011 06:54:26 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 56CA33A6403 for ; Wed, 26 Jan 2011 06:54:26 -0800 (PST) Received: by ywk9 with SMTP id 9so161420ywk.31 for ; Wed, 26 Jan 2011 06:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uVUO27Hbb30Lw41mwz/w8zq3o4jRpWaUcJCXj3VEpQw=; b=TV8IhTKBnVqu1ZBIKaMiQnpuscM1XQXdAjtrDm102KJZ/T80RlnGarlamlgNZTtcMZ VPFqtyIgMCDzF56NAJYaa1juRT4bj7kuI5oX04wg1SFLuhn74SCTZhqRSwQG9H+O7o4o VB8dX9NIAdW+nF0j8VGZj9QMPO4Bee/QQ6Iwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hsZtnBXykLo4CSEYH6/Ax63o3jQT1slgM+eiqkeU8VA3y8sVxuGCzqqYrtBEnER5wn hOXeT1Av2whXj23QmI6qE95SW/Njg4zD31oyZ2MCV76d6Kywg0/N5uftt3fyBcPQ6W+X v5u8BEhY3wGN+pERbIIV6EJhqEwIkrQc3QHkc= MIME-Version: 1.0 Received: by 10.100.34.1 with SMTP id h1mr5098601anh.188.1296053846810; Wed, 26 Jan 2011 06:57:26 -0800 (PST) Received: by 10.100.109.16 with HTTP; Wed, 26 Jan 2011 06:57:26 -0800 (PST) In-Reply-To: References: <4D3F233C.7000900@vpnc.org> Date: Wed, 26 Jan 2011 09:57:26 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=0016e6465220262250049ac10db0 Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 14:54:27 -0000 --0016e6465220262250049ac10db0 Content-Type: text/plain; charset=ISO-8859-1 If you want to distribute keys for immediate use in the DNS, use the infrastructure designed for that purpose. If you want to perform long term trust root management, use an architecture that is designed for that purpose. X.509v3 is designed to deal with TA keys that are valid for decades. There is experience doing that. There is infrastructure that exists to perform management of such keys in a high security environment. And it is possible to outsource management of such to several providers and is is possible to buy the equipment to do so in-house. As a general rule, if I install hardware in my enterprise, it is going to have to chain to my root or one that I select. --0016e6465220262250049ac10db0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you want to distribute keys for immediate use in the DNS, use the infras= tructure designed for that purpose.

If you want to perform long term trust root management,= use an architecture that is designed for that purpose.


X.509v3 is designed to deal with TA keys that are vali= d for decades. There is experience doing that. There is infrastructure that= exists to perform management of such keys in a high security environment. = And it is possible to outsource management of such to several providers and= is is possible to buy the equipment to do so in-house.

As a general rule, if I install hardware in my enterpri= se, it is going to have to chain to my root or one that I select.
--0016e6465220262250049ac10db0-- From paul@xelerance.com Wed Jan 26 06:55:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2983A67A8 for ; Wed, 26 Jan 2011 06:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VNxsl+y4J-4 for ; Wed, 26 Jan 2011 06:55:25 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 55BC13A659A for ; Wed, 26 Jan 2011 06:55:23 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 5B2E7BF8B; Wed, 26 Jan 2011 09:58:22 -0500 (EST) Date: Wed, 26 Jan 2011 09:58:21 -0500 (EST) From: Paul Wouters To: Tony Finch In-Reply-To: Message-ID: References: <4D3F233C.7000900@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 14:55:26 -0000 On Wed, 26 Jan 2011, Tony Finch wrote: > On Tue, 25 Jan 2011, Paul Wouters wrote: >> >> The anser seems to be "yes". It also means that some devices will fail due to >> firewall rules if this updating happens outside of the DNS scope. > > You probably want to implement the bootstrap using a very long-lived trust > anchor for a fixed vendor zone on a fixed IP address. Many vendors will > have to support their bootstrap anchors for about ten years! Ideally, this would be vendor neutral, and survive company merges, or vendors going belly up, or vendor pool IP address changes, etc. If vendors do this then all vendors have to do it themselves. Also, they have to use a different bootstrap because only IANA has the private keys for the root zone to do this in a way that we can use DNSKEY signatures from old to newer keys. Paul From paul@xelerance.com Wed Jan 26 07:03:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55EFC3A67D8 for ; Wed, 26 Jan 2011 07:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFuTF7rEGnpf for ; Wed, 26 Jan 2011 07:03:42 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1010E3A67D4 for ; Wed, 26 Jan 2011 07:03:42 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 2DE54C53C; Wed, 26 Jan 2011 10:06:42 -0500 (EST) Date: Wed, 26 Jan 2011 10:06:41 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4D3F233C.7000900@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 15:03:43 -0000 On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote: > If you want to distribute keys for immediate use in the DNS, use the infrastructure designed for that purpose. > If you want to perform long term trust root management, use an architecture that is designed for that purpose. > > X.509v3 is designed to deal with TA keys that are valid for decades. There is experience doing that. There is infrastructure that exists to perform > management of such keys in a high security environment. And it is possible to outsource management of such to several providers and is is possible to buy > the equipment to do so in-house. Which CA(s)s would we have to make the products trust? IANA seems to be using Godaddy today. Is that guaranteed to last forever? If not, then how is a device supposed to know which CA IANA has chosen at some time in the future? Do we just have to trust all 1500+ commercial CA? And deal with all the revocations? And how to install new ones, using what trust? And remember, this is a switch or router, not a browser or an OS with the "update now" button. Remember this has to work on a product that has just been factory defaulted to a config from 10 years ago, and the device is EOL with no firmware upgrades. > As a general rule, if I install hardware in my enterprise, it is going to have to chain to my root or one that I select. That's awesome for your enterprise, but the question here transcends the single enterprise or the single vendor area. What we are looking at is some guaranteed (preferably DNS but could be http) based linked list of DNSKEY's that sign each other to show transfer of trust. This means with ONE original trusted key, the device can climb up to the current root key in a trusted way. Adding X.509/CA chains solves nothing and adds more complications. Paul From Ed.Lewis@neustar.biz Wed Jan 26 08:06:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4AE3A67AD for ; Wed, 26 Jan 2011 08:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnaFlRlqopbJ for ; Wed, 26 Jan 2011 08:06:10 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 1A1A23A67A8 for ; Wed, 26 Jan 2011 08:06:10 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0QG94xb066646; Wed, 26 Jan 2011 11:09:04 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.111] by Work-Laptop-2.local (PGP Universal service); Wed, 26 Jan 2011 11:09:10 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 26 Jan 2011 11:09:10 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D3F233C.7000900@vpnc.org> Date: Wed, 26 Jan 2011 11:07:05 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 16:06:11 -0000 At 10:06 -0500 1/26/11, Paul Wouters wrote: >This means with ONE original trusted key, the device can climb up to the >current root key in a trusted way. Adding X.509/CA chains solves nothing >and adds more complications. I've been opposed to DNSEXT developing a solution to this problem from the start. Now, here's yet another reason. As much as it would appear that adding a X.509/CA-derived mechanism would redundantly add to the already existing DNS mechanisms ad DNS admin would have, adding a DNS-based update mechanism would add to the exiting SysAdmin mechanisms a Systems admin would have. Reading through this thread adds even more to the reasons why I think this topic is a non-starter. At first was that this proposal effectively extends the key effectivity period of the zone keys beyond the DNS need for it. Now I see the impracticality of having remote machines having to navigate a variety of network security obstacles (such as firewalls) to phone home for security data. I'm not encouraged. More over, when it comes to something as sensitive to security, I'd rather have the configuration done on the in-office desk (or in a staging area within our own data center, etc.) of an admin than in remote rackspace, with or without remote hands involved. This is a general rule, I am not running an operations/security team. Once on the desk, normal sysadmin tools and techniques apply. (We have had our share of customs issues shipping equipment we built locally and then deployed remotely. That's another issue.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 With a week old newborn at home, I've discovered that the only difference between him and me is that I have to go to work daily. That's not fair! Ma! From thierry.moreau@connotech.com Wed Jan 26 08:25:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B113A689F for ; Wed, 26 Jan 2011 08:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.169 X-Spam-Level: * X-Spam-Status: No, score=1.169 tagged_above=-999 required=5 tests=[AWL=1.606, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXIT3ix3hIZ2 for ; Wed, 26 Jan 2011 08:25:27 -0800 (PST) Received: from bretelle.intaglionic.org (unknown [76.10.176.241]) by core3.amsl.com (Postfix) with ESMTP id 85ABA3A689A for ; Wed, 26 Jan 2011 08:25:27 -0800 (PST) Received: from [192.168.1.200] (unknown [192.168.1.200]) by bretelle.intaglionic.org (Postfix) with ESMTPA id 97EFC30760; Wed, 26 Jan 2011 16:39:43 -0500 (EST) Message-ID: <4D404B58.20302@connotech.com> Date: Wed, 26 Jan 2011 11:27:04 -0500 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Paul Wouters References: <4D3F233C.7000900@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 16:25:28 -0000 Paul Wouters wrote: > > Which CA(s)s would we have to make the products trust? IANA seems to > be using Godaddy today. > > Remember this has to work on a product that has just been factory defaulted > to a config from 10 years ago, and the device is EOL with no firmware > upgrades. > You have to make a leap-of-faith decision somewhere somehow. I bet your leap-of-faith decision for current for current DNSSEC root keys is based more on what you know about current IANA than anything about Godaddy. For your product family design, you seek a leap-of-faith decision now, valid for decades. Why don't you put a leap-of-faith pushbutton command in the firmware today, so that the leap-of-faith decision can be re-made independently by your grand-children when he puts the unit back on the network? Isn't this discussion running into circles? -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 From fanf2@hermes.cam.ac.uk Wed Jan 26 08:39:44 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240313A67EF for ; Wed, 26 Jan 2011 08:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhqFkByyk8ZI for ; Wed, 26 Jan 2011 08:39:43 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id 01AC43A67F3 for ; Wed, 26 Jan 2011 08:39:43 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:48553) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Pi8SA-0007NI-Se (Exim 4.72) (return-path ); Wed, 26 Jan 2011 16:42:42 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Pi8SA-000087-S8 (Exim 4.67) (return-path ); Wed, 26 Jan 2011 16:42:42 +0000 Date: Wed, 26 Jan 2011 16:42:42 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Edward Lewis In-Reply-To: Message-ID: References: <4D3F233C.7000900@vpnc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 16:39:44 -0000 On Wed, 26 Jan 2011, Edward Lewis wrote: > > More over, when it comes to something as sensitive to security, I'd rather > have the configuration done on the in-office desk (or in a staging area within > our own data center, etc.) of an admin than in remote rackspace, with or > without remote hands involved. This is a general rule, I am not running an > operations/security team. Once on the desk, normal sysadmin tools and > techniques apply. What if the validator is in a consumer DSL router? Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From Ed.Lewis@neustar.biz Wed Jan 26 09:06:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107BF3A6801 for ; Wed, 26 Jan 2011 09:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGrpHGbDkBKJ for ; Wed, 26 Jan 2011 09:06:15 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 2BA403A67DF for ; Wed, 26 Jan 2011 09:06:15 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0QH97cH067240; Wed, 26 Jan 2011 12:09:07 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.111] by Work-Laptop-2.local (PGP Universal service); Wed, 26 Jan 2011 12:09:13 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 26 Jan 2011 12:09:13 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D3F233C.7000900@vpnc.org> Date: Wed, 26 Jan 2011 12:04:06 -0500 To: Tony Finch From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 17:06:16 -0000 At 16:42 +0000 1/26/11, Tony Finch wrote: > >What if the validator is in a consumer DSL router? We don't (and no one I ever worked for) run those. (Meaning, I can't speak from experience.) I would guess the upgrade would be done the way any of those are upgraded for other reasons. (I.e, the DNSSEC key isn't that special.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 With a week old newborn at home, I've discovered that the only difference between him and me is that I have to go to work daily. That's not fair! Ma! From hallam@gmail.com Wed Jan 26 09:38:47 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F0C3A6917 for ; Wed, 26 Jan 2011 09:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlGzsDhp6djZ for ; Wed, 26 Jan 2011 09:38:46 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D409B3A6828 for ; Wed, 26 Jan 2011 09:38:45 -0800 (PST) Received: by gxk27 with SMTP id 27so273841gxk.31 for ; Wed, 26 Jan 2011 09:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KAWiNOdA39VBwENQbcH1uhePyfIY2UJRtOhFimpC0Cc=; b=enI6JTo9CDSOsPQx6ZWrBMnTwNjo5k1eq/PyH+oXV558W40jmzD0gA/KkVdyuEAc2T r1LgWEEtRZmk0Ij/iNhnygcqY9VjQSGXNoNNW68kZSOmqRppb4Ba8I8wRGQUx0aawxCj tMvS+KJELuUoqRmXvgWfg1dD6EHgk3wLj/BP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=w9hE08w42dBl9nkFogreRhfvgfvDnt6a+0/BpwUBQZ/01/9C3QJCDoTgXlnRwaBhCT 1S8mNbbJZBu6EddVpB451mM7tE8U0cLMkQNWvhNOGJloZpy7MEJaKcU0juYCuJuYE5hl jYtZnHtFyERo+p5/00wf0BWm+jUNk2xf/celM= MIME-Version: 1.0 Received: by 10.100.134.10 with SMTP id h10mr5158792and.86.1296063706309; Wed, 26 Jan 2011 09:41:46 -0800 (PST) Received: by 10.100.109.16 with HTTP; Wed, 26 Jan 2011 09:41:45 -0800 (PST) In-Reply-To: References: <4D3F233C.7000900@vpnc.org> Date: Wed, 26 Jan 2011 12:41:45 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e644c708d22361049ac35839 Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 17:38:47 -0000 --0016e644c708d22361049ac35839 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 26, 2011 at 10:06 AM, Paul Wouters wrote: > On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote: > > If you want to distribute keys for immediate use in the DNS, use the >> infrastructure designed for that purpose. >> If you want to perform long term trust root management, use an >> architecture that is designed for that purpose. >> >> X.509v3 is designed to deal with TA keys that are valid for decades. There >> is experience doing that. There is infrastructure that exists to perform >> management of such keys in a high security environment. And it is possible >> to outsource management of such to several providers and is is possible to >> buy >> the equipment to do so in-house. >> > > Which CA(s)s would we have to make the products trust? IANA seems to > be using Godaddy today. Is that guaranteed to last forever? If not, > then how is a device supposed to know which CA IANA has chosen at some > time in the future? Do we just have to trust all 1500+ commercial CA? And > deal with all the revocations? And how to install new ones, using > what trust? And remember, this is a switch or router, not a browser or > an OS with the "update now" button. > Use a Quorate Root then. Multiple Signers, are recognized. A valid key must be counter signed by a quorum of the recognized signers. This approach is unencumbered as far as I know (Phil Z. described it at length but did not deploy code). As Ed Lewis points out, these are really tricky trust problems and there are good reasons not to want to trust any monolithic single rooted scheme. There are much larger International IT efforts than DNSSEC that have collapsed due to failure to agree on this type of issue. -- Website: http://hallambaker.com/ --0016e644c708d22361049ac35839 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 26, 2011 at 10:06 AM, Paul W= outers <paul@xel= erance.com> wrote:
On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote:

If you want to distribute keys for immediate use in the DNS, use the infras= tructure designed for that purpose.
If you want to perform long term trust root management, use an architecture= that is designed for that purpose.

X.509v3 is designed to deal with TA keys that are valid for decades. There = is experience doing that. There is infrastructure that exists to perform management of such keys in a high security environment. And it is possible = to outsource management of such to several providers and is is possible to = buy
the equipment to do so in-house.

Which CA(s)s would we have to make the products trust? IANA seems to
be using Godaddy today. Is that guaranteed to last forever? If not,
then how is a device supposed to know which CA IANA has chosen at some
time in the future? Do we just have to trust all 1500+ commercial CA? And d= eal with all the revocations? And how to install new ones, using
what trust? And remember, this is a switch or router, not a browser or
an OS with the "update now" button.


Use a Quorate Root then.

Mul= tiple Signers, are recognized. A valid key must be counter signed by a quor= um of the recognized signers.

This approach is unencumbered as far as I know (Phil Z.= described it at length but did not deploy code).

=
As Ed Lewis points out, these are really tricky trust proble= ms and there are good reasons not to want to trust any monolithic single ro= oted scheme.=A0

There are much larger International IT efforts than DNS= SEC that have collapsed due to failure to agree on this type of issue.=A0

--
Website: http://ha= llambaker.com/

--0016e644c708d22361049ac35839-- From brian.peter.dickson@gmail.com Wed Jan 26 09:58:19 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9C63A67BD for ; Wed, 26 Jan 2011 09:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.083 X-Spam-Level: X-Spam-Status: No, score=-3.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AydtMEdtjmeA for ; Wed, 26 Jan 2011 09:58:18 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 118403A67B3 for ; Wed, 26 Jan 2011 09:58:17 -0800 (PST) Received: by fxm9 with SMTP id 9so1315333fxm.31 for ; Wed, 26 Jan 2011 10:01:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+6Hg5Lq4s7KBTTubwFS5uVoyz2bBPNnEStwwNrgG+hg=; b=psKR3bQohX4BUr/Vc+e7WOqtQVR8A4UUVM14JqlrcL/n+l+y65PFeyZ2uSGFiCCFQR 58/s1NxetdrD2ofKc09HHG9/rIAHwHkaqVgG/Xd0gKniOxR38KvqqQ5ymWF+g+64PF6p /EsRFAWc43qj+H7e73CP9XTfyWnf+cqnpukIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Zuw1LijUz5T2dwxSk0I+/asRnaO3R3+7bejDoNnZSzUIEI3yxkNdw4ZPHegOnM1vGd 17VM0pkIdxtYJ46UIMtdxBM4weytdxCc1XQsoDaYFmkFvB6s2pLaRlkQkdH8Tju9KJCu F7S12zrsgQrhLMHrGNDSuYNobdeHa6icDSiaE= MIME-Version: 1.0 Received: by 10.223.93.139 with SMTP id v11mr7462875fam.132.1296064452846; Wed, 26 Jan 2011 09:54:12 -0800 (PST) Received: by 10.223.108.71 with HTTP; Wed, 26 Jan 2011 09:54:12 -0800 (PST) In-Reply-To: References: Date: Wed, 26 Jan 2011 13:54:12 -0400 Message-ID: From: Brian Dickson To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext List Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 17:58:19 -0000 Actually, this is only a problem if the revoked keys are removed from the root DNSKEY RRset. Other than space reasons, I don't see any particular reason to remove revoked keys, especially at the root. Perhaps someone from ICANN/IANA can answer this concern? Joe? Brian On Tue, Jan 25, 2011 at 1:53 PM, Paul Wouters wrote: > > A very large router vendor is about to make it mandatory that new devices > they produce use dnssec by default. One issue that comes up with that > is what happens if these devices were off long enough for a rollover to > have happened and the RFC5011 bit/key has been retired. > > Are there plans to create a zone with all old root keys, that all sign the > DNSKEY RRset (eg rootkeys.root-servers.net) so that having ANY one old root > key could lead you to get a signed version of the latest root key? This way > you could disable DNSSEC to resolve rootkeys.root-servers.net, use your > current key to confirm the latest key, configure it, and drop the cache, > and you're golden. > > Is something like this even possible? I'm not sure what happens to the > root private keys once they are retired... > > Paul > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From paul@xelerance.com Wed Jan 26 10:02:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BDCE3A6850 for ; Wed, 26 Jan 2011 10:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDxeRGJzr9jb for ; Wed, 26 Jan 2011 10:02:19 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id D58773A6818 for ; Wed, 26 Jan 2011 10:02:18 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 47B89BF8B; Wed, 26 Jan 2011 13:05:18 -0500 (EST) Date: Wed, 26 Jan 2011 13:05:17 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4D3F233C.7000900@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 18:02:20 -0000 On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote: > Which CA(s)s would we have to make the products trust? IANA seems to > be using Godaddy today. Is that guaranteed to last forever? If not, > then how is a device supposed to know which CA IANA has chosen at some > time in the future? Do we just have to trust all 1500+ commercial CA? And deal with all the revocations? And how to install new ones, using > what trust? And remember, this is a switch or router, not a browser or > an OS with the "update now" button. > Use a Quorate Root then. > > Multiple Signers, are recognized. A valid key must be counter signed by a quorum of the recognized signers. Maybe we can add even more complexity to this? The path here is extremely clear. It hopes from a common trusted key to new keys via intermediate steps, all of which are signed. To bring in any other outside trusted third party with its own pletora of trust anchor update issues is not solving the problem. You are just moving the problem. Worse, you are moving the problem away from the original trusted parties into a hypothetical bag of other trusted parties with even less clear mandates. > As Ed Lewis points out, these are really tricky trust problems and there are good reasons not to want to trust any monolithic single rooted scheme.  Please either specifically mention the reasons, or stop waiving your generalities. DNSSEC is already trusting "monolithic single rooted scheme", so suggesting we destroy that is moot. There is no valid reason to bring in third parties. Let alone insist that validating resolvers need to gain ASN.1 parsers and X.509 trust anchors. Seriously, grab a 10 year old browser and tell me how well this "proven technology" works? How many of those CA's are still valid today? How could we have guaranteed to have picked one that is still active today - provided there is any? We already have a fully functional path of trust, from root key to root key, that is validatable by DNSSEC. > There are much larger International IT efforts than DNSSEC that have collapsed due to failure to agree on this type of issue.  Yeah, the Government of Canada's Entrust X.509 scheme comes to mind....... Paul From anicoll@cert.org Wed Jan 26 10:06:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 023653A6834 for ; Wed, 26 Jan 2011 10:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2DR2WnSJUmQ for ; Wed, 26 Jan 2011 10:06:41 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by core3.amsl.com (Postfix) with ESMTP id A4E4F3A6818 for ; Wed, 26 Jan 2011 10:06:41 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.13.8/8.13.8/1294) with ESMTP id p0QI9gdl020354 for ; Wed, 26 Jan 2011 13:09:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1296065382; bh=Fm1LtHCds0iJwKOP3tsjky2xEjrVqn4TiZgBoLmB6e4=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=dZM49S1xy9RpToaE2k7I6dobHpcJBLGx/lJSKlv8BJqT2TXK4hhGRebodtrXSzQU1 UKKHd1Uj3HZRK+svLFEwu2C+/upUJ/P5L0HAvimt87kYNqFisN1iPh1ohVbwID/RfN jyiEfqeCOP/eja2y3YgU+XEsvOuAntQYss6jM3ps= Received: from owa.sei.cmu.edu (tyranus.sei.cmu.edu [10.64.28.15]) by timber.sei.cmu.edu (8.13.8/8.13.8/1348) with ESMTP id p0QI9gQ4018003 for ; Wed, 26 Jan 2011 13:09:42 -0500 Received: from EXCHANGE.sei.cmu.edu ([10.64.28.13]) by tyranus.sei.cmu.edu ([10.64.28.15]) with mapi; Wed, 26 Jan 2011 13:09:42 -0500 From: Alex Nicoll To: "dnsext@ietf.org" Date: Wed, 26 Jan 2011 13:09:40 -0500 Thread-Topic: [dnsext] historal root keys for upgrade path? Thread-Index: Acu9g5vLTa0KYNCkTYCIjyk8j7hrmwAADLNA Message-ID: References: <4D3F233C.7000900@vpnc.org> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 18:06:43 -0000 Gents (and lurking ladies) -=20 Maybe I'm missing something here, but I thought that the whole purpose of D= NSKEY rotation was to adhere to the basic cryptography tenet that a key is = only good for so long, and then there's too great a risk of someone crackin= g it. If we implement an entire schema for historical keys that chains tru= st, don't we introduce the capability for long term key attacks to compromi= se the whole system? I know I could do this for several know encryption sc= hemes now - there's no reason advances in computing power cannot do it for = new ones. =20 Long story short - wouldn't this shoot us in the foot? -Alex -----Original Message----- From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf Of= Paul Wouters Sent: Wednesday, January 26, 2011 1:05 PM To: Phillip Hallam-Baker Cc: Paul Hoffman; dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote: > Which CA(s)s would we have to make the products trust? IANA seems to=20 > be using Godaddy today. Is that guaranteed to last forever? If not,=20 > then how is a device supposed to know which CA IANA has chosen at some=20 > time in the future? Do we just have to trust all 1500+ commercial CA?=20 > And deal with all the revocations? And how to install new ones, using=20 > what trust? And remember, this is a switch or router, not a browser or an= OS with the "update now" button. > Use a Quorate Root then. >=20 > Multiple Signers, are recognized. A valid key must be counter signed by a= quorum of the recognized signers. Maybe we can add even more complexity to this? The path here is extremely clear. It hopes from a common trusted key to new= keys via intermediate steps, all of which are signed. To bring in any othe= r outside trusted third party with its own pletora of trust anchor update i= ssues is not solving the problem. You are just moving the problem. Worse, y= ou are moving the problem away from the original trusted parties into a hyp= othetical bag of other trusted parties with even less clear mandates. > As Ed Lewis points out, these are really tricky trust problems and=20 > there are good reasons not to want to trust any monolithic single rooted = scheme. Please either specifically mention the reasons, or stop waiving your genera= lities. DNSSEC is already trusting "monolithic single rooted scheme", so su= ggesting we destroy that is moot. There is no valid reason to bring in thir= d parties. Let alone insist that validating resolvers need to gain ASN.1 pa= rsers and X.509 trust anchors. Seriously, grab a 10 year old browser and te= ll me how well this "proven technology" works? How many of those CA's are still valid today? How could we have guar= anteed to have picked one that is still active today - provided there is an= y? We already have a fully functional path of trust, from root key to root key= , that is validatable by DNSSEC. > There are much larger International IT efforts than DNSSEC that have=20 > collapsed due to failure to agree on this type of issue. Yeah, the Government of Canada's Entrust X.509 scheme comes to mind....... Paul _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From hallam@gmail.com Wed Jan 26 10:31:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58E03A686E for ; Wed, 26 Jan 2011 10:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsmsTciLmZcM for ; Wed, 26 Jan 2011 10:31:22 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 24B0F3A67D8 for ; Wed, 26 Jan 2011 10:31:22 -0800 (PST) Received: by ywk9 with SMTP id 9so283433ywk.31 for ; Wed, 26 Jan 2011 10:34:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zyJGsuGjNufEWt5CX24MOj30gQ9bzFiXbu1txdUFUMo=; b=RIoRIwPv6uJWMF5nK7H2e7R2Y2U2L9hYp+oUcZzGfpLimZ+N00lt+iXBZWXdVUtgZS HcVjzR+vX95PQp/XEecK84V8oUudrcMFcarG67b2cPn6M/DWJVEebfLL2tTwnUXj5ycG 11eHyPJonc+ZcnOxijS2WRDhQPKUph9HFyiog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OkjF+acoztt3PA9hQNL5wnSDaYACdX4MNygKbfVKBxNxJMX+JpSIRodQeuTh4tVl4i g6R1iwSCepk+hRHODD/W6JHpSEEmGj2mlcs3RgtDUMW8kkDLECa27IAaVM3miiJH9oua ZlX7l2Zs1TkhqJMoEaKQV5pCglohIH28JY0ak= MIME-Version: 1.0 Received: by 10.100.34.1 with SMTP id h1mr5267151anh.188.1296066862994; Wed, 26 Jan 2011 10:34:22 -0800 (PST) Received: by 10.100.109.16 with HTTP; Wed, 26 Jan 2011 10:34:22 -0800 (PST) In-Reply-To: References: <4D3F233C.7000900@vpnc.org> Date: Wed, 26 Jan 2011 13:34:22 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e6465220f9547f049ac41432 Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 18:31:24 -0000 --0016e6465220f9547f049ac41432 Content-Type: text/plain; charset=ISO-8859-1 Paul, you came here with an assertion that you were interested in solving a particular problem. Since then you have changed the problem whenever people suggest an alternative that does not match your proposed solution. PKI is complex because the world is complex. And people who try to ignore the complexity of the real world tend to end up wit PKIs that are even more complex than they need to be. If I was a major router manufacturer or any other manufacturer, I would make sure that there was satisfactory control of the ultimate root of trust embedded in my products. As the Internet matures and the need to upgrade equipment for purely performance issues subsides, service lifetimes for network infrastructure is going to be measured in decades. Which is something of a problem in an industry where Internet time turned out to mean that Netscape took a little over five years to go from startup, to industry behemoth, to extinction rather than the 80-90 years that it took General Motors to achieve the same. On Wed, Jan 26, 2011 at 1:05 PM, Paul Wouters wrote: > On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote: > > Which CA(s)s would we have to make the products trust? IANA seems to >> be using Godaddy today. Is that guaranteed to last forever? If not, >> then how is a device supposed to know which CA IANA has chosen at some >> time in the future? Do we just have to trust all 1500+ commercial CA? And >> deal with all the revocations? And how to install new ones, using >> what trust? And remember, this is a switch or router, not a browser or >> an OS with the "update now" button. >> > > Use a Quorate Root then. >> >> Multiple Signers, are recognized. A valid key must be counter signed by a >> quorum of the recognized signers. >> > > Maybe we can add even more complexity to this? > > The path here is extremely clear. It hopes from a common trusted key to new > keys via intermediate steps, > all of which are signed. To bring in any other outside trusted third party > with its own pletora of > trust anchor update issues is not solving the problem. You are just moving > the problem. Worse, you are > moving the problem away from the original trusted parties into a > hypothetical bag of other trusted parties > with even less clear mandates. > > > As Ed Lewis points out, these are really tricky trust problems and there >> are good reasons not to want to trust any monolithic single rooted scheme. >> > > Please either specifically mention the reasons, or stop waiving your > generalities. DNSSEC is already > trusting "monolithic single rooted scheme", so suggesting we destroy that > is moot. There is no valid > reason to bring in third parties. Let alone insist that validating > resolvers need to gain ASN.1 parsers > and X.509 trust anchors. Seriously, grab a 10 year old browser and tell me > how well this "proven technology" > works? How many of those CA's are still valid today? How could we have > guaranteed to have picked one that > is still active today - provided there is any? > > We already have a fully functional path of trust, from root key to root > key, that is validatable by DNSSEC. > > > There are much larger International IT efforts than DNSSEC that have >> collapsed due to failure to agree on this type of issue. >> > > Yeah, the Government of Canada's Entrust X.509 scheme comes to mind....... > > Paul > -- Website: http://hallambaker.com/ --0016e6465220f9547f049ac41432 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul, you came here with an assertion that you were interested in solving a= particular problem.

Since then you have changed the pro= blem whenever people suggest an alternative that does not match your propos= ed solution.

PKI is complex because the world is complex. And people= who try to ignore the complexity of the real world tend to end up wit PKIs= that are even more complex than they need to be.


If I was a major router manufacturer or any other manufactur= er, I would make sure that there was satisfactory control of the ultimate r= oot of trust embedded in my products.

As the Inter= net matures and the need to upgrade equipment for purely performance issues= subsides, service lifetimes for network infrastructure is going to be meas= ured in decades. Which is something of a problem in an industry where Inter= net time turned out to mean that Netscape took a little over five years to = go from startup, to industry behemoth, to extinction rather than the 80-90 = years that it took General Motors to achieve the same.


On Wed, Jan 26, 2011 at = 1:05 PM, Paul Wouters <paul@xelerance.com> wrote:
On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote:

Which CA(s)s would we have to make the products trust? IANA seems to
be using Godaddy today. Is that guaranteed to last forever? If not,
then how is a device supposed to know which CA IANA has chosen at some
time in the future? Do we just have to trust all 1500+ commercial CA? And d= eal with all the revocations? And how to install new ones, using
what trust? And remember, this is a switch or router, not a browser or
an OS with the "update now" button.

Use a Quorate Root then.

Multiple Signers, are recognized. A valid key must be counter signed by a q= uorum of the recognized signers.

Maybe we can add even more complexity to this?

The path here is extremely clear. It hopes from a common trusted key to new= keys via intermediate steps,
all of which are signed. To bring in any other outside trusted third party = with its own pletora of
trust anchor update issues is not solving the problem. You are just moving = the problem. Worse, you are
moving the problem away from the original trusted parties into a hypothetic= al bag of other trusted parties
with even less clear mandates.


As Ed Lewis points out, these are really tricky trust problems and there ar= e good reasons not to want to trust any monolithic single rooted scheme.=A0=

Please either specifically mention the reasons, or stop waiving your genera= lities. DNSSEC is already
trusting "monolithic single rooted scheme", so suggesting we dest= roy that is moot. There is no valid
reason to bring in third parties. Let alone insist that validating resolver= s need to gain ASN.1 parsers
and X.509 trust anchors. Seriously, grab a 10 year old browser and tell me = how well this "proven technology"
works? How many of those CA's are still valid today? How could we have = guaranteed to have picked one that
is still active today - provided there is any?

We already have a fully functional path of trust, from root key to root key= , that is validatable by DNSSEC.


There are much larger International IT efforts than DNSSEC that have collap= sed due to failure to agree on this type of issue.=A0

Yeah, the Government of Canada's Entrust X.509 scheme comes to mind....= ...

Paul



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

--0016e6465220f9547f049ac41432-- From paul@xelerance.com Wed Jan 26 13:38:17 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39A23A68A0 for ; Wed, 26 Jan 2011 13:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBgTfSBcfFHZ for ; Wed, 26 Jan 2011 13:38:16 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 7C5283A6893 for ; Wed, 26 Jan 2011 13:38:15 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id C9181C53C; Wed, 26 Jan 2011 16:41:15 -0500 (EST) Date: Wed, 26 Jan 2011 16:41:15 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4D3F233C.7000900@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 21:38:17 -0000 On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote: > Paul, you came here with an assertion that you were interested in solving a particular problem. > Since then you have changed the problem whenever people suggest an alternative that does not match your > proposed solution. > If I was a major router manufacturer or any other manufacturer, I would make sure that there was satisfactory > control of the ultimate root of trust embedded in my products. This particular big router vendor has stated to me that using X.509 and CA's can not be part of the solution, exactly for the reasons I have mentioned in previous emails. These are their words exactly: Frankly, one of the most compelling reasons for wanting to see ubiquitous DNSSEC is precisely this long, ever changing list of X.509 CAs, each with its own policies, procedures, personnel, and pressure points, and each representing an opportunity for total failure of the whole PKI. X.509 as deployed is a security disaster, and I see basically no chance of it ever getting better. Personally, and I'm hoping to convince [vendor] and everybody else of this eventually, I would like to see DNSSEC *replace* X.509 as the PKI for basically everything on the Internet, or at least see all X.509 trust conditioned on DNSSEC trust. Phillip, it is not just me. Your PKI solution does not fit this problem. It just creates an additional problem. > As the Internet matures and the need to upgrade equipment for purely performance issues subsides, service > lifetimes for network infrastructure is going to be measured in decades. Which is something of a problem in > an industry where Internet time turned out to mean that Netscape took a little over five years to go from > startup, to industry behemoth, to extinction rather than the 80-90 years that it took General Motors to > achieve the same. You never did give me your professional expert estimate of the amount or percentage of valid CA's of the latest Netscape Navigator/Communicator released. I would still be interested in that number to confirm or deny the usability of Certificate Agencies over a decade long deployment. Paul From stephan.lagerholm@secure64.com Wed Jan 26 13:59:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC62F3A69D9 for ; Wed, 26 Jan 2011 13:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.327 X-Spam-Level: X-Spam-Status: No, score=-0.327 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWJu-CEHXYYy for ; Wed, 26 Jan 2011 13:59:18 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by core3.amsl.com (Postfix) with ESMTP id B5D9B3A68B7 for ; Wed, 26 Jan 2011 13:59:18 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 9DE0BB82D9; Wed, 26 Jan 2011 14:57:14 -0700 (MST) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cf10wbySyog5; Wed, 26 Jan 2011 14:57:14 -0700 (MST) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id D76D6B82D6; Wed, 26 Jan 2011 14:57:13 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1296079033; bh=tSq+Y09kfUbIzxzjxv/FF2qTtbLcOH0N3Sr5PZ/i30A=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=upsGUqkWChRkI+/DAF frHaJcewfjHczkN9Ii4IaKhnkkEyHECeC6tLWmBs9J65m0FNJrdhhBu+aKu6cuZM9gX UuWZPNaEqOHuyK9C20BhG+ZIFPb5lYMmxKIM99SPYOp4oVgTncuL74zJjc/R9Zlbfgd sGXQx/uEZZxvCLGmjvM= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2011 15:02:14 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] historal root keys for upgrade path? Thread-Index: Acu9oaKyTUW3YlFzSUOpkIEYOjjp0wAAtxeA References: <4D3F233C.7000900@vpnc.org> From: "Stephan Lagerholm" To: "Paul Wouters" Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 21:59:23 -0000 Paul, This does not appear to be DNS problem. Software becomes old and insecure as time passes. Trust anchors expires, bugs are being found, algorithms are being retired, etc. I'm assuming that the vendor already have a secure mechanism in place to distribute software updates. Why can you not use the same method for new trust anchors? Thanks /Stephan ---------------------------------------------------------------------- Stephan Lagerholm Senior DNS Architect, M.Sc. ,CISSP Secure64 Software Corporation, www.secure64.com Cell: 469-834-3940 -----Original Message----- From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf Of Paul Wouters Sent: Wednesday, January 26, 2011 3:41 PM To: Phillip Hallam-Baker Cc: Paul Hoffman; dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote: > Paul, you came here with an assertion that you were interested in solving a particular problem. > Since then you have changed the problem whenever people suggest an alternative that does not match your > proposed solution. > If I was a major router manufacturer or any other manufacturer, I would make sure that there was satisfactory > control of the ultimate root of trust embedded in my products. This particular big router vendor has stated to me that using X.509 and CA's can not be part of the solution, exactly for the reasons I have mentioned in previous emails. These are their words exactly: Frankly, one of the most compelling reasons for wanting to see ubiquitous DNSSEC is precisely this long, ever changing list of X.509 CAs, each with its own policies, procedures, personnel, and pressure points, and each representing an opportunity for total failure of the whole PKI. X.509 as deployed is a security disaster, and I see basically no chance of it ever getting better. Personally, and I'm hoping to convince [vendor] and everybody else of this eventually, I would like to see DNSSEC *replace* X.509 as the PKI for basically everything on the Internet, or at least see all X.509 trust conditioned on DNSSEC trust. Phillip, it is not just me. Your PKI solution does not fit this problem. It just creates an additional problem. > As the Internet matures and the need to upgrade equipment for purely performance issues subsides, service > lifetimes for network infrastructure is going to be measured in decades. Which is something of a problem in > an industry where Internet time turned out to mean that Netscape took a little over five years to go from > startup, to industry behemoth, to extinction rather than the 80-90 years that it took General Motors to > achieve the same. You never did give me your professional expert estimate of the amount or percentage of valid CA's of the latest Netscape Navigator/Communicator released. I would still be interested in that number to confirm or deny the usability of Certificate Agencies over a decade long deployment. Paul _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From jabley@hopcount.ca Wed Jan 26 15:23:59 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E1A3A6A07 for ; Wed, 26 Jan 2011 15:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttCqYeKw7PAq for ; Wed, 26 Jan 2011 15:23:58 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 3BFDA3A68EA for ; Wed, 26 Jan 2011 15:23:58 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PiEpW-000Grs-E1; Wed, 26 Jan 2011 23:31:15 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: Date: Wed, 26 Jan 2011 18:26:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> References: To: Paul Wouters X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext List Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 23:23:59 -0000 On 2011-01-25, at 12:53, Paul Wouters wrote: > Is something like this even possible? I'm not sure what happens to the > root private keys once they are retired... They still get published in the xml file we host at = https://data.iana.org/root-anchors/, but with appropriate valid=46rom = and validUntil attributes on the KeyDigest element to indicate that they = are not current. See http://tools.ietf.org/html/draft-jabley-dnssec-trust-anchor-00 which Jakob and I will pick back up shortly, sorry for the delay. = Wouter's earlier proposal which is mentioned elsewhere in this thread = had the principle defect that its use relied upon trusting signatures = made by old keys, which in general some of us thought was a poor idea = (e.g. in the event that a key was rolled because it was compromised). Joe From fweimer@bfk.de Thu Jan 27 04:20:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8B53A6AE2 for ; Thu, 27 Jan 2011 04:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gsn2xY3uHNPN for ; Thu, 27 Jan 2011 04:20:42 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 0CF343A6AE1 for ; Thu, 27 Jan 2011 04:20:40 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PiQt4-0002tO-Bk; Thu, 27 Jan 2011 12:23:42 +0000 Received: by bfk.de with local id 1PiQt4-0005B7-6W; Thu, 27 Jan 2011 12:23:42 +0000 To: Paul Wouters References: From: Florian Weimer Date: Thu, 27 Jan 2011 12:23:42 +0000 In-Reply-To: (Paul Wouters's message of "Tue\, 25 Jan 2011 12\:53\:11 -0500 \(EST\)") Message-ID: <82oc72r0vl.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext List Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 12:20:43 -0000 * Paul Wouters: > A very large router vendor is about to make it mandatory that new devices > they produce use dnssec by default. One issue that comes up with that > is what happens if these devices were off long enough for a rollover to > have happened and the RFC5011 bit/key has been retired. AFAUI, this is not something that can be tested in a realistic scenario. Any implementation will be in SDI-land, so it's not worth bothering from an engineering point of view. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fneves@registro.br Thu Jan 27 05:40:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4F83A681E for ; Thu, 27 Jan 2011 05:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzZ02q-PSR6G for ; Thu, 27 Jan 2011 05:40:19 -0800 (PST) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by core3.amsl.com (Postfix) with ESMTP id A77703A6819 for ; Thu, 27 Jan 2011 05:40:18 -0800 (PST) Received: by clone.registro.br (Postfix, from userid 1000) id 98858E051C; Thu, 27 Jan 2011 11:43:20 -0200 (BRST) Date: Thu, 27 Jan 2011 11:43:20 -0200 From: Frederico A C Neves To: dnsext@ietf.org Message-ID: <20110127134320.GC91248@registro.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [dnsext] URI RRTYPE review - New Comments period end Feb 17th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 13:40:20 -0000 Dear Colleagues, Bellow is a resubmission of a completed template requesting a new RRTYPE assignment under the procedures of RFC5395. This message starts a 3 weeks period for an expert-review of the DNS RRTYPE parameter allocation for URI specified in http://tools.ietf.org/html/draft-faltstrom-uri-05 If you have any new comments regarding this request that have not yet being made at the thread starting with message http://www.ietf.org/mail-archive/web/dnsext/current/msg08956.html , please post them here before Feb 17th 18:00 UTC Best Regards, Frederico Neves --begin 5395 template URI-- A. Submission Date: May 23, 2009 B. Submission Type: [X] New RRTYPE [ ] Modification to existing RRTYPE C. Contact Information for submitter: Name: Patrik Faltstrom Email Address: paf@cisco.com International telephone number: +46-8-6859131 Other contact handles: (Note: This information will be publicly posted.) D. Motivation for the new RRTYPE application? There is no easy way to get from a domain name to a URI. Some mechanisms exists via use of the NAPTR [RFC3403] resource record. That implies quite complicated rules that are simplified via the S-NAPTR [RFC3958] specification. But, the ability to directly look up a URI still exists. This specification uses a prefix based naming mechanism originated in the definition of the SRV [RFC2782] resource record, and the RDATA is a URI, encoded as one text field. See also Section 1 in draft-faltstrom-uri-05.txt. E. Description of the proposed RR type. The format of the URI resource record is as follows: Ownername TTL Class URI Priority Weight Target The URI RR has service information encoded in its ownername. In order to encode the service for a specific owner name one uses service parameters. Valid service parameters used are either Enumservice Registrations registered by IANA, or prefixes used for the SRV resource record. The wire format of the RDATA is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Target / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? The RRTYPE that come closest is the NAPTR resource record. It is for example used in the DDDS and S-NAPTR algorithms. The main problem with the NAPTR is that selection of what record (or records) one is interested in is based on data stored in the RDATA portion of the NAPTR resource record. This, as explained in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further, most applications using NAPTR resource records uses regular expression based rewrite rules for creation of the URI, and that has shown be complicated to implement. The second closest RRTYPE is the SRV record that given a prefixed based naming just like is suggested for the URI resource record, one get back a port number and domain name. This can also be used for creation of a URI, but, only URIs without path components. G. What mnemonic is requested for the new RRTYPE (optional)? URI H. Does the requested RRTYPE make use of any existing IANA Registry or require the creation of a new IANA sub-registry in DNS Parameters? Yes, partially. One of the mechanisms to select a service is to use the Enumservice Registry managed by IANA. Another is to use services and protocols used for SRV records. I. Does the proposal require/expect any changes in DNS servers/ resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? No J. Comments: None --end 5395 template URI-- From jakob@kirei.se Thu Jan 27 07:14:27 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33A143A68E2 for ; Thu, 27 Jan 2011 07:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M8TtxO2RAKP for ; Thu, 27 Jan 2011 07:14:26 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 8C3433A68E7 for ; Thu, 27 Jan 2011 07:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=5v7+ZKNeIreWnk9uh8LRQpygfmN1hr/ShlgCfrPLMcg=; b=JbtO9+8if9d/UmlSX9lyCywNsUDN3qa8PgDFSiZasTEm7zTzue4pcARNpKm1zxLuUjYBCnriyFg7v sAQsLNwr95ffFT4yXD/KthVToL84EIx2xPeJaa4Vp7IQJZPI0VrvppRPuYDd5CuV8ewAOE71tQNyzp lM+gDEwUFes9Oipo= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 27 Jan 2011 16:17:26 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <4D3F233C.7000900@vpnc.org> Date: Thu, 27 Jan 2011 16:17:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D3F233C.7000900@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 15:14:27 -0000 On 25 jan 2011, at 20.23, Paul Hoffman wrote: > Bootstrapping is hard, but once you have done it, you can reuse the = trust logic you used to do it again. Unbound [1] has a very elaborate way (see the source code [2] of = unbound-anchor) of maintaining the root trust anchor. jakob [1] http://www.unbound.net/documentation/unbound-anchor.html [2] http://unbound.nlnetlabs.nl/svn/trunk/smallapp/unbound-anchor.c From paul@xelerance.com Thu Jan 27 07:34:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53B83A68F5 for ; Thu, 27 Jan 2011 07:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bqXUHcFwZ7m for ; Thu, 27 Jan 2011 07:34:55 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id C06133A67E4 for ; Thu, 27 Jan 2011 07:34:55 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id A93ACC522; Thu, 27 Jan 2011 10:37:57 -0500 (EST) Date: Thu, 27 Jan 2011 10:37:57 -0500 (EST) From: Paul Wouters To: Jakob Schlyter In-Reply-To: Message-ID: References: <4D3F233C.7000900@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 15:34:57 -0000 On Thu, 27 Jan 2011, Jakob Schlyter wrote: >> Bootstrapping is hard, but once you have done it, you can reuse the trust logic you used to do it again. > > Unbound [1] has a very elaborate way (see the source code [2] of unbound-anchor) of maintaining the root trust anchor. But that has the same issues we discussed earlier, "You can update it by fetching it from https://data.iana.org/root-anchors/icannbun-dle.pem (and validate it)." Note the possibly human action of "and validate it" Paul From nweaver@icsi.berkeley.edu Thu Jan 27 08:03:58 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952043A682A for ; Thu, 27 Jan 2011 08:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GW4GMOI1z8kY for ; Thu, 27 Jan 2011 08:03:57 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 79CE03A67F4 for ; Thu, 27 Jan 2011 08:03:57 -0800 (PST) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 747CC36A034; Thu, 27 Jan 2011 08:07:01 -0800 (PST) References: <4D3F233C.7000900@vpnc.org> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <10A3D861-EC02-49FF-BBD1-44843378C9CB@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Thu, 27 Jan 2011 08:07:00 -0800 To: Paul Wouters X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 16:03:58 -0000 On Jan 27, 2011, at 7:37 AM, Paul Wouters wrote: > On Thu, 27 Jan 2011, Jakob Schlyter wrote: >=20 >>> Bootstrapping is hard, but once you have done it, you can reuse the = trust logic you used to do it again. >>=20 >> Unbound [1] has a very elaborate way (see the source code [2] of = unbound-anchor) of maintaining the root trust anchor. >=20 > But that has the same issues we discussed earlier, >=20 > "You can update it by fetching it from = https://data.iana.org/root-anchors/icannbun-dle.pem (and validate = it)." >=20 > Note the possibly human action of "and validate it" Stupid question: What is wrong with the proposals where there is just a = historical record of key signing by default, and the URL above as a = backup? Lets face it, 98% of the root key rollovers are going to be benign, on = that once-a-year schedule. So in those cases there actually is no security implications for those = resolvers who have been offline for >1 year to just fetch the chain = through DNS, start with the most recent root key they have, and follow = the chain to the current root key. On the 1% chance that its due to a compromise, there is going to be such = out-of-band chatter that anyone getting it from = https://data.iana.org/root-anchors/icannbun-dle.pem is GOING to be = validated because everyone and his mother will have the SHA hash for = this. Yes, we need to consider 1% cases, but 1% cases do enable = human-in-the-loop. And on the 1% chance its due to someone coming up with a practical = quantum computer, I think this means that all public key right now is = fubared anyway, so its back-to-the-drawing-board for DNSSEC anyway. From hallam@gmail.com Thu Jan 27 08:07:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BEF63A682B for ; Thu, 27 Jan 2011 08:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKJC-fOnXYFL for ; Thu, 27 Jan 2011 08:07:31 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 1CAAD3A682A for ; Thu, 27 Jan 2011 08:07:30 -0800 (PST) Received: by yxt33 with SMTP id 33so742371yxt.31 for ; Thu, 27 Jan 2011 08:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=H7clyGt09ciGNORo/0ncx1URDnfY8qBWeSPNSPMS8nI=; b=e35dkoi/hYO/PdabNZ6HjeV+ZggjUSYUDiPhD7SN5tXgMo2hlC75MYVL9QydLJ1arQ AULR8j7ZRDKgjqDzFry3VPsoR6A+ddw3O6t3K76ZsbdGnjhSB5bW5abIZ979EZKJkw1k OeoSYnEon6o59ZAGJ04e0S5iB2hLOwTftJ/Xc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TBDP1+nJdlsWZbkhvgnSsBjwcumauhRg+EmhqXjPKXIHGgBpnZKW1O4E0f4xgpmT0T 3qeFz4qTfJpbXut0QvbbrtF/TankVUZ9DvJsG8biNQgmR3e+cHLEZF3msCBJij3xPrdG fY6B543yH+ZaPu2gfpXJTMbsL98LxncrdPbiM= MIME-Version: 1.0 Received: by 10.42.229.8 with SMTP id jg8mr2322516icb.461.1296144634266; Thu, 27 Jan 2011 08:10:34 -0800 (PST) Received: by 10.42.155.6 with HTTP; Thu, 27 Jan 2011 08:10:34 -0800 (PST) In-Reply-To: References: <4D3F233C.7000900@vpnc.org> Date: Thu, 27 Jan 2011 11:10:34 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=20cf3043474c80ce98049ad63081 Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 16:07:32 -0000 --20cf3043474c80ce98049ad63081 Content-Type: text/plain; charset=ISO-8859-1 Both your reply and the reply from the big router vendor make it clear to me that you do simply do not understand my proposal. There are some cases in which it is acceptable to have anonymous contributions like this. But in my view big router manufacturers are quite capable of representing themselves directly in IETF and should not have need of intermediaries. Please tell your associate that if this is an issue, they should participate in the group directly. On Wed, Jan 26, 2011 at 4:41 PM, Paul Wouters wrote: > On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote: > > Paul, you came here with an assertion that you were interested in solving >> a particular problem. >> Since then you have changed the problem whenever people suggest an >> alternative that does not match your >> proposed solution. >> > > If I was a major router manufacturer or any other manufacturer, I would >> make sure that there was satisfactory >> control of the ultimate root of trust embedded in my products. >> > > This particular big router vendor has stated to me that using X.509 and > CA's can not > be part of the solution, exactly for the reasons I have mentioned in > previous emails. > > These are their words exactly: > > Frankly, one of the most compelling reasons for wanting to see > ubiquitous DNSSEC is precisely this long, ever changing list of X.509 > CAs, each with its own policies, procedures, personnel, and pressure > points, and each representing an opportunity for total failure of the > whole PKI. X.509 as deployed is a security disaster, and I see > basically no chance of it ever getting better. > > Personally, and I'm hoping to convince [vendor] and everybody else of > this eventually, I would like to see DNSSEC *replace* X.509 as the > PKI for basically everything on the Internet, or at least see all > X.509 trust conditioned on DNSSEC trust. > > > Phillip, it is not just me. Your PKI solution does not fit this > problem. It just creates an additional problem. > > > As the Internet matures and the need to upgrade equipment for purely >> performance issues subsides, service >> lifetimes for network infrastructure is going to be measured in decades. >> Which is something of a problem in >> an industry where Internet time turned out to mean that Netscape took a >> little over five years to go from >> startup, to industry behemoth, to extinction rather than the 80-90 years >> that it took General Motors to >> achieve the same. >> > > You never did give me your professional expert estimate of the amount or > percentage of valid CA's of the latest Netscape Navigator/Communicator > released. I would still be interested in that number to confirm or deny > the usability of Certificate Agencies over a decade long deployment. > > Paul > -- Website: http://hallambaker.com/ --20cf3043474c80ce98049ad63081 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Both your reply and the reply from the big router vendor make it clear to m= e that you do simply do not understand my proposal.

Ther= e are some cases in which it is acceptable to have anonymous contributions = like this. But in my view big router manufacturers are quite capable of rep= resenting themselves directly in IETF and should not have need of intermedi= aries.

Please tell your associate that if this is an issue, th= ey should participate in the group directly.


On Wed, Jan 26, 2011 at 4:41 PM, Paul Wouters <paul@xelerance.com><= /span> wrote:
On Wed, 26 Jan 2011, Phil= lip Hallam-Baker wrote:

Paul, you came here with an assertion that you were interested in solving a= particular problem.
Since then you have changed the problem whenever people suggest an alternat= ive that does not match your
proposed solution.

If I was a major router manufacturer or any other manufacturer, I would mak= e sure that there was satisfactory
control of the ultimate root of trust embedded in my products.

This particular big router vendor has stated to me that using X.509 and CA&= #39;s can not
be part of the solution, exactly for the reasons I have mentioned in previo= us emails.

These are their words exactly:

=A0 Frankly, one of the most compelling reasons for wanting to see
=A0 ubiquitous DNSSEC is precisely this long, ever changing list of X.509<= br> =A0 CAs, each with its own policies, procedures, personnel, and pressure =A0 points, and each representing an opportunity for total failure of the<= br> =A0 whole PKI. X.509 as deployed is a security disaster, and I see
=A0 basically no chance of it ever getting better.

=A0 Personally, and I'm hoping to convince [vendor] and everybody else= of
=A0 this eventually, I would like to see DNSSEC *replace* X.509 as the
=A0 PKI for basically everything on the Internet, or at least see all
=A0 X.509 trust conditioned on DNSSEC trust.


Phillip, it is not just me. Your PKI solution does not fit this
problem. It just creates an additional problem.


As the Internet matures and the need to upgrade equipment for purely perfor= mance issues subsides, service
lifetimes for network infrastructure is going to be measured in decades. Wh= ich is something of a problem in
an industry where Internet time turned out to mean that Netscape took a lit= tle over five years to go from
startup, to industry behemoth, to extinction rather than the 80-90 years th= at it took General Motors to
achieve the same.

You never did give me your professional expert estimate of the amount or percentage of valid CA's of the latest Netscape Navigator/Communicator<= br> released. I would still be interested in that number to confirm or deny
the usability of Certificate Agencies over a decade long deployment.

Paul



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

--20cf3043474c80ce98049ad63081-- From matthew@dempsky.org Thu Jan 27 08:11:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B6C3A67F4 for ; Thu, 27 Jan 2011 08:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-zC1yIbN6uh for ; Thu, 27 Jan 2011 08:11:20 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id C08043A67D3 for ; Thu, 27 Jan 2011 08:11:19 -0800 (PST) Received: by iyi42 with SMTP id 42so1785243iyi.31 for ; Thu, 27 Jan 2011 08:14:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.32.140 with SMTP id c12mr1169896ibd.74.1296144861616; Thu, 27 Jan 2011 08:14:21 -0800 (PST) Received: by 10.231.161.67 with HTTP; Thu, 27 Jan 2011 08:14:21 -0800 (PST) In-Reply-To: References: Date: Thu, 27 Jan 2011 08:14:21 -0800 Message-ID: From: Matthew Dempsky To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext List Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 16:11:22 -0000 On Tue, Jan 25, 2011 at 9:53 AM, Paul Wouters wrote: > A very large router vendor is about to make it mandatory that new devices > they produce use dnssec by default. One issue that comes up with that > is what happens if these devices were off long enough for a rollover to > have happened and the RFC5011 bit/key has been retired. Just upgrade the router firmware using the local network or a USB drive. From hallam@gmail.com Thu Jan 27 08:59:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EFED3A6807 for ; Thu, 27 Jan 2011 08:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc00SMM1Fx2s for ; Thu, 27 Jan 2011 08:59:17 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id F1F283A67C0 for ; Thu, 27 Jan 2011 08:59:16 -0800 (PST) Received: by iyi42 with SMTP id 42so1834982iyi.31 for ; Thu, 27 Jan 2011 09:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=074iKQuXmNi/bsha8TDBw7CqakM8+VqnRJeJjjhF4Uc=; b=WFYerE0OFOBho1uLYT2QaAbzTwESWKClEXVT1CQiW4TQqX8Dgxsvr5HYq3/f1epee5 ocwdVRQDRShDcUeupYshGFwYWxBOuNv1i09GfjbUIel6RppRd1Q4RBtRNIq5AInBc64Q y/DyHTXr9sufQi9dFiiWkh6GL2jIzc3k3gCZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=v7HeyxakjOAqTlaRdScieWQSdXOVfln14OzbSN+ogmiVoUDJtRB3CCFIAzVZsfFY6Q F7BeOAQGybUtj1fzOQINwTByQfar95jOXpdixweqgDp9DBTVNhcVdg+w/U87VlaTINOc 9qM3jITPwQpqYOStVtuSZhwYb4hAGUG3NG7lk= MIME-Version: 1.0 Received: by 10.42.240.133 with SMTP id la5mr2431489icb.327.1296147740671; Thu, 27 Jan 2011 09:02:20 -0800 (PST) Received: by 10.42.155.6 with HTTP; Thu, 27 Jan 2011 09:02:20 -0800 (PST) In-Reply-To: References: <4D3F233C.7000900@vpnc.org> Date: Thu, 27 Jan 2011 12:02:20 -0500 Message-ID: From: Phillip Hallam-Baker To: Alex Nicoll Content-Type: multipart/alternative; boundary=20cf305644eba8bfff049ad6e9cf Cc: "dnsext@ietf.org" Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 16:59:20 -0000 --20cf305644eba8bfff049ad6e9cf Content-Type: text/plain; charset=ISO-8859-1 [apols for top posting, referring to multiple posts here] Good cryptographic practice depends on the resources you have available and the algorithms involved. It is important to carry out a risk assessment for the specific instance. There are two considerations here, one is the risk of a cryptographic compromise due to a cryptanalytic attack, compromise of keying material etc, the second is the risk of failure due to operational errors, either at the root or in infrastructure that depends on the root. The ICANN DNS root management processes are modelled on a set of practices that have been in use in the NSA and other places for forty years. As such, the risk of compromise is negligible. But the risk that the operational constraints imposed are going to prove impractical is significant. Back in the 1980s, all the algorithms we had available were suspect at best or known to be marginal with respect to the computing hardware that was emerging. So limiting the cryptoperiod was very important. We knew that breaking RSA1024 was not going to be cost effective, we had no assurance that it would be impossible. So in the 1980s, refreshing keying material on a regular basis was essential even though we understood that the refresh mechanism would necessarily introduce a vulnerability. In the 1990s, that tradeoff started to become more marginal and today we have algorithms such as AES and RSA2048 and ECC that make the risk of cryptanalysis insignificant compared to the risk of operational compromise. In this case rekey at the root raises two sets of operational concerns, the first is for ICANN and its contractors, the second is for relying parties. ICANN is a single point of failure but it can pour resources into the problem of providing security. They use offline hardware that never touches a network, they have tier6 physical security, they have key splitting etc. etc. We really should not need to worry about the risk of technical compromise of an offline key with a lifetime of 20 years that is used to sign the root KSKs once a year. There is a significant political concern that might well cause people to ask if we would want to rely on a single 20 year embedded key held by a corporation that we cannot necessarily rely on being around in 20 years time. Back in 1995 I would have thought it inconceivable that Lotus would be acquired by IBM in a hostile takeover or that Digital would be acquired by Compaq. I have seen several non-profits and not-for-profits morph from being voluntary organizations for the public good to commercial competitors and one has become a public company. We have also seen recently a situation where the staff of a public CA was given the choice of issuing a known fraudulent certificate or going to jail. The only protection that an organization can obtain that prevents that type of coercion is to establish a technical infrastructure that makes that type of coercion pointless. Limiting the validity period of the root keys to a year and not having a master root would appear to me to be a reasonable personal security control. So I think that if people did want a 20 year root, they would have to look to more than one party to be the signer. Otherwise the risk of being coerced would be unacceptably high. On Wed, Jan 26, 2011 at 1:09 PM, Alex Nicoll wrote: > Gents (and lurking ladies) - > > Maybe I'm missing something here, but I thought that the whole purpose of > DNSKEY rotation was to adhere to the basic cryptography tenet that a key is > only good for so long, and then there's too great a risk of someone cracking > it. If we implement an entire schema for historical keys that chains trust, > don't we introduce the capability for long term key attacks to compromise > the whole system? I know I could do this for several know encryption > schemes now - there's no reason advances in computing power cannot do it for > new ones. > > Long story short - wouldn't this shoot us in the foot? > > -Alex > > -----Original Message----- > From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf > Of Paul Wouters > Sent: Wednesday, January 26, 2011 1:05 PM > To: Phillip Hallam-Baker > Cc: Paul Hoffman; dnsext@ietf.org > Subject: Re: [dnsext] historal root keys for upgrade path? > > On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote: > > > Which CA(s)s would we have to make the products trust? IANA seems to > > be using Godaddy today. Is that guaranteed to last forever? If not, > > then how is a device supposed to know which CA IANA has chosen at some > > time in the future? Do we just have to trust all 1500+ commercial CA? > > And deal with all the revocations? And how to install new ones, using > > what trust? And remember, this is a switch or router, not a browser or an > OS with the "update now" button. > > > Use a Quorate Root then. > > > > Multiple Signers, are recognized. A valid key must be counter signed by a > quorum of the recognized signers. > > Maybe we can add even more complexity to this? > > The path here is extremely clear. It hopes from a common trusted key to new > keys via intermediate steps, all of which are signed. To bring in any other > outside trusted third party with its own pletora of trust anchor update > issues is not solving the problem. You are just moving the problem. Worse, > you are moving the problem away from the original trusted parties into a > hypothetical bag of other trusted parties with even less clear mandates. > > > As Ed Lewis points out, these are really tricky trust problems and > > there are good reasons not to want to trust any monolithic single rooted > scheme. > > Please either specifically mention the reasons, or stop waiving your > generalities. DNSSEC is already trusting "monolithic single rooted scheme", > so suggesting we destroy that is moot. There is no valid reason to bring in > third parties. Let alone insist that validating resolvers need to gain ASN.1 > parsers and X.509 trust anchors. Seriously, grab a 10 year old browser and > tell me how well this "proven technology" > works? How many of those CA's are still valid today? How could we have > guaranteed to have picked one that is still active today - provided there is > any? > > We already have a fully functional path of trust, from root key to root > key, that is validatable by DNSSEC. > > > There are much larger International IT efforts than DNSSEC that have > > collapsed due to failure to agree on this type of issue. > > Yeah, the Government of Canada's Entrust X.509 scheme comes to mind....... > > Paul > _______________________________________________ > 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 > -- Website: http://hallambaker.com/ --20cf305644eba8bfff049ad6e9cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [apols for top posting, referring to multiple posts here]


Good cryptographic practice depends on the resources you h= ave available and the algorithms involved.=A0It is important to carry out a= risk assessment for the specific instance.=A0

There are two considerations here, one is the risk of a= cryptographic compromise due to a cryptanalytic attack, compromise of keyi= ng material etc, the second is the risk of failure due to operational error= s, either at the root or in infrastructure that depends on the root.

The ICANN DNS root management processes are modelled on= a set of practices that have been in use in the NSA and other places for f= orty years. As such, the risk of compromise is negligible. But the risk tha= t the operational constraints imposed are going to prove impractical is sig= nificant.


Back in the 1980s, all the algorithms we= had available were suspect at best or known to be marginal with respect to= the computing hardware that was emerging. So limiting the cryptoperiod was= very important. We knew that breaking RSA1024 was not going to be cost eff= ective, we had no assurance that it would be impossible.

So in the 1980s, refreshing keying material on a regula= r basis was essential even though we understood that the refresh mechanism = would necessarily introduce a vulnerability. In the 1990s, that tradeoff st= arted to become more marginal and today we have algorithms such as AES and = RSA2048 and ECC that make the risk of cryptanalysis insignificant compared = to the risk of operational compromise.


In this case rekey at the root raises tw= o sets of operational concerns, the first is for ICANN and its contractors,= the second is for relying parties.

ICANN is a sin= gle point of failure but it can pour resources into the problem of providin= g security. They use offline hardware that never touches a network, they ha= ve tier6 physical security, they have key splitting etc. etc.

We really should not need to worry about the risk of te= chnical compromise of an offline key with a lifetime of 20 years that is us= ed to sign the root KSKs once a year.


There is= a significant political concern that might well cause people to ask if we = would want to rely on a single 20 year embedded key held by a corporation t= hat we cannot necessarily rely on being around in 20 years time.=A0

Back in 1995 I would have thought it inconceivable that= Lotus would be acquired by IBM in a hostile takeover or that Digital would= be acquired by Compaq. I have seen several non-profits and not-for-profits= morph from being voluntary organizations for the public good to commercial= competitors and one has become a public company.=A0

We have also seen recently a situation where the staff = of a public CA was given the choice of issuing a known fraudulent certifica= te or going to jail.

The only protection that an o= rganization can obtain that prevents that type of coercion is to establish = a technical infrastructure that makes that type of coercion pointless.

Limiting the validity period of the root keys to a year= and not having a master root would appear to me to be a reasonable persona= l security control.=A0


So I think t= hat if people did want a 20 year root, they would have to look to more than= one party to be the signer. Otherwise the risk of being coerced would be u= nacceptably high.


On Wed, Jan 26, 2011 at = 1:09 PM, Alex Nicoll <anicoll@cert.org> wrote:
Gents (and lurking ladies) -

Maybe I'm missing something here, but I thought that the whole purpose = of DNSKEY rotation was to adhere to the basic cryptography tenet that a key= is only good for so long, and then there's too great a risk of someone= cracking it. =A0If we implement an entire schema for historical keys that = chains trust, don't we introduce the capability for long term key attac= ks to compromise the whole system? =A0I know I could do this for several kn= ow encryption schemes now - there's no reason advances in computing pow= er cannot do it for new ones.

Long story short - wouldn't this shoot us in the foot?

-Alex

-----Original Message-----
From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.or= g] On Behalf Of Paul Wouters
Sent: Wednesday, January 26, 2011 1= :05 PM
To: Phillip Hallam-Baker
Cc: Paul Hoffman; dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path?

On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote:

> Which CA(s)s would we have to make the products trust? IANA seems to > be using Godaddy today. Is that guaranteed to last forever? If not, > then how is a device supposed to know which CA IANA has chosen at some=
> time in the future? Do we just have to trust all 1500+ commercial CA?<= br> > And deal with all the revocations? And how to install new ones, using<= br> > what trust? And remember, this is a switch or router, not a browser or= an OS with the "update now" button.

> Use a Quorate Root then.
>
> Multiple Signers, are recognized. A valid key must be counter signed b= y a quorum of the recognized signers.

Maybe we can add even more complexity to this?

The path here is extremely clear. It hopes from a common trusted key to new= keys via intermediate steps, all of which are signed. To bring in any othe= r outside trusted third party with its own pletora of trust anchor update i= ssues is not solving the problem. You are just moving the problem. Worse, y= ou are moving the problem away from the original trusted parties into a hyp= othetical bag of other trusted parties with even less clear mandates.

> As Ed Lewis points out, these are really tricky trust problems and
> there are good reasons not to want to trust any monolithic single root= ed scheme.

Please either specifically mention the reasons, or stop waiving your genera= lities. DNSSEC is already trusting "monolithic single rooted scheme&qu= ot;, so suggesting we destroy that is moot. There is no valid reason to bri= ng in third parties. Let alone insist that validating resolvers need to gai= n ASN.1 parsers and X.509 trust anchors. Seriously, grab a 10 year old brow= ser and tell me how well this "proven technology"
works? How many of those CA's are still valid today? How could we have = guaranteed to have picked one that is still active today - provided there i= s any?

We already have a fully functional path of trust, from root key to root key= , that is validatable by DNSSEC.

> There are much larger International IT efforts than DNSSEC that have > collapsed due to failure to agree on this type of issue.

Yeah, the Government of Canada's Entrust X.509 scheme comes to mind....= ...

Paul
_____________________________= __________________
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



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

--20cf305644eba8bfff049ad6e9cf-- From fweimer@bfk.de Thu Jan 27 09:15:09 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2909C28C14E for ; Thu, 27 Jan 2011 09:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GXKNm--ZVFE for ; Thu, 27 Jan 2011 09:15:08 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 0135F28C145 for ; Thu, 27 Jan 2011 09:15:06 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PiVTx-0007Pt-CN; Thu, 27 Jan 2011 17:18:05 +0000 Received: by bfk.de with local id 1PiVTx-000547-85; Thu, 27 Jan 2011 17:18:05 +0000 To: Paul Wouters References: <4D3F233C.7000900@vpnc.org> From: Florian Weimer Date: Thu, 27 Jan 2011 17:18:05 +0000 In-Reply-To: (Paul Wouters's message of "Wed\, 26 Jan 2011 10\:06\:41 -0500 \(EST\)") Message-ID: <82vd1amfjm.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:15:09 -0000 * Paul Wouters: > Remember this has to work on a product that has just been factory > defaulted to a config from 10 years ago, and the device is EOL with > no firmware upgrades. Why? Where does this requirement come from? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer@bfk.de Thu Jan 27 09:18:30 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B8F28C145 for ; Thu, 27 Jan 2011 09:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KlSO3MwBSfP for ; Thu, 27 Jan 2011 09:18:29 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 68A0628C141 for ; Thu, 27 Jan 2011 09:18:29 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PiVXI-0007ib-32; Thu, 27 Jan 2011 17:21:32 +0000 Received: by bfk.de with local id 1PiVXH-0001Gv-SK; Thu, 27 Jan 2011 17:21:31 +0000 To: Nicholas Weaver References: <4D3F233C.7000900@vpnc.org> <10A3D861-EC02-49FF-BBD1-44843378C9CB@icsi.berkeley.edu> From: Florian Weimer Date: Thu, 27 Jan 2011 17:21:31 +0000 In-Reply-To: <10A3D861-EC02-49FF-BBD1-44843378C9CB@icsi.berkeley.edu> (Nicholas Weaver's message of "Thu\, 27 Jan 2011 08\:07\:00 -0800") Message-ID: <82r5bymfdw.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:18:30 -0000 * Nicholas Weaver: > Lets face it, 98% of the root key rollovers are going to be benign, > on that once-a-year schedule. I'm pretty sure that the first scheduled root KSK rollover will be indefinitely postponed in 2014. 8-) --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From paul@xelerance.com Thu Jan 27 09:44:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ABDC3A69B7 for ; Thu, 27 Jan 2011 09:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY0JPs3BIv4h for ; Thu, 27 Jan 2011 09:44:21 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 60C253A698E for ; Thu, 27 Jan 2011 09:43:55 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id E886FC522; Thu, 27 Jan 2011 12:46:58 -0500 (EST) Date: Thu, 27 Jan 2011 12:46:58 -0500 (EST) From: Paul Wouters To: Florian Weimer In-Reply-To: <82vd1amfjm.fsf@mid.bfk.de> Message-ID: References: <4D3F233C.7000900@vpnc.org> <82vd1amfjm.fsf@mid.bfk.de> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:44:22 -0000 On Thu, 27 Jan 2011, Florian Weimer wrote: >> Remember this has to work on a product that has just been factory >> defaulted to a config from 10 years ago, and the device is EOL with >> no firmware upgrades. > > Why? Where does this requirement come from? It was an example. The (perhaps implicit) requirement is that a device has no unneccessary limitations that it becomes unusable at a specific expiry date within a time period where the hardware and software is expected to still be fully functional. If a device becomes obsolete because the world has moved into unpredicted direction the vendor could not forsee, that is acceptable. However, producing equipment that you know is going to fail on a certain date only three years into the future is most probably not. Paul From brian.peter.dickson@gmail.com Thu Jan 27 09:46:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB4A3A69B2 for ; Thu, 27 Jan 2011 09:46:16 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgghG-SygXYs for ; Thu, 27 Jan 2011 09:46:15 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 672113A6996 for ; Thu, 27 Jan 2011 09:46:15 -0800 (PST) Received: by fxm9 with SMTP id 9so2631162fxm.31 for ; Thu, 27 Jan 2011 09:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qW7+eFsPeQ1t3DMElFg6hbO6TZ1AwEGylD5tU0WEBkA=; b=qfD1YO4yfgyTEqRqS7wlYcvbWrK6Qi+eNMM775KlU3DNLWBzB6EXGJ8CFy8MEIT6kZ H6ZmAIk1OnIDqJJ9AtU/mCQCbhGNVRL1QWx5W4kNuNnkzMAsOn0J/tRaS8NzAa87v4j3 il28ya+6yD/nzxbtqLk5/J296rWFactUW/VPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xpLtubko4qkoHzNfw1gox4sC+AS4htrYWzhje79OSAJZw2ru8KjCp+GrN/CwsE7IOw aQjzBsx/QLngjLGVa96iSdfY/rXinYwOSiDl0BuuzTSjNl46CxeLafO3qBiGh1v9F77O nNUZm/Ii5RNBBFBDS0W3Rt93vFrRQDk3MS7vg= MIME-Version: 1.0 Received: by 10.223.123.142 with SMTP id p14mr1224018far.56.1296150558502; Thu, 27 Jan 2011 09:49:18 -0800 (PST) Received: by 10.223.108.71 with HTTP; Thu, 27 Jan 2011 09:49:18 -0800 (PST) In-Reply-To: <82vd1amfjm.fsf@mid.bfk.de> References: <4D3F233C.7000900@vpnc.org> <82vd1amfjm.fsf@mid.bfk.de> Date: Thu, 27 Jan 2011 13:49:18 -0400 Message-ID: From: Brian Dickson To: Florian Weimer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:46:16 -0000 On Thu, Jan 27, 2011 at 1:18 PM, Florian Weimer wrote: > * Paul Wouters: > >> Remember this has to work on a product that has just been factory >> defaulted to a config from 10 years ago, and the device is EOL with >> no firmware upgrades. > > Why? =A0Where does this requirement come from? Operational reality... There are two resource issues. One is network engineers who are DNSSEC-knowledgeable. (In numbers, routers >> managed customers >> noc staff >> network engineers >> DNS network engineers >> DNSSEC network engineers.) The other is the life of a "factory default config". It goes from $vendor, to $flash-vendor, to $mfg, to $shipping, to $customs, to $distributor, to $customer. In some cases, $customer has a large inventory, to supply their $end-custom= ers. And in some cases, $end-customer has both a live router, and cold spare (in a box), purchased at the same time. Think MTBF... So, there are cases where both large numbers of $customer get a new box, which has a slightly-outdated trust anchor (because roll-over happened during the supply chain process), and where moderate numbers of $customer eventually have a "new" box which is quite old. Solving for one solves for both, ideally. Regardless of oversimplification, having $vendor ship all routers with DNSSEC not only supported, but enabled by default, should be commended. We complain about adoption delays. This, we should be falling over ourselves to assist on, or never, ever complain again about adoption. Seriously. Brian From jabley@hopcount.ca Thu Jan 27 10:25:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9847A3A67ED for ; Thu, 27 Jan 2011 10:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWqxpipZHIqd for ; Thu, 27 Jan 2011 10:25:36 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id CEF163A67BD for ; Thu, 27 Jan 2011 10:25:36 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PiWeE-0002Jw-KJ; Thu, 27 Jan 2011 18:32:55 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <10A3D861-EC02-49FF-BBD1-44843378C9CB@icsi.berkeley.edu> Date: Thu, 27 Jan 2011 13:28:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2BC28AF0-9132-4FFD-9FA6-FCEC29A1D471@hopcount.ca> References: <4D3F233C.7000900@vpnc.org> <10A3D861-EC02-49FF-BBD1-44843378C9CB@icsi.berkeley.edu> To: Nicholas Weaver X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 18:25:37 -0000 On 2011-01-27, at 11:07, Nicholas Weaver wrote: > Lets face it, 98% of the root key rollovers are going to be benign, on = that once-a-year schedule. There is no established schedule for rolling the root zone's KSK. All we = have said to date is that we don't expect to do it any time soon, = because it's not clear that support for automated handling of such an = event is well-deployed in clients. Joe From vixie@vix.com Thu Jan 27 10:48:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A093A69B9 for ; Thu, 27 Jan 2011 10:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HYY3Wr9RoEv for ; Thu, 27 Jan 2011 10:48:53 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 7EC5E3A67F7 for ; Thu, 27 Jan 2011 10:48:53 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 879C7A1058 for ; Thu, 27 Jan 2011 18:51:56 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Thu, 27 Jan 2011 17:21:31 GMT." <82r5bymfdw.fsf@mid.bfk.de> References: <4D3F233C.7000900@vpnc.org> <10A3D861-EC02-49FF-BBD1-44843378C9CB@icsi.berkeley.edu> <82r5bymfdw.fsf@mid.bfk.de> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Thu, 27 Jan 2011 18:51:56 +0000 Message-ID: <49385.1296154316@nsa.vix.com> Sender: vixie@vix.com Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 18:48:54 -0000 > From: Florian Weimer > Date: Thu, 27 Jan 2011 17:21:31 +0000 > > I'm pretty sure that the first scheduled root KSK rollover will be > indefinitely postponed in 2014. 8-) agreed, this seems likely, though undesireable. From vixie@vix.com Thu Jan 27 11:00:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CEB53A69CB for ; Thu, 27 Jan 2011 11:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-BjA0KcN+wQ for ; Thu, 27 Jan 2011 11:00:36 -0800 (PST) Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 9611F3A6828 for ; Thu, 27 Jan 2011 11:00:36 -0800 (PST) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 28389A1019 for ; Thu, 27 Jan 2011 19:03:40 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Thu, 27 Jan 2011 13:28:26 EST." <2BC28AF0-9132-4FFD-9FA6-FCEC29A1D471@hopcount.ca> References: <4D3F233C.7000900@vpnc.org> <10A3D861-EC02-49FF-BBD1-44843378C9CB@icsi.berkeley.edu> <2BC28AF0-9132-4FFD-9FA6-FCEC29A1D471@hopcount.ca> X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22) Date: Thu, 27 Jan 2011 19:03:40 +0000 Message-ID: <50123.1296155020@nsa.vix.com> Sender: vixie@vix.com Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:00:37 -0000 > From: Joe Abley > Date: Thu, 27 Jan 2011 13:28:26 -0500 > > There is no established schedule for rolling the root zone's KSK. All > we have said to date is that we don't expect to do it any time soon, > because it's not clear that support for automated handling of such an > event is well-deployed in clients. under what conditions can you imagine that changing? (for me it's the null set.) From brian.peter.dickson@gmail.com Thu Jan 27 11:04:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05A963A6818 for ; Thu, 27 Jan 2011 11:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ni8EW8YtXsGv for ; Thu, 27 Jan 2011 11:04:47 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C3A283A6835 for ; Thu, 27 Jan 2011 11:04:46 -0800 (PST) Received: by fxm9 with SMTP id 9so2715487fxm.31 for ; Thu, 27 Jan 2011 11:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8AeuMTYzJ5QCy+ugkfCzL94GoZPQ90/TnwQVEuWJ13o=; b=SkIKFkcbTX/cK7lJBmyvjQWktFmsxUmMU51KsMNDyC2YYiQ27lghukJNuTuy+Xoclx fC8Zt1nzgW4V3abm1iWK92zaxUPRKpZk6knYqolZFfZ9tmLEbIAqiXhpXX1FjAa2Omk4 yicRL+38Dx05/LoIDJihIbrl/UAj6naMxb3/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mdzBtIYj8lFNIN9Tn4U8fMS/zSioh/W6A7HARfWf01fzPedwdIggwRm7M1hUfN2oHN mcexG6nQo+MFrtBv1wExu4Hkp1BxAneapRMOYdSt/LCKoq5csF8Z+xH0BJARvrcCORso tjicwkflrn3wrjksaTf0T0SJqI35nJ8ZO4IjI= MIME-Version: 1.0 Received: by 10.223.123.142 with SMTP id p14mr1307256far.56.1296155138393; Thu, 27 Jan 2011 11:05:38 -0800 (PST) Received: by 10.223.108.71 with HTTP; Thu, 27 Jan 2011 11:05:38 -0800 (PST) In-Reply-To: References: <4D3F233C.7000900@vpnc.org> <82vd1amfjm.fsf@mid.bfk.de> Date: Thu, 27 Jan 2011 15:05:38 -0400 Message-ID: From: Brian Dickson To: Florian Weimer Content-Type: text/plain; charset=ISO-8859-1 Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:04:48 -0000 On Thu, Jan 27, 2011 at 1:49 PM, Brian Dickson wrote: > We complain about adoption delays. This, we should be falling over > ourselves to assist on, or never, ever complain again about adoption. > Seriously. /* *mouth = money */ Open question, to whoever feels like answering it: Would the following, as a general mechanism for publishing someone else's DNSKEY (securely) work? (Here, "foreign" means, we don't hold the private keys) (1) Using a current, known-good trust anchor, retrieve and validate the (foreign) DNSKEY data (possibly plural). (2) For every algorithm in the set of foreign DNSKEY data : (2a) Generate (one time only!!!) a new public/private key pair for our own (local) DNSKEY (2b) Combine the local and foreign DNSKEY data into the apex of our own zone file, for which we are authoritative. (2c) Sign the DNSKEYs with our private keys (2d) RRSIGs signed by our DNSKEYs are the only RRSIGs, and there is one for every DNSKEY algorithm present, so even "strict" validators should be happy (3) Provide our (permanent) public keys as trust anchors, to whoever will use our zone as a "bootstrap" for the foreign (possibly changing) DNSKEYs. (4) As necessary, i.e. whenever any foreign DNSKEY needs to be updated, added/deleted, make corresponding adds/changes to our DNSKEY set, and re-sign the RRSET NB - the same foreign DNSKEYs can be kept in multiple zones, so that specific instance usage can be tracked over time. E.g. over time, the set of algorithms required by the foreign keys may change, and rather than continue to sign with a superset of historically-used algorithms, newer instances of the zone get signed only with new local DNSKEYs for the current algorithms. Older zone instances continue being signed with the older keys/algorithms, so there could be a weakness related to use of them, but that would be limited to clients with old keys, which would expect to tail off over time (drastically, perhaps). These zones would be used only for bootstrapping DNSKEY data used for "real" trust anchors, and could be discarded once the "real" trust anchor has been validated (and *only* then). The bootstrap process would need to rely on DNSSEC-unknown (unvalidated) data, to reach the trust-anchored zone, but the fact that the zone is signed with the trust anchor itself, provides "enough" security to be considered "secure", IMHO. Brian From brian.peter.dickson@gmail.com Thu Jan 27 11:11:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75EBD3A69E3 for ; Thu, 27 Jan 2011 11:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.154 X-Spam-Level: X-Spam-Status: No, score=-3.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8xp0Ld5Jq2f for ; Thu, 27 Jan 2011 11:11:47 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 81E0A3A69F2 for ; Thu, 27 Jan 2011 11:11:46 -0800 (PST) Received: by fxm9 with SMTP id 9so2722932fxm.31 for ; Thu, 27 Jan 2011 11:14:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NC1txP70fuHahicYRE5W9Z1cIuqap1yWJQKO4r1y4WY=; b=gq77j0mFQp+0jTD28+qOmzEWZPY3rWGd8JVrs96brId+Nj63/39SC5z1qPj77EC4Jh nqSUyRd4ty2Kk98LdNvMtMOelzENUW9tT9UCAuePTVpxWv8yozzp5mTWVGIr32Hf4oK3 275HGK3lXgb838elzjj2h74kk4BLzWEJEfOSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EIlP0PsoZwDM/WTQc25RjJYZTBfuhzo3AmspgT9YtMpf/Lmd/nWHrvEI00y6WTG4F6 WjMTuKCLfzmpLHshfJbLnT3Mjwg2Osw4swpe8tF6ZmnMwTxqNXlud/Co3uoEBM7uYa8d PCPVxl1rf2J2IEDkK+V+oMZA49eo8Jk9G5cLI= MIME-Version: 1.0 Received: by 10.223.101.135 with SMTP id c7mr1293034fao.76.1296155508113; Thu, 27 Jan 2011 11:11:48 -0800 (PST) Received: by 10.223.108.71 with HTTP; Thu, 27 Jan 2011 11:11:47 -0800 (PST) In-Reply-To: References: <4D3F233C.7000900@vpnc.org> <82vd1amfjm.fsf@mid.bfk.de> Date: Thu, 27 Jan 2011 15:11:47 -0400 Message-ID: From: Brian Dickson To: Florian Weimer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:11:48 -0000 On Thu, Jan 27, 2011 at 1:49 PM, Brian Dickson wrote: > On Thu, Jan 27, 2011 at 1:18 PM, Florian Weimer wrote: >> * Paul Wouters: >> >>> Remember this has to work on a product that has just been factory >>> defaulted to a config from 10 years ago, and the device is EOL with >>> no firmware upgrades. >> >> Why? =A0Where does this requirement come from? > > Regardless of oversimplification, having $vendor ship all routers with > DNSSEC not only supported, but enabled by default, should be > commended. BTW, the reason we should consider this a really big win, is the following observation for use cases: (1) $Enterprise deploys new $router or $switch in their infrastructure (2) $router/$switch has DNSSEC configured on by default, and presumably successfully bootstraps its valid root trust anchor (3) $Enterprise configures DHCP on $router/$switch, using $router/$switch as the validating (non-stub?) resolver (4) $Enterprise desktops use physically-secure infrastructure to the resolver, which does validated DNSSEC resolution. Note that $desktop does not strictly need DNSSEC. (5) #WIN Brian From paul@xelerance.com Thu Jan 27 12:21:10 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD9C3A6A4A for ; Thu, 27 Jan 2011 12:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIf9XVRBf0Ga for ; Thu, 27 Jan 2011 12:21:09 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 68C813A6A16 for ; Thu, 27 Jan 2011 12:21:08 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 79DCBBF8B; Thu, 27 Jan 2011 15:24:11 -0500 (EST) Date: Thu, 27 Jan 2011 15:24:10 -0500 (EST) From: Paul Wouters To: Brian Dickson In-Reply-To: Message-ID: References: <4D3F233C.7000900@vpnc.org> <82vd1amfjm.fsf@mid.bfk.de> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:21:10 -0000 On Thu, 27 Jan 2011, Brian Dickson wrote: > Open question, to whoever feels like answering it: > Would the following, as a general mechanism for publishing someone > else's DNSKEY (securely) work? > (Here, "foreign" means, we don't hold the private keys) > > (1) Using a current, known-good trust anchor, retrieve and validate > the (foreign) DNSKEY data (possibly plural). > (2) For every algorithm in the set of foreign DNSKEY data : > (2a) Generate (one time only!!!) a new public/private key pair for > our own (local) DNSKEY > (2b) Combine the local and foreign DNSKEY data into the apex of our > own zone file, for which we are authoritative. > (2c) Sign the DNSKEYs with our private keys Now you have just moved the problem. I need this DNSKEY as trust anchor. How do I know this will not be rolled and how to I get historic data on this key. Paul From hallam@gmail.com Thu Jan 27 12:31:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50393A696B for ; Thu, 27 Jan 2011 12:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-NeRR88q5zi for ; Thu, 27 Jan 2011 12:31:06 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id DD1B73A6A3C for ; Thu, 27 Jan 2011 12:31:05 -0800 (PST) Received: by gyd12 with SMTP id 12so895078gyd.31 for ; Thu, 27 Jan 2011 12:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rvldOEoK0WVRzbMQdj7//annYOIL7Lbrdodq4XPNYSE=; b=aWSsh/gKkCV3my0K7Vi3vLiyiTdhH/tMH5+VKTUFeCiZKea4VwWdYa19DHHHoWsrsv 8RPLPMEIWiRNleadS0wYcGPYzjEVMXNAAkTW5yC2pPH5PTqhqHwYY8lY+HbUGvc3tFxd Gr3AVGDUDHwgEEqrm1gT/9lvyxC2AnEAM0k20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xYXt7hqEG4gDBjMq/oCbbUbhktPZ62GsWLXPw2ZKfxcekTXcdzIwBAl5tJo2LJSUM+ Ii4l6UDowlJ0DVvbCyg417S/SBN8OBdhT36I3xT22s/wC5bv4hP8H6YlgP/ebpk2qz10 rUGJWvGprz4YivaqsIVue7M6GLPuZaHZsL0hY= MIME-Version: 1.0 Received: by 10.100.195.12 with SMTP id s12mr938942anf.18.1296160449810; Thu, 27 Jan 2011 12:34:09 -0800 (PST) Received: by 10.100.109.16 with HTTP; Thu, 27 Jan 2011 12:34:04 -0800 (PST) In-Reply-To: <49385.1296154316@nsa.vix.com> References: <4D3F233C.7000900@vpnc.org> <10A3D861-EC02-49FF-BBD1-44843378C9CB@icsi.berkeley.edu> <82r5bymfdw.fsf@mid.bfk.de> <49385.1296154316@nsa.vix.com> Date: Thu, 27 Jan 2011 15:34:04 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Vixie Content-Type: multipart/alternative; boundary=0016e644c6302ed194049ad9dfc6 Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:31:07 -0000 --0016e644c6302ed194049ad9dfc6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 27, 2011 at 1:51 PM, Paul Vixie wrote: > > From: Florian Weimer > > Date: Thu, 27 Jan 2011 17:21:31 +0000 > > > > I'm pretty sure that the first scheduled root KSK rollover will be > > indefinitely postponed in 2014. 8-) > > agreed, this seems likely, though undesireable. Why undesirable? If the root KSK is compromised the consequences will be exhausted long before the scheduled rollover occurs. People would be required to get on planes and roll a new root. DNSSEC keys are not designed to support encryption of stored data, non-repudiation or other requirements that would normally motivate rolling the root key. The only possible motivation for rolling the DNSSEC root KSK would be to limit the length of time that an attacker had to work on the problem. That really does not make much sense unless the period between rolls is short with respect to improvements in hardware. Currently Moores law and the expansion of the net mean that computing resources available to an attacker approximately double year on year (more machines plus faster machines). So after 4 years a cracking effort should be proceeding at 8 times the rate it did in the first year and the contribution to the effort from the first year represents only 1/15th = 6.7% of the cumulative effort. If the cracking goes on another year, the contribution from the first year is only 3% and will continue to diminish exponentially. It follows that if you are going to mount an attack using a botnet or pooled resources, there is really little point in attempting any effort that you do not expect to finish within 4-6 years. If you have a key that you expect will take 4 years to break (accounting for improvements in speed) and start on 1 Jan 2011, you would expect to finish 1 Jan 2015. If you decide to delay your start by a year to 1 Jan 2012, the expected end date would be some time in Feb 2015 So a policy that requires rolls at 4 year increments would appear to offer no additional security over a policy to never roll the keys at all unless the security of the algorithm itself was in question. [Obviously people can argue that the increase in resources is faster or slower than doubling each year, but we know Moore's law is 18 months and we know that social networks get bigger so I think my figures are probably conservative here] -- Website: http://hallambaker.com/ --0016e644c6302ed194049ad9dfc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 27, 2011 at 1:51 PM, Paul Vi= xie <vixie@isc.org> wrote:
> From: Florian Weimer <fweimer@bfk= .de>
> Date: Thu, 27 Jan 2011 17:21:31 +0000
>
> I'm pretty sure that the first scheduled root KSK rollover will be=
> indefinitely postponed in 2014. 8-)

agreed, this seems likely, though undesireable.

=
Why undesirable?

If the root KSK is com= promised the consequences will be exhausted long before the scheduled rollo= ver occurs. People would be required to get on planes and roll a new root.<= /div>

DNSSEC keys are not designed to support encryption of s= tored data, non-repudiation or other requirements that would normally motiv= ate rolling the root key.

The only possible motiva= tion for rolling the DNSSEC root KSK would be to limit the length of time t= hat an attacker had to work on the problem. That really does not make much = sense unless the period between rolls is short with respect to improvements= in hardware.


Currently Moores law and the expansion o= f the net mean that computing resources available to an attacker approximat= ely double year on year (more machines plus faster machines).

So after 4 years a cracking effort should be proceeding at 8= times the rate it did in the first year and the contribution to the effort= from the first year represents only 1/15th =3D 6.7% of the cumulative effo= rt.

If the cracking goes on another year, the contribution = from the first year is only 3% and will continue to diminish exponentially.=


It follows that if you are going t= o mount an attack using a botnet or pooled resources, there is really littl= e point in attempting any effort that you do not expect to finish within 4-= 6 years.

If you have a key that you expect will take 4 years to = break (accounting for improvements in speed) and start on 1 Jan 2011, you w= ould expect to finish 1 Jan 2015. If you decide to delay your start by a ye= ar to 1 Jan 2012, the expected end date would be some time in Feb 2015

So a policy that requires rolls at 4 year increments wo= uld appear to offer no additional security over a policy to never roll the = keys at all unless the security of the algorithm itself was in question.


[Obviously people can argue that the inc= rease in resources is faster or slower than doubling each year, but we know= Moore's law is 18 months and we know that social networks get bigger s= o I think my figures are probably conservative here]



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

--0016e644c6302ed194049ad9dfc6-- From brian.peter.dickson@gmail.com Thu Jan 27 12:45:30 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551033A6916 for ; Thu, 27 Jan 2011 12:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nb9KY3xLES0 for ; Thu, 27 Jan 2011 12:45:29 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 297363A68A7 for ; Thu, 27 Jan 2011 12:45:28 -0800 (PST) Received: by fxm9 with SMTP id 9so2827019fxm.31 for ; Thu, 27 Jan 2011 12:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aUxMpYGBBqQllOe1govxPXRhB9ZvVejMQcNc8UiTykw=; b=Mj9/Ubqrg4gNhiDebctYVza8HsTE7LUvsoOtfaW8Q2F9sYU8jjonyapi2UGw2miWMd aS27cE+YE5Ww8/+rKb6ZFjMq0jrjCtyFaB4En0jhI18Il+ZaqkaR6cjK3F6ItC5bpP1O +6dzkxH+WPNQ8uwBA2OuxG8DhOTTlgHsmzxq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BelyVgZVRSoD1X0oQWkQnY6gs+DjVWb0XOUw+vkxyqqQUQC0TUTMT6sWRQz31jpeaS AE9Ce4gZGsEk95LRLi0SrARErq36Y0AIBqY7DGdC7V8UEGXSyt9379WaD1ZDHV2fWNXw bSTaWLyiZUngRrAr/D8dlQr/FWM/uaaokhuj4= MIME-Version: 1.0 Received: by 10.223.83.8 with SMTP id d8mr1394198fal.94.1296160633799; Thu, 27 Jan 2011 12:37:13 -0800 (PST) Received: by 10.223.108.71 with HTTP; Thu, 27 Jan 2011 12:37:13 -0800 (PST) In-Reply-To: References: <4D3F233C.7000900@vpnc.org> <82vd1amfjm.fsf@mid.bfk.de> Date: Thu, 27 Jan 2011 16:37:13 -0400 Message-ID: From: Brian Dickson To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:45:30 -0000 On Thu, Jan 27, 2011 at 4:24 PM, Paul Wouters wrote: > On Thu, 27 Jan 2011, Brian Dickson wrote: > >> Open question, to whoever feels like answering it: >> Would the following, as a general mechanism for publishing someone >> else's DNSKEY (securely) work? >> (Here, "foreign" means, we don't hold the private keys) >> >> (1) Using a current, known-good trust anchor, retrieve and validate >> the (foreign) DNSKEY data (possibly plural). >> (2) For every algorithm in the set of foreign DNSKEY data : >> (2a) Generate (one time only!!!) =A0a new public/private key pair for >> our own (local) DNSKEY >> (2b) Combine the local and foreign DNSKEY data into the apex of our >> own zone file, for which we are authoritative. >> (2c) Sign the DNSKEYs with our private keys > > Now you have just moved the problem. I need this DNSKEY as trust anchor. = How > do I know this will not be rolled and how to I get historic data on this > key. Sorry, I thought that was obvious... This DNS zone (or these zones) would need to be maintained, actively, by $vendor. The vendor is then responsible for the key not rolling, and the accuracy of the served trust anchor data (root keys) in the zone, the serving (or outsourcing the serving) of the zone, etc. The only traffic to this zone will be bootstrapping devices, and ideally just once per device. The zones can be fed by a private master, and served literally from anywhere the vendor wants. The liability issues are strictly with the vendor to the itself (and its customers), i.e. negligible. It scales reasonably well, and the overhead, in terms of operational management, while important to get right, is really insignificant. Brian From hallam@gmail.com Thu Jan 27 12:56:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8B33A6A56 for ; Thu, 27 Jan 2011 12:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojmg3X6qKWpe for ; Thu, 27 Jan 2011 12:56:51 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 0B4843A6A51 for ; Thu, 27 Jan 2011 12:56:50 -0800 (PST) Received: by ywk9 with SMTP id 9so883331ywk.31 for ; Thu, 27 Jan 2011 12:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KYEvO+t0HLxd7+VpHmH4MQ+l9yAGFY7b8FamCmq2BOg=; b=xtbgnT3yYf4aL/2/bN/SG4WflSt6edqnpO16la5zkd/LXqZlD9f0YgOD0XgRXEYxkO hSfjwTcvKZpg8jzGAZGTgE7Zo9mUoMQ5rt6zgYzHKGS63F01F2UhPdvvIC1xfzTAkNzu UTuto4VMxqgIzalkMalvnV1Kjo30lR5IJvJ+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kJg9WZPOGZb14dSI7Vp2djYOy7Z7zFp5ibhO11ZhtFNzDbTTBA9cfFPUKIJWMZC5uS yTREM0lc0RClVuoihaqrpvNSdJ0z5F6esPqCZXJZHTuJ8wiJYqvuc0Fi6dmNiRlvMrxD 8ffiDbSna3sBUNtjYeIHxpqWwjG9S7U4epZHE= MIME-Version: 1.0 Received: by 10.100.195.12 with SMTP id s12mr957864anf.18.1296161995025; Thu, 27 Jan 2011 12:59:55 -0800 (PST) Received: by 10.100.109.16 with HTTP; Thu, 27 Jan 2011 12:59:54 -0800 (PST) In-Reply-To: References: <4D3F233C.7000900@vpnc.org> <82vd1amfjm.fsf@mid.bfk.de> Date: Thu, 27 Jan 2011 15:59:54 -0500 Message-ID: From: Phillip Hallam-Baker To: Brian Dickson Content-Type: multipart/alternative; boundary=0016e644c63048ee0f049ada3b6d Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:56:52 -0000 --0016e644c63048ee0f049ada3b6d Content-Type: text/plain; charset=ISO-8859-1 Or alternatively, the vendors get together as a consortium and set up some infrastructure whereby they manage this in a practical manner. This is an important problem that is not limited to DNS trust roots. But the people who would be interested in a solution are going to be the type of people who consider real world business issues of the type that cause many people on this list to stick their fingers in their ears and chant 'la-la-la not listening'. So it is really not a problem that I think is useful to address as part of a DNSSEC infrastructure consideration. On Thu, Jan 27, 2011 at 3:37 PM, Brian Dickson < brian.peter.dickson@gmail.com> wrote: > On Thu, Jan 27, 2011 at 4:24 PM, Paul Wouters wrote: > > On Thu, 27 Jan 2011, Brian Dickson wrote: > > > >> Open question, to whoever feels like answering it: > >> Would the following, as a general mechanism for publishing someone > >> else's DNSKEY (securely) work? > >> (Here, "foreign" means, we don't hold the private keys) > >> > >> (1) Using a current, known-good trust anchor, retrieve and validate > >> the (foreign) DNSKEY data (possibly plural). > >> (2) For every algorithm in the set of foreign DNSKEY data : > >> (2a) Generate (one time only!!!) a new public/private key pair for > >> our own (local) DNSKEY > >> (2b) Combine the local and foreign DNSKEY data into the apex of our > >> own zone file, for which we are authoritative. > >> (2c) Sign the DNSKEYs with our private keys > > > > Now you have just moved the problem. I need this DNSKEY as trust anchor. > How > > do I know this will not be rolled and how to I get historic data on this > > key. > > Sorry, I thought that was obvious... This DNS zone (or these zones) > would need to be maintained, actively, by $vendor. > > The vendor is then responsible for the key not rolling, and the > accuracy of the served trust anchor data (root keys) in the zone, the > serving (or outsourcing the serving) of the zone, etc. > > The only traffic to this zone will be bootstrapping devices, and > ideally just once per device. > > The zones can be fed by a private master, and served literally from > anywhere the vendor wants. > > The liability issues are strictly with the vendor to the itself (and > its customers), i.e. negligible. > > It scales reasonably well, and the overhead, in terms of operational > management, while important to get right, is really insignificant. > > Brian > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --0016e644c63048ee0f049ada3b6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Or alternatively, the vendors get together as a consortium and set up some = infrastructure whereby they manage this in a practical manner.

This is an important problem that is not limited to DNS trust roots.= =A0

But the people who would be interested in a solution ar= e going to be the type of people who consider real world business issues of= the type that cause many people on this list to stick their fingers in the= ir ears and chant 'la-la-la not listening'.=A0

So it is really not a problem that I think is useful to= address as part of a DNSSEC infrastructure consideration.



On Thu, Jan 27, 2011= at 3:37 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:<= br>
On Thu, Jan 27, 2011 at 4= :24 PM, Paul Wouters <paul@xeleran= ce.com> wrote:
> On Thu, 27 Jan 2011, Brian Dickson wrote:
>
>> Open question, to whoever feels like answering it:
>> Would the following, as a general mechanism for publishing someone=
>> else's DNSKEY (securely) work?
>> (Here, "foreign" means, we don't hold the private ke= ys)
>>
>> (1) Using a current, known-good trust anchor, retrieve and validat= e
>> the (foreign) DNSKEY data (possibly plural).
>> (2) For every algorithm in the set of foreign DNSKEY data :
>> (2a) Generate (one time only!!!) =A0a new public/private key pair = for
>> our own (local) DNSKEY
>> (2b) Combine the local and foreign DNSKEY data into the apex of ou= r
>> own zone file, for which we are authoritative.
>> (2c) Sign the DNSKEYs with our private keys
>
> Now you have just moved the problem. I need this DNSKEY as trust ancho= r. How
> do I know this will not be rolled and how to I get historic data on th= is
> key.

Sorry, I thought that was obvious... This DNS zone (or these zones) would need to be maintained, actively, by $vendor.

The vendor is then responsible for the key not rolling, and the
accuracy of the served trust anchor data (root keys) in the zone, the
serving (or outsourcing the serving) of the zone, etc.

The only traffic to this zone will be bootstrapping devices, and
ideally just once per device.

The zones can be fed by a private master, and served literally from
anywhere the vendor wants.

The liability issues are strictly with the vendor to the itself (and
its customers), i.e. negligible.

It scales reasonably well, and the overhead, in terms of operational
management, while important to get right, is really insignificant.

Brian
__________________________________= _____________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext



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

--0016e644c63048ee0f049ada3b6d-- From paul@xelerance.com Thu Jan 27 12:58:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178CC3A6A6A for ; Thu, 27 Jan 2011 12:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSbZD5qJc62k for ; Thu, 27 Jan 2011 12:58:38 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1207A3A6A5E for ; Thu, 27 Jan 2011 12:58:38 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id B30D8C522; Thu, 27 Jan 2011 16:01:41 -0500 (EST) Date: Thu, 27 Jan 2011 16:01:41 -0500 (EST) From: Paul Wouters To: Brian Dickson In-Reply-To: Message-ID: References: <4D3F233C.7000900@vpnc.org> <82vd1amfjm.fsf@mid.bfk.de> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:58:39 -0000 On Thu, 27 Jan 2011, Brian Dickson wrote: >> Now you have just moved the problem. I need this DNSKEY as trust anchor. How >> do I know this will not be rolled and how to I get historic data on this >> key. > > Sorry, I thought that was obvious... This DNS zone (or these zones) > would need to be maintained, actively, by $vendor. The idea (or hope) was that we could do something once, instead of each vendor having to do it for themselves. also if vendors die or merge, these zones could die while the equipment is otherwise still fine to use. If the vendor is active and alive and the product not EOL, then you could just integrate it with a firmware ugprade (though this might be hard in the field) Paul From paul@xelerance.com Thu Jan 27 13:02:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178263A6A75 for ; Thu, 27 Jan 2011 13:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3a3rnZkUj42 for ; Thu, 27 Jan 2011 13:02:51 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 479EE3A6A74 for ; Thu, 27 Jan 2011 13:02:51 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 2C354C522; Thu, 27 Jan 2011 16:05:55 -0500 (EST) Date: Thu, 27 Jan 2011 16:05:54 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4D3F233C.7000900@vpnc.org> <82vd1amfjm.fsf@mid.bfk.de> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 21:02:52 -0000 On Thu, 27 Jan 2011, Phillip Hallam-Baker wrote: > But the people who would be interested in a solution are going to be the type of people who consider real world business issues of the type that cause > many people on this list to stick their fingers in their ears and chant 'la-la-la not listening'.  Just because someone disagrees with you, does not mean they are not listening. One could also argue that it has been stated repeatedly by many here that mixing up DNSSEC and PKIX trustanchors is not desirable - yet you keep proposing it for everything. Paul From jbash@cisco.com Thu Jan 27 12:19:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205933A6A4A for ; Thu, 27 Jan 2011 12:19: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VksL9mYXQlUY for ; Thu, 27 Jan 2011 12:19:02 -0800 (PST) Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id 4E0AB3A6A16 for ; Thu, 27 Jan 2011 12:19:02 -0800 (PST) Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id 893231A52D4 for ; Thu, 27 Jan 2011 15:22:03 -0500 (EST) Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id 675853061; Thu, 27 Jan 2011 15:22:02 -0500 (EST) Message-ID: <4D41D3E2.6060107@cisco.com> Date: Thu, 27 Jan 2011 15:21:54 -0500 From: John Bashinski Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC8C727F6F6685A16808A8232" Subject: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 21:04:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC8C727F6F6685A16808A8232 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, this has generated some interesting messages, and apparently some people think that the "large router vendor" in question should speak for itself. Of course, since this is the IETF, I don't actually represent the "large router vendor". We're all individuals here. I am, however, the person who's writing the internal standards in question for the "large router vendor", and I guess I've just authorized myself to disclose what the "large router vendor" is thinking about doing, so that maybe some of the constraints are a little more clear. Context =3D=3D=3D=3D=3D=3D=3D Presently under discussion (not finalized, with no commitment to do anything at all, subject to change or complete abandonment at any time even if we do adopt the plan, and undoubtedly to suffer exceptions in implementation if we execute on it): 1. Essentially every Cisco product will do DNSSEC validation, with RFC 5011 trust root rollover. I don't mean just routers, and definite= ly not not just professionally administered routers. That $50 Linksys home router/WiFi AP you buy down at Fry's will do DNSSEC when you plug it in. So will that Umi telepresence unit. So will the WebEx client, for that matter. And the network management software, and the management processor in your blade server, and whatever else you can think of. The present direction is to apply thi= s to any and every Cisco product that uses DNS and has access to the necessary computing resources. Implication A: We can't assume very much about what resources a product has. We know it will have DNS and the necessary code and compute powe= r to do DNSSEC validation. Most, but not all, products will have X.509 and TLS code, and the ability to retrieve stuff over HTTP. Beyond that, we don't know. If we force ourselves to put lots of code or hardware in products just for DNSSEC, we will price ourselves out of some markets... or, more realistically, our internal product teams will rightfully rebel and refuse to include validation at all. 2. Validation will be done *locally* in the vast majority of cases. We're not just talking about looking at the AD bit. 3. Validation will be done by default upon installation. If you don't wa= nt it, you'll be able to turn it off, but it's going to happen if you do= n't actively disable it. 4. This would be phased in, with the final phase at somewhere around the beginning of 2013. Realities =3D=3D=3D=3D=3D=3D=3D=3D=3D 5. Some of the people installing these products (frankly including some of the professional network gear) will have no clue what DNSSEC is or what cryptography is. 6. In the case of the consumer gear, the cost to us of helping the custo= mer deal with any DNSSEC failure will be greater than the entire profit we make on the device. 7. Even for professional gear, customers don't want to pay their staff to mess with this, and we don't want to pay our staff to support them. 8. Lots of our products get drop-shipped to people's field offices, get plugged in by a wire-plugger-inner who basically just checks that the lights are on and goes on to the next task, and then have to fend for themselves, at least enough to be able to talk to the NOC and await further instructions. Implication B: As much as it possibly can, anything we do must work without human intervention, and especially without very skilled intervention. We know there will be problems, but we MUST minimize them and minimize the amount of "touch" required to fix them. Implication C: Social engineering is almost always a bigger risk than cryptographic failure, especially at the device end of the communication chain. 9. Devices of all kinds will get their configurations wiped now and then. They will get resold (at which point they SHOULD have their configurations wiped). They will get bought, left on a shelf for 2 or 3 years, and then installed. 10. We can't rely on any customer, let alone consumer products customers, to keep software up to date. I don't happen to like that, but it is a fact. In any case, it may sometimes be a pain to update the software in your device before you have the DNS working. Implication D: Whatever we do must work with a device that has software several years old, and no configuration data newer than the software. Implication E: We *will* be forced to rely on old trust roots, whether they be DNSSEC trust roots, public X.509 trust roots, or trust roots in some system we create for ourselves. Some devices just plain won't have newer information, and just plain won't have admins who can give them newer information, and that puts an absolute lower bound on some cryptoperiod. It's either trust old keys, or have no validation whatsoever. 11. Devices will get installed in corporate and government networks, behind all kinds of unpredictable firewalls administered by people who may not be very happy about opening any holes. Implication F: We have to minimize the number of things we assume to be reachable. Ideally, we'd like to keep it to just the DNS; we're already forced to assume the DNS is available, so that introduces no extra ways to fail. If we have to accept it, a well-known HTTP service or something might be OK, especially if it's something the customer can replicate internally. Weird proprietary protocols are a lot harder to sell to those firewall admins. 12. For most devices, there's a very significant logistical cost to us whenever we change the software... even if the change is just an embedded root key. In the same way, there's a logistical cost (and a new security exposure) if we change the manufacturing process to embed a key separately from the system software. Since our products have diverse manufacturing processes, we bear that cost separately for each product line. Principles =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 13. We prefer to minimize trust in Cisco. Yes, obviously anybody using a Cisco product is trusting Cisco to deliver software that does what it says it does, and that's an enormous amount of trust. Nonetheless, we try to keep further trust to a minimum. If nothing else, that makes it easier for us to manage things internally, and to contain the effects of any internal failures. 14. We also try to reduce the temporal extent of trust; when possible, we avoid assuming that your trusting us when you install a box at time T implies you should have to trust us at every moment in time after T. For example, we usually require user approval for software updates. 15. We prefer to minimize the spread of trust to different entities. We're already trusting the process that maintains the DNS root, and we're already extending that trust over a long time without any real way to respond if it turns out to be unjustified. That is an unavoidable risk. We would prefer not to take on any avoidable risk. Implication G: We would like to avoid cryptographic trust in anything but DNSSEC root keys. Yes, we could use our PKI for this, but we'd prefer not to if we can easily avoid it. Further realities =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 16. The public X.509 PKI (actually a loose confederation of rival PKIs, each of which everything is expected to trust) is completely broken. There's no sign that it will ever be fixed, we definitely can't wait around for it to get fixed, and making our DNSSEC dependent on it would greatly compromise the solution security, complicate the implementation, enlarge the attack surface beyond all sanity, *and* make the whole trust root maintenance problem worse (because we'd now have to maintain many, many roots). Implication H: "Fetch the key from IANA over HTTPS" won't do it. 17. As far as I can see, any other vendor who tried to do this would run into exactly the same problems. Implication I: It seems as though it makes sense to have a shared solutio= n. Approaches =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D At the moment, the following are under consideration: I. Get IANA and the root zone to provide some kind of service for getting up to date starting from old trust roots. This is our preferred answer, because-- a. Every vendor could use it.. b. Every professional network admin would eventually be familiar wit= h it c. Every firewall would probably eventually let it through. d. It would get a lot of scrutiny, and that would make it more trustworthy. e. We wouldn't have to commit to running a well-known service for ages and ages. To be honest, it's not that easy to get a big corporation to buy into something like that in a way that makes you feel as confident as I'd like to be in this. f. It could outlast any vendor. I do not have the authority to even *suggest* committing any Cisco funds to supporting this, but I could ask. Perhaps others on this list could think about asking their employers as well. It's always easier to get money if the boss feels the need to keep up with the Joneses... II. Provide our own key update service. This might be DNS-based or HTTP-based. It would provide either: a. The entire historical chain of DNS root KSKs, with older keys signing newer ones, so that the device could pick up from whatever key it had, OR b. Just the current root key, signed with a key validated by Cisco's private X.509 PKI (the same PKI we use to sign software), OR c. The chain of (a) further signed with a key from (b). We are obviously capable of this. We also obviously think it's inferior to (I). III. Try to ship devices with up-to-date keys, and rely on admins to update them when that fails. I think this would blow up on us, and I got some indignant pushback for even suggesting it. IV. Weaken the scheme in one of the following ways: a. Just query for the key record for the root zone at installation time, and believe whatever comes back. At least you're only exposed at one time instead of forever afterwards. b. Try a wired-in key, then fall back to (a) if it doesn't work. Which isn't every different from (a). Using the current public X.509 PKI is NOT under consideration. -- jbash --------------enigC8C727F6F6685A16808A8232 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1B0+oACgkQQXYiJfd/Jba9BQCeNkP9Z9WaClLExotaKlTQ/cgN oScAn1VS2WeGVIERpYwRf3cIDOLxRpc6 =3kqN -----END PGP SIGNATURE----- --------------enigC8C727F6F6685A16808A8232-- From ajs@shinkuro.com Thu Jan 27 13:19:35 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5DB928C170 for ; Thu, 27 Jan 2011 13:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQqQcxH5qRlX for ; Thu, 27 Jan 2011 13:19:35 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 04A253A6A74 for ; Thu, 27 Jan 2011 13:19:33 -0800 (PST) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id DA7861ECB426 for ; Thu, 27 Jan 2011 21:22:36 +0000 (UTC) Date: Thu, 27 Jan 2011 16:22:35 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110127212235.GM21088@shinkuro.com> References: <82vd1amfjm.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 21:19:35 -0000 [moderation note] Colleagues, Not to pick on Paul and Phillip, but I note that some of the discussion around this issue is a little heated sometimes. It's an important issue, I think we can agree, and therefore it is important we find workable solutions (either in-protocol or out). So let's keep the discourse super-civilized, please. Thanks! A On Thu, Jan 27, 2011 at 04:05:54PM -0500, Paul Wouters wrote: > On Thu, 27 Jan 2011, Phillip Hallam-Baker wrote: > >> But the people who would be interested in a solution are going to be the type of people who consider real world business issues of the type that cause >> many people on this list to stick their fingers in their ears and chant 'la-la-la not listening'.  > > Just because someone disagrees with you, does not mean they are not listening. -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From jabley@hopcount.ca Thu Jan 27 13:35:17 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC883A69D4 for ; Thu, 27 Jan 2011 13:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMaZJb1IJ7Ct for ; Thu, 27 Jan 2011 13:35:15 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 5698C3A6A75 for ; Thu, 27 Jan 2011 13:35:15 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PiZbq-0008Wr-D4; Thu, 27 Jan 2011 21:42:37 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <50123.1296155020@nsa.vix.com> Date: Thu, 27 Jan 2011 16:38:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D3F233C.7000900@vpnc.org> <10A3D861-EC02-49FF-BBD1-44843378C9CB@icsi.berkeley.edu> <2BC28AF0-9132-4FFD-9FA6-FCEC29A1D471@hopcount.ca> <50123.1296155020@nsa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 21:35:17 -0000 On 2011-01-27, at 14:03, Paul Vixie wrote: >> From: Joe Abley >> Date: Thu, 27 Jan 2011 13:28:26 -0500 >>=20 >> There is no established schedule for rolling the root zone's KSK. All >> we have said to date is that we don't expect to do it any time soon, >> because it's not clear that support for automated handling of such an >> event is well-deployed in clients. >=20 > under what conditions can you imagine that changing? If the groundwork was done and it looked like the client population was = likely to be substantially KSK-roll-tolerant (by which I intend to imply = experimentation, real-world surveys and testing, conversations with = relevant vendors, a much clearer specification for desired client = behaviour, etc) I would advocate scheduled KSK rolls for the root. The benefits of all that work would be operational rather than = cryptographic (at least, I have been told that there is little = cryptographic in rolling an uncompromised 2048 bit root zone KSK). For = example, clients are far more likely to be able to survive an emergency = key roll if we know that all the code points associated with a scheduled = key roll are well-understood and exercised; those from IANA and the = community who are involved in managing the KSK have a better shot of = getting it right if the processes involved are regularly used (even if = they're not used very often). Without a much better understanding of the likely impact on clients, = however, and without any confidence that clients will handle the event = without helpdesk intervention, the costs of a KSK roll appear to = outweigh the benefits, even with the relatively small validating base we = might imagine exists today. Joe From jabley@hopcount.ca Thu Jan 27 13:52:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4693A28C177 for ; Thu, 27 Jan 2011 13:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFK8xLnIiJ9Y for ; Thu, 27 Jan 2011 13:52:31 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 0F3A33A69DE for ; Thu, 27 Jan 2011 13:52:31 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PiZsX-00092y-Cv; Thu, 27 Jan 2011 21:59:47 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <4D41D3E2.6060107@cisco.com> Date: Thu, 27 Jan 2011 16:55:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> References: <4D41D3E2.6060107@cisco.com> To: John Bashinski X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext List Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 21:52:32 -0000 Hi John, On 2011-01-27, at 15:21, John Bashinski wrote: > At the moment, the following are under consideration: >=20 > I. Get IANA and the root zone to provide some kind of service for > getting up to date starting from old trust roots. This is our > preferred answer, because-- >=20 > a. Every vendor could use it.. >=20 > b. Every professional network admin would eventually be familiar = with it >=20 > c. Every firewall would probably eventually let it through. >=20 > d. It would get a lot of scrutiny, and that would make it more > trustworthy. >=20 > e. We wouldn't have to commit to running a well-known service > for ages and ages. To be honest, it's not that easy to get > a big corporation to buy into something like that in a way > that makes you feel as confident as I'd like to be in this. >=20 > f. It could outlast any vendor. >=20 > I do not have the authority to even *suggest* committing any > Cisco funds to supporting this, but I could ask. Perhaps others > on this list could think about asking their employers as well. > It's always easier to get money if the boss feels the need to > keep up with the Joneses... Right now we publish trust anchors for the root zone as: 1. an XML file, which is signed separately using S/MIME and PGP. This = file contains the current public key and also includes details of all = previous public keys, annotated XMLishly to indicate over what periods = of time they were intended to be used. 2. an X.509 certificate. One of the products of a key ceremony is an = X.509 CSR, which we sign using an ICANN-maanged CA to produce the = certificate. It was our ambition with (2) to publish multiple certificates for each = anchor, each one representing the same CSR signed by a different = certificate authority. This would allow a software vendor who already = runs a CA (e.g. for the purpose of signing software updates) to = bootstrap trust in a published KSK public key using their own key, but = it might also be useful with well-known and -used commercial CAs, too. A client might then have a bootstrapping mechanism of - retrieve ; - retrieve the set of CRTs associated with the current KSK (as = identified in the XML file, currently just = , but potentially = ); (both the above accomplished without using DNSSEC validation, or SSL, = although those URLs are provided with HTTPS too) - use a local X.509 trust anchor (e.g. for a vendor CA, or the regular = browser list of SysTrust-accredited commercial CAs, or something else) = to verify that the trust anchor retrieved is correct and proper. Don't interpret any of that as reluctance to discuss doing anything new = at IANA to make this easier; I just want to make sure the existing = mechanisms can't be made to work in a sensible way first. Joe= From hallam@gmail.com Thu Jan 27 15:20:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769C63A69D6 for ; Thu, 27 Jan 2011 15:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKPJ2tK1xCWr for ; Thu, 27 Jan 2011 15:20:00 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 5A04D3A68AA for ; Thu, 27 Jan 2011 15:19:57 -0800 (PST) Received: by yxt33 with SMTP id 33so943938yxt.31 for ; Thu, 27 Jan 2011 15:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eHKgrJt0qVWD4+RrjPwm2AMCSI9blKtnaaVlhGSAbto=; b=bVQMWQG4rbADBmI/Ky8lVFVdhsGK6LOcopWkMK1aSiYUtd3MCWmJKTKx5xyq/UMYNB jKA35/udr38Deo4HDVxbEvlD7Phbk8LepR3J5lUU3tHQaElEsOph/BwmLST5EkS49mGB CQaT238cTTVX9l4JYu5sxsDTCtwPDjB6T9IQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RqBlWvYgBQG44NFHNvrayHukbouyaUKOufimb8I4hKaEmyJPt/98pKiN8lLVZ/o4Yq oVvOK64+w0XdEYDk5mLFPXT3DamBSK25CvXaV+Rpo8rDHH0KnSZk8PSYDMSsMokrPy1Z oEhzNt75fk5Rjt9Kic7uABSevKThWAG0nxLMw= MIME-Version: 1.0 Received: by 10.100.48.3 with SMTP id v3mr1046166anv.154.1296170581459; Thu, 27 Jan 2011 15:23:01 -0800 (PST) Received: by 10.100.109.16 with HTTP; Thu, 27 Jan 2011 15:23:01 -0800 (PST) In-Reply-To: References: <4D3F233C.7000900@vpnc.org> <10A3D861-EC02-49FF-BBD1-44843378C9CB@icsi.berkeley.edu> <2BC28AF0-9132-4FFD-9FA6-FCEC29A1D471@hopcount.ca> <50123.1296155020@nsa.vix.com> Date: Thu, 27 Jan 2011 18:23:01 -0500 Message-ID: From: Phillip Hallam-Baker To: Joe Abley Content-Type: multipart/alternative; boundary=0016e645b8c4138405049adc3b28 Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 23:20:11 -0000 --0016e645b8c4138405049adc3b28 Content-Type: text/plain; charset=ISO-8859-1 The risk of doing such a roll would be that the ensuing chaos is then used as proof that DNSSEC is not ready for prime-time. I do think that it is worth people like myself who have been considering cyber-conflict issues for some time war-gaming an emergency roll. But we are talking about possibilities that are really very unlikely indeed and we are probably talking about scenarios that involve 'kinetic' attacks in addition to purely cyber. If you want to engage in that type of exercise you need to posit a plausible scenario that would cause the emergency roll to be required. And once you start considering those type of scenarios we are talking about catastrophic failures that are going to completely invalidate any experience from the proposed fire-drill. Airlines do train for evacuation of passengers from aircraft, but they do not perform such drills on a regular basis with paying passengers (liners on the other hand do). So the downside risk is large, if you try that test it is likely to damage prospects for DNSSEC deployment. The benefit is negligible. On Thu, Jan 27, 2011 at 4:38 PM, Joe Abley wrote: > > On 2011-01-27, at 14:03, Paul Vixie wrote: > > >> From: Joe Abley > >> Date: Thu, 27 Jan 2011 13:28:26 -0500 > >> > >> There is no established schedule for rolling the root zone's KSK. All > >> we have said to date is that we don't expect to do it any time soon, > >> because it's not clear that support for automated handling of such an > >> event is well-deployed in clients. > > > > under what conditions can you imagine that changing? > > If the groundwork was done and it looked like the client population was > likely to be substantially KSK-roll-tolerant (by which I intend to imply > experimentation, real-world surveys and testing, conversations with relevant > vendors, a much clearer specification for desired client behaviour, etc) I > would advocate scheduled KSK rolls for the root. > > The benefits of all that work would be operational rather than > cryptographic (at least, I have been told that there is little cryptographic > in rolling an uncompromised 2048 bit root zone KSK). For example, clients > are far more likely to be able to survive an emergency key roll if we know > that all the code points associated with a scheduled key roll are > well-understood and exercised; those from IANA and the community who are > involved in managing the KSK have a better shot of getting it right if the > processes involved are regularly used (even if they're not used very often). > > Without a much better understanding of the likely impact on clients, > however, and without any confidence that clients will handle the event > without helpdesk intervention, the costs of a KSK roll appear to outweigh > the benefits, even with the relatively small validating base we might > imagine exists today. > > > Joe > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --0016e645b8c4138405049adc3b28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The risk of doing such a roll would be that the ensuing chaos is then used = as proof that DNSSEC is not ready for prime-time.


I do think that it is worth people like myself who have been consi= dering cyber-conflict issues for some time war-gaming an emergency roll. Bu= t we are talking about possibilities that are really very unlikely indeed a= nd we are probably talking about scenarios that involve 'kinetic' a= ttacks in addition to purely cyber.

If you want to engage in that type of exercise you need= to posit a plausible scenario that would cause the emergency roll to be re= quired.

And once you start considering those type = of scenarios we are talking about catastrophic failures that are going to c= ompletely invalidate any experience from the proposed fire-drill.=A0


Airlines do train for evacuation of passengers from= aircraft, but they do not perform such drills on a regular basis with payi= ng passengers (liners on the other hand do).


So the downside risk is large, if you try that test it is likely= to damage prospects for DNSSEC deployment. The benefit is negligible.


On Thu, Jan = 27, 2011 at 4:38 PM, Joe Abley <jabley@hopcount.ca> wrote:

On 2011-01-27, at 14:03, Paul Vixie wrote:

>> From: Joe Abley <jabley@h= opcount.ca>
>> Date: Thu, 27 Jan 2011 13:28:26 -0500
>>
>> There is no established schedule for rolling the root zone's K= SK. All
>> we have said to date is that we don't expect to do it any time= soon,
>> because it's not clear that support for automated handling of = such an
>> event is well-deployed in clients.
>
> under what conditions can you imagine that changing?

If the groundwork was done and it looked like the client population w= as likely to be substantially KSK-roll-tolerant (by which I intend to imply= experimentation, real-world surveys and testing, conversations with releva= nt vendors, a much clearer specification for desired client behaviour, etc)= I would advocate scheduled KSK rolls for the root.

The benefits of all that work would be operational rather than cryptographi= c (at least, I have been told that there is little cryptographic in rolling= an uncompromised 2048 bit root zone KSK). For example, clients are far mor= e likely to be able to survive an emergency key roll if we know that all th= e code points associated with a scheduled key roll are well-understood and = exercised; those from IANA and the community who are involved in managing t= he KSK have a better shot of getting it right if the processes involved are= regularly used (even if they're not used very often).

Without a much better understanding of the likely impact on clients, howeve= r, and without any confidence that clients will handle the event without he= lpdesk intervention, the costs of a KSK roll appear to outweigh the benefit= s, even with the relatively small validating base we might imagine exists t= oday.


Joe

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



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

--0016e645b8c4138405049adc3b28-- From hallam@gmail.com Thu Jan 27 21:31:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67783A6BA2 for ; Thu, 27 Jan 2011 21:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DIdnsFEbgIx for ; Thu, 27 Jan 2011 21:31:17 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 5CAF23A6B9C for ; Thu, 27 Jan 2011 21:31:17 -0800 (PST) Received: by ywk9 with SMTP id 9so1051706ywk.31 for ; Thu, 27 Jan 2011 21:34:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+UaZhYRXT9/EJocA9AGoewB66ne/mQdkfN+YN+DgNew=; b=xMLI1BguNf9Bc59tYmwS4csn3ikDQu0HDKRhR4OJUVsYsNu/pMHcHOEqTKjaFmgMiJ 1xoxzpP9g2xK8O/76MO97uhiwJKvqjhrXmEwlj4NktylPLHoxb/aBpETgUTztgtc7JCP /BLMPdI6LTsUZx/zA7kP79clfkCJOA8Luh9HE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mgzsFUM/a8Ton7T6HyWLADiOm5YisHBFkXpAfmEblDcnojZ/uWvL7pLChrSIH0Ko4s vUvQA8ALnJnbr2sMUTbqRFCOesQbcJK39JEXtAkJ78VuG/4OO2jzYl3tZ7FGBdx8KocD K7k6Z4yEF47EtWUK8NAfQoE5688sOe+iyuqEg= MIME-Version: 1.0 Received: by 10.100.195.12 with SMTP id s12mr1283256anf.18.1296192860846; Thu, 27 Jan 2011 21:34:20 -0800 (PST) Received: by 10.100.109.16 with HTTP; Thu, 27 Jan 2011 21:34:20 -0800 (PST) In-Reply-To: <4D41D3E2.6060107@cisco.com> References: <4D41D3E2.6060107@cisco.com> Date: Fri, 28 Jan 2011 00:34:20 -0500 Message-ID: From: Phillip Hallam-Baker To: John Bashinski Content-Type: multipart/alternative; boundary=0016e644c63007fb9f049ae16ba5 Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 05:31:18 -0000 --0016e644c63007fb9f049ae16ba5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 27, 2011 at 3:21 PM, John Bashinski wrote: > > Using the current public X.509 PKI is NOT under consideration. > > Just to be clear, it was never proposed, except as a straw man by Paul Wouters. What I suggested was that we look at the possibilities of using X.509 standards and infrastructure that has been developed to meet similar considerations in that space. I think it is abundantly clear that we do not want the criteria for signing the root KSK to be inclusion in some browser root anchor list. X.509 is designed to deal with persistent keys, DNS is not designed to persist data. I think that we should detach this problem from DNSSEC because we are going to face the same problem for device keys. We have over the years created quite a few consortiums that sign various CA certs for device keys and we are in the process of creating more. Ultimately these devices are going to have to tie into enterprise networks and recognize the root of trust for the enterprise regardless of whether their function requires them to also process DNSSEC or not. So I would look to develop a scheme that addresses the problem of managing the enterprise trust root first and then consider the IANA root key as being a special case that would reuse the same code and management principles. -- Website: http://hallambaker.com/ --0016e644c63007fb9f049ae16ba5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 27, 2011 at 3:21 PM, John Ba= shinski <jbash@cisc= o.com> wrote:

Using the current public X.509 PKI is NOT under consideration.

Just to be clear, it was never proposed, except as a = straw man by Paul Wouters.

What I suggested was th= at we look at the possibilities of using X.509 standards and infrastructure= that has been developed to meet similar considerations in that space. I th= ink it is abundantly clear that we do not want the criteria for signing the= root KSK to be =A0inclusion in some browser root anchor list.=A0

X.509 is designed to deal with persistent keys, DNS is = not designed to persist data.


I thi= nk that we should detach this problem from DNSSEC because we are going to f= ace the same problem for device keys. We have over the years created quite = a few consortiums that sign various CA certs for device keys and we are in = the process of creating more.

Ultimately these devices are going to have to tie into = enterprise networks and recognize the root of trust for the enterprise rega= rdless of whether their function requires them to also process DNSSEC or no= t.=A0

So I would look to develop a scheme that addresses the = problem of managing the enterprise trust root first and then consider the I= ANA root key as being a special case that would reuse the same code and man= agement principles.
=A0

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

--0016e644c63007fb9f049ae16ba5-- From drc@virtualized.org Thu Jan 27 22:03:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36F953A6BC4 for ; Thu, 27 Jan 2011 22:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl0VVki+c-xi for ; Thu, 27 Jan 2011 22:03:05 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 39E583A6BC0 for ; Thu, 27 Jan 2011 22:03:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id C31651062598; Thu, 27 Jan 2011 22:06:10 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql09huWCr+6B; Thu, 27 Jan 2011 22:06:08 -0800 (PST) Received: from 205.122.224.10.in-addr.arpa (m170436d0.tmodns.net [208.54.4.23]) by virtualized.org (Postfix) with ESMTP id 11A591062590; Thu, 27 Jan 2011 22:06:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> Date: Thu, 27 Jan 2011 22:06:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.1082) Cc: dnsext List Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 06:03:07 -0000 On Jan 26, 2011, at 1:26 PM, Joe Abley wrote: > Wouter's earlier proposal which is mentioned elsewhere in this thread = had the principle defect that its use relied upon trusting signatures = made by old keys, which in general some of us thought was a poor idea = (e.g. in the event that a key was rolled because it was compromised). I don't think that's a risk. If a key is rolled because of a known = compromise, it simply means you can't safely chain from the = old-but-installed-key to the current-but-not-yet-installed key. = Presumably, when a key is known to be compromised, the chain from old to = current keys would be broken such that automated systems would require = human intervention. As far as I can tell the real risk is that an attacker has an increased = amount of time to secretly compromise any key in the old to current = chain, thereby enabling a MITM attack to insert a branch to a new chain = that will end in a malicious key. The continued use of the old keys for = something valuable means the keys have to be much stronger and it sort = of defeats the purpose of scheduled rolling of keys. Regards, -drc From drc@virtualized.org Thu Jan 27 22:03:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5683A6BCC for ; Thu, 27 Jan 2011 22:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxjFD49k1tS8 for ; Thu, 27 Jan 2011 22:03:10 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id B85023A6BC0 for ; Thu, 27 Jan 2011 22:03:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 7550210625A1; Thu, 27 Jan 2011 22:06:14 -0800 (PST) X-Quarantine-ID: <1eauwqF7LzTc> X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eauwqF7LzTc; Thu, 27 Jan 2011 22:06:12 -0800 (PST) Received: from 205.122.224.10.in-addr.arpa (m170436d0.tmodns.net [208.54.4.23]) by virtualized.org (Postfix) with ESMTP id 733EA1062599; Thu, 27 Jan 2011 22:06:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <4D41D3E2.6060107@cisco.com> Date: Thu, 27 Jan 2011 22:06:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3976B502-F2D5-4C70-8354-B46A9185E9CF@virtualized.org> References: <4D41D3E2.6060107@cisco.com> To: John Bashinski X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 06:03:12 -0000 John, Very useful note, thanks! On Jan 27, 2011, at 12:21 PM, John Bashinski wrote: > At the moment, the following are under consideration: >=20 > I. Get IANA and the root zone to provide some kind of service for > getting up to date starting from old trust roots. If you only want to use DNS/DNSSEC, the implication of this is that the = old trust roots would need to be forever (or at least the longest = lifetime of all products) secure. This would also sort of defeat the = purpose of scheduled key rolls and would fail in the face of a key roll = caused by known or suspected key compromise (you won't want to chain up = through a known-compromised key). > II. Provide our own key update service. How would this be (conceptually) different than providing a (secure) = software update service? (Somewhat as an aside, in a world in which you can't trust admins, I'd = argue that (by default) requiring user approval to install updates is = demonstrably more risky to the Internet at large than otherwise.) > III. Try to ship devices with up-to-date keys, and rely on admins to > update them when that fails. I think this would blow up on us, and > I got some indignant pushback for even suggesting it. I'd agree relying on admins is unlikely to work. > IV. Weaken the scheme in one of the following ways: >=20 > a. Just query for the key record for the root zone at installation > time, and believe whatever comes back. At least you're only = exposed > at one time instead of forever afterwards. >=20 > b. Try a wired-in key, then fall back to (a) if it doesn't > work. Which isn't every different from (a). This doesn't seem that much different from III. You'd have to rely on = the admin to do something (in this case, ensure the initial connection = used to fetch the root key is safe). > Using the current public X.509 PKI is NOT under consideration. Understandable. However, this doesn't necessarily preclude the use of a = private (not necessarily X.509, e.g., PGP/GPG) PKI. Fundamentally, I don't see how this can be solved securely via = DNS/DNSSEC.=20 Regards, -drc From brian.peter.dickson@gmail.com Thu Jan 27 22:34:29 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EBC13A6BBD for ; Thu, 27 Jan 2011 22:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.191 X-Spam-Level: X-Spam-Status: No, score=-3.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNOBUUd8YiWV for ; Thu, 27 Jan 2011 22:34:28 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C1B1A3A6BB8 for ; Thu, 27 Jan 2011 22:34:27 -0800 (PST) Received: by fxm9 with SMTP id 9so3278423fxm.31 for ; Thu, 27 Jan 2011 22:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MDW8DR0ARjCK6pfDh7GXPppS7vR+K0BtWL/ph9lkfVs=; b=mqSOvoSkXlDQ+hwsQJWngvhmIR7YbXTU1pMBH28WNrwpEcqvM44+ao9EpwYusXHbV8 njchB9lIx7SjXzRmQMLRn2hMEWCElFL5fUZL7StCkTknpd6XFb3yhdHzu74SRnDNoWOI x/a5SnFd22zxo1k42RRYOrdpN0x3OLmZbHC+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BJ1RfAd8WmNnA3ZjEX0rzMWI+1lJhnsEfdFSeoc9Wa8qgTDdzv8HYyl+Vg9zKAOx9C tNFh/yHCjs0blzVdkLYz/uPD1ffL6sphFUg8wcNbpnBYLVfgnYxPya1CdXf3qj1JtJwn RhJbaF3T50T6w8tnZZPPwQMVbXbn8aozCY5iQ= MIME-Version: 1.0 Received: by 10.223.102.77 with SMTP id f13mr1916707fao.113.1296196652537; Thu, 27 Jan 2011 22:37:32 -0800 (PST) Received: by 10.223.108.71 with HTTP; Thu, 27 Jan 2011 22:37:32 -0800 (PST) In-Reply-To: <4D41D3E2.6060107@cisco.com> References: <4D41D3E2.6060107@cisco.com> Date: Fri, 28 Jan 2011 02:37:32 -0400 Message-ID: From: Brian Dickson To: John Bashinski Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 06:34:29 -0000 Thanks for the update, John. Clarification and open question follows: On Thu, Jan 27, 2011 at 4:21 PM, John Bashinski wrote: > > Approaches > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > At the moment, the following are under consideration: > > =A0I. Get IANA and the root zone to provide some kind of service for > =A0 =A0 getting up to date starting from old trust roots. What if, rather than starting from "old trust roots", it was starting from "privately-signed trust anchors"? I.e. have IANA have private keys which are used ONLY for this service. The vendors would include the public keys as trust anchors for boot-strapping purposes. The key transfer might happen offline, or at least out-of-band. The same data could be signed with multiple such unpublished keys, as needed (e.g. one per vendor, per year, use a new key every year, but keep signing with all keys) and/or funded. Vendors might agree to pool resources/keys, or not. In the event of a key compromise of one of these keys, the presumed impact would be finite, small, localized (to a vendor-pool + year tuple), and decreasing over time (if a given public key is used only for one-time bootstrap purposes). And, most importantly, it would be off-axis from the root-key chaining. The rolling of root keys (for whatever reason, especially for compromise) would be orthogonal to this mechanism. And now, consider the possibility when the public keys are never actually published in this or any other zone.... The "public key" would be the trust anchor, used to validate the RRSIG dire= ctly. Open question: Does not publishing the key make it harder to compromise the key? (Of course, the key needs to be distributed in the software and/or configuration files, so it's just "less well known", I suppose...) Brian From jakob@kirei.se Thu Jan 27 23:52:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54E528C0DE for ; Thu, 27 Jan 2011 23:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmgCMpOVGwCr for ; Thu, 27 Jan 2011 23:52:51 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id E295628C0CE for ; Thu, 27 Jan 2011 23:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=1EnZpQtJ7Dw0WpaaYx4TLKb5nN8RNFp0J7l0ebWAQ88=; b=VorOMWdpelUXl0Lhg9DwTkp4IlY07Myt+I4U7mjJVoGqv/+kA3xwysyP2CmEgsHDDlhW4LUzEEFR4 xVZnrX9nxh74Sm/r8tlf+EXk2/nWgAfSgASdJR3P35CY3jzcZ6QaxtnsbuYUw/fzu/v3Le8O4dUXKL SjcqgcRz+BsoUiJw= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 28 Jan 2011 08:55:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Fri, 28 Jan 2011 08:55:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F7680DF-C167-4600-A7F2-0CB76D6550AA@kirei.se> References: <4D41D3E2.6060107@cisco.com> To: Brian Dickson X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 07:52:53 -0000 On 28 jan 2011, at 07.37, Brian Dickson wrote: > What if, rather than starting from "old trust roots", it was starting > from "privately-signed trust anchors"? >=20 > I.e. have IANA have private keys which are used ONLY for this service. > The vendors would include the public keys as trust anchors for > boot-strapping purposes. The key transfer might happen offline, or at > least out-of-band. We designed the detached signature [1] over the XML file [2] to work = almost like that, although the ICANN Root CA is used for other things as = well. > The same data could be signed with multiple such unpublished keys, as > needed (e.g. one per vendor, per year, use a new key every year, but > keep signing with all keys) and/or funded. Vendors might agree to pool > resources/keys, or not. Anyone can grab the latest root key CSR [3], sign it and produce a their = "own" DNSSEC root key certificate and distribute with their software. > And, most importantly, it would be off-axis from the root-key > chaining. The rolling of root keys (for whatever reason, especially > for compromise) would be orthogonal to this mechanism. IMHO, any key signing the root key should protected with the same = controls as the root key itself. Given how the root key itself is = protected, I doubt that very few organizations can match that level of = protection (although I know I'm biased when it comes to root key = protection). > Open question: > Does not publishing the key make it harder to compromise the key? No. jakob [1] http://data.iana.org/root-anchors/root-anchors.p7s [2] http://data.iana.org/root-anchors/root-anchors.xml [3] http://data.iana.org/root-anchors/Kjqmt7v.csr --=20 Jakob Schlyter Kirei AB - www.kirei.se From fweimer@bfk.de Fri Jan 28 00:18:23 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8E828C0ED for ; Fri, 28 Jan 2011 00:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aW8cY6LyEatt for ; Fri, 28 Jan 2011 00:18:22 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 6FB563A6BF6 for ; Fri, 28 Jan 2011 00:18:22 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Pija8-0006Bv-Kn; Fri, 28 Jan 2011 08:21:24 +0000 Received: by bfk.de with local id 1Pija8-0003rQ-Hl; Fri, 28 Jan 2011 08:21:24 +0000 To: Joe Abley References: <4D3F233C.7000900@vpnc.org> <10A3D861-EC02-49FF-BBD1-44843378C9CB@icsi.berkeley.edu> <2BC28AF0-9132-4FFD-9FA6-FCEC29A1D471@hopcount.ca> From: Florian Weimer Date: Fri, 28 Jan 2011 08:21:24 +0000 In-Reply-To: <2BC28AF0-9132-4FFD-9FA6-FCEC29A1D471@hopcount.ca> (Joe Abley's message of "Thu\, 27 Jan 2011 13\:28\:26 -0500") Message-ID: <82aailmoaj.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 08:18:23 -0000 * Joe Abley: > On 2011-01-27, at 11:07, Nicholas Weaver wrote: > >> Lets face it, 98% of the root key rollovers are going to be benign, on t= hat once-a-year schedule. > > There is no established schedule for rolling the root zone's > KSK. All we have said to date is that we don't expect to do it any > time soon, because it's not clear that support for automated > handling of such an event is well-deployed in clients. This was exactly my impression, too. But when Nicholas brought up the once-a-year schedule, I started looking for policy statements because a yearly key rollover is rather scary. The closest I could come up with is this statement: | 6.5. Key signing key roll-over |=20 | Each RZ KSK will be scheduled to be rolled over through a key | ceremony as required, or after 5 years of operation. This is how I came up with the year 2014 so I didn't pull it out of the air completely. Of course, I welcome if you want to make it 2011 instead of 2014. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer@bfk.de Fri Jan 28 00:34:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3B23A6950 for ; Fri, 28 Jan 2011 00:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JBalTrGvYJw for ; Fri, 28 Jan 2011 00:34:51 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 0B1E93A6933 for ; Fri, 28 Jan 2011 00:34:49 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Pijq3-0007sa-Sh; Fri, 28 Jan 2011 08:37:51 +0000 Received: by bfk.de with local id 1Pijq3-0001m3-Oe; Fri, 28 Jan 2011 08:37:51 +0000 To: John Bashinski References: <4D41D3E2.6060107@cisco.com> From: Florian Weimer Date: Fri, 28 Jan 2011 08:37:51 +0000 In-Reply-To: <4D41D3E2.6060107@cisco.com> (John Bashinski's message of "Thu\, 27 Jan 2011 15\:21\:54 -0500") Message-ID: <82r5bxl8yo.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 08:34:52 -0000 * John Bashinski: > I am, however, the person who's writing the internal standards in > question for the "large router vendor", and I guess I've just authorized > myself to disclose what the "large router vendor" is thinking about > doing, so that maybe some of the constraints are a little more clear. Would it help you if there weren't any vanity key rollovers at all? Then the remaining cases are, as far as I can see: (i) key is lost (ii) key is compromised (iii) cryptographic algorithms are compromised (iv) control of the root zone changes In cases (i), (iv), you cannot expect that the new key material will be signed by the old. In case (ii), you cannot rely on the signature from the old key material. In case (iii), you'll likely need a firmware update to implement new algorithms, and you can ship new key material with that. What am I missing? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From george.barwood@blueyonder.co.uk Fri Jan 28 01:46:52 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE7F3A6C08 for ; Fri, 28 Jan 2011 01:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.696 X-Spam-Level: X-Spam-Status: No, score=0.696 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm0fOYqJTtob for ; Fri, 28 Jan 2011 01:46:52 -0800 (PST) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id CC3D93A6965 for ; Fri, 28 Jan 2011 01:46:51 -0800 (PST) Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1Pikxn-0001Nj-Of; Fri, 28 Jan 2011 09:49:55 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PikxQ-0007Z3-RH; Fri, 28 Jan 2011 09:49:32 +0000 Message-ID: <1964C69C6E2043BAA45387ED557C72E2@local> From: "George Barwood" To: "John Bashinski" , "Florian Weimer" References: <4D41D3E2.6060107@cisco.com> <82r5bxl8yo.fsf@mid.bfk.de> Date: Fri, 28 Jan 2011 09:49:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 09:46:52 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJGbG9yaWFuIFdlaW1lciIgPGZ3 ZWltZXJAYmZrLmRlPg0KDQo+IFdvdWxkIGl0IGhlbHAgeW91IGlmIHRoZXJlIHdlcmVuJ3QgYW55 IHZhbml0eSBrZXkgcm9sbG92ZXJzIGF0IGFsbD8NCg0KSSB0aGluayBpdCdzIG5lY2Vzc2FyeSB0 byByb2xsIHRoZSBrZXkgZXZlbnR1YWxseSBiZWNhdXNlIEROU1NFQyBzaWduYXR1cmUgZGF0ZXMg d3JhcCwNCihhbmQgc2lnbmF0dXJlcyBjYW4gdGhlcmVmb3JlIGJlIHJlcGxheWVkKSBidXQgb25s eSBhZnRlciAxMzYgeWVhcnMuDQoNCk15IGZlZWxpbmcgaXMgdGhhdCB0aGUgcm9sbCBwcm9jZXNz IHNob3VsZCBiZSB2ZXJ5IHNsb3cuDQoNCmUuZy4gdGhlIERTIHJlY29yZCBmb3IgYSBuZXcga2V5 IGlzIHB1Ymxpc2hlZCBzYXkgNjAgeWVhcnMgaW4gYWR2YW5jZSwNCndpdGggYSBuZXcga2V5IGJl aW5nIGdlbmVyYXRlZCBzYXkgZXZlcnkgMjAgeWVhcnMuDQoNClRoYXQgYWxsb3dzIGEgbG9uZyAo NjAgeWVhcikgbGlmZSBmb3IgZXF1aXBtZW50IHRoYXQgaGFzIGEgRFMgcmVjb3JkIGZvciB0aGUg cm9vdCBlbWJlZGRlZC4NCg0KR2VvcmdlDQoNCg0KDQoNCg0K From alex@alex.org.uk Fri Jan 28 02:59:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8AF3A6767 for ; Fri, 28 Jan 2011 02:59:28 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOOCzyvIPuwG for ; Fri, 28 Jan 2011 02:59:26 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 7CA643A635F for ; Fri, 28 Jan 2011 02:59:26 -0800 (PST) Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 8A80CC56606; Fri, 28 Jan 2011 11:02:30 +0000 (GMT) Date: Fri, 28 Jan 2011 11:02:29 +0000 From: Alex Bligh To: John Bashinski , dnsext@ietf.org Message-ID: <7780AF9B46FB75DD51990806@Ximines.local> In-Reply-To: <4D41D3E2.6060107@cisco.com> References: <4D41D3E2.6060107@cisco.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 28 Jan 2011 10:59:28 -0000 --On 27 January 2011 15:21:54 -0500 John Bashinski wrote: > II. Provide our own key update service. This might be DNS-based or > HTTP-based. It would provide either: ... > We are obviously capable of this. We also obviously think it's > inferior to (I). I wonder if we're not overcomplicating this, or more accurately looking at this as a problem unique to DNSSEC. With plain old DNS, or DNSSEC, or SSL cert validation, or whatever, there is a set of bootstrap data that need to be distributed with any image. Under certain circumstances (all root servers move IP address, lots of key rollover whilst disconnected from the internet, new CAs, whatever), that data can become out of date in a manner where the protocols themselves can't make things right. There's also a pile of other bootstrap stuff distributed with Large Router Vendor (for any value of LRV) devices, which is the firmware it's designed to run on. One presumes LRV's devices have at least some permanent storage in even if their firmware is non-upgradable, else this problem is near insoluble. So, how about 1. When 'things go wrong', 'periodically', or 'on UI interaction' (obviously the latter to be avoided), device makes a simple http request to a known URL at LRV. 2. Device downloads new bootstrap data. At this stage, it could be bogus. No need to use anything more fancy than http. 3. Device verifies it is genuine, e.g. by checking it is signed with a private key (held securely by the LRV), the public key-pair being in the firmware. If it is, genuine, it replaces the current bootstrap data. DoS attacks, etc. could prevent this upgrade from happening, but that would have to be for an entire key rollover period. -- Alex Bligh From jabley@hopcount.ca Fri Jan 28 06:32:04 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706663A6826 for ; Fri, 28 Jan 2011 06:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HsEbMfTQtB5 for ; Fri, 28 Jan 2011 06:32:03 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id A36F43A67B3 for ; Fri, 28 Jan 2011 06:32:03 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PipTs-000FmB-Kl; Fri, 28 Jan 2011 14:39:25 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: Date: Fri, 28 Jan 2011 09:35:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <530DDAE1-2C3A-4420-AC9A-6C52A13AEDB8@hopcount.ca> References: <4D3F233C.7000900@vpnc.org> <10A3D861-EC02-49FF-BBD1-44843378C9CB@icsi.berkeley.edu> <2BC28AF0-9132-4FFD-9FA6-FCEC29A1D471@hopcount.ca> <50123.1296155020@nsa.vix.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 14:32:04 -0000 On 2011-01-27, at 18:23, Phillip Hallam-Baker wrote: > The risk of doing such a roll would be that the ensuing chaos is then = used as proof that DNSSEC is not ready for prime-time. That is indeed a risk, and to confirm I am not in favour of rolling it = speculatively or without extensive successful prior experimentation and = testing. A benefit of a successful, controlled roll is that we could perhaps = worry less about widespread failure in the event that we need to do an = emergency roll. I'll note that this is probably not the list to debate these things. Joe= From jabley@hopcount.ca Fri Jan 28 06:35:02 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA473A685B for ; Fri, 28 Jan 2011 06:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fam3xiE3LnXF for ; Fri, 28 Jan 2011 06:35:01 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 3FFAC3A6826 for ; Fri, 28 Jan 2011 06:35:01 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PipWl-000FuA-9b; Fri, 28 Jan 2011 14:42:23 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> Date: Fri, 28 Jan 2011 09:37:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2C4E4A03-A589-4B45-BA68-F0E43296E2B0@hopcount.ca> References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext List Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 14:35:02 -0000 On 2011-01-28, at 01:06, David Conrad wrote: > On Jan 26, 2011, at 1:26 PM, Joe Abley wrote: >> Wouter's earlier proposal which is mentioned elsewhere in this thread = had the principle defect that its use relied upon trusting signatures = made by old keys, which in general some of us thought was a poor idea = (e.g. in the event that a key was rolled because it was compromised). >=20 > I don't think that's a risk. If a key is rolled because of a known = compromise, it simply means you can't safely chain from the = old-but-installed-key to the current-but-not-yet-installed key. = Presumably, when a key is known to be compromised, the chain from old to = current keys would be broken such that automated systems would require = human intervention. That's not what the trust-history proposal was about; in that proposal = every outgoing key would be used to sign a copy of its subsequent = incoming key, such that any validator coming on-line from a long time in = the dark would have a path to the current key, no matter what key it was = using before. Downloading the trust anchor from the XML file and finding a way to = trust it does not involve signatures made by previously-used KSKs, = however. Joe= From jbash@cisco.com Fri Jan 28 08:18:49 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6F03A690B for ; Fri, 28 Jan 2011 08:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMNZ6PRQTppt for ; Fri, 28 Jan 2011 08:18:46 -0800 (PST) Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id A19BE3A68B0 for ; Fri, 28 Jan 2011 08:18:45 -0800 (PST) Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id 6945E1A52B7; Fri, 28 Jan 2011 11:21:41 -0500 (EST) Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id 611CE3061; Fri, 28 Jan 2011 11:21:40 -0500 (EST) Message-ID: <4D42ED13.5030000@cisco.com> Date: Fri, 28 Jan 2011 11:21:39 -0500 From: John Bashinski Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext List References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> In-Reply-To: <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF1B32E40119B90E0CA19E2ED" Cc: george.barwood@plueyonder.co.uk Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 16:18:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF1B32E40119B90E0CA19E2ED Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK, now that I'm back on the Net, I'll respond to a few things: Joe Abley wrote: > 1. an XML file, which is signed separately using S/MIME and PGP. This > file contains the current public key and also includes details of al= l > previous public keys, annotated XMLishly to indicate over what perio= ds > of time they were intended to be used. Is there some particular S/MIME or PGP key that's guaranteed to be used to sign every update in the future, and is that key reasonably well controlled (it doesn't have to be perfect)? > 2. an X.509 certificate. One of the products of a key ceremony is an > X.509 CSR, which we sign using an ICANN-maanged CA to produce the > certificate. Same question... if I wake up several years from now, is the root key for that CA going to be the same, or am I going to be able to trace a path from the key I have to the current key? The overriding requirement is that a device be able to choose its trust anchor with no human intervention, based on information that may be several years old. We could work with that if we had a guarantee that: o The ICANN CA was going to be around for the useful life of our products= o It wasn't going to change its root key unless there was some reason good enough to merit knocking hundreds of thousands of devices out of DNS. o The current X.509 cert would always be available in some well-known pla= ce Especially if that well-known place were in the DNS itself, actually, so that we didn't have to rely on being able to get an HTTP request out of who-knows-where in who-knows-what network. But HTTP could be OK, too. I'd have to know more about how ICANN was managing the CA. I assume its key isn't as well controlled as the DNSSEC root key itself, which could be a bit of a problem. We need to have as much confidence in the root as reasonably possible under the circumstances... and we need to be able to give our customers a good reason for every risk we expose them to and for every entity we make their equipment trust. On the other hand, whatever we end up doing doesn't have to be the absolute highest assurance way of learning the current valid root key. I'm only talking about default behavior here. If an administrator wants to manually configure the trust anchor (which will always be possible even on consumer devices), then the administrator can get additional assurance out of band, up to and including attending key ceremonies. There are obvious limits on how certain you can ever be with a years-old trust anchor. > It was our ambition with (2) to publish multiple certificates for ea= ch > anchor, each one representing the same CSR signed by a different > certificate authority. This would allow a software vendor who alread= y > runs a CA (e.g. for the purpose of signing software updates) to > bootstrap trust in a published KSK public key using their own key, b= ut > it might also be useful with well-known and -used commercial CAs, to= o. We probably would NOT use our own CA to sign the CSR. Too much complexity, too many chances for error or compromise, too much extension of trust, requires an extra communication channel we'd prefer not to have to assume was available, too expensive, and perhaps too much liability assumed by us. > [first part of suggested bootstrap procedure snipped for brevity] > - use a local X.509 trust anchor (e.g. for a vendor CA, or the > regular browser list of SysTrust-accredited commercial CAs, or > something else) to verify that the trust anchor retrieved is correct > and proper. I don't think that's unreasonable. I'd prefer to retrieve the cert from DNS rather than over HTTP, but that's not an absolute requirement. I do think that trust anchor ought to be "something else", and that that "something else" ought to be something well defined that everybody can use and rely on. Using a browser CA list is absolutely, unequivocally not acceptable. Using a vendor CA is possible, but it seems to me it costs work and money and complicates things and doesn't improve security... kind of a bad combination. Again, this ICANN CA of which you speak is intriguing, depending on how it's managed. I think the real weakness in DNSSEC is at the registration side. Perhaps one way to look at this is that, so as long as we had enough assurance on the key signing side to give the registration process some headroom to improve into in the future, we'd have reasonably balanced system exposures. Phillip Hallam-Baker wrote: >> Using the current public X.509 PKI is NOT under consideration. > Just to be clear, it was never proposed, except as a straw man by Paul > Wouters. Point taken. > What I suggested was that we look at the possibilities of using X.509 > standards and infrastructure that has been developed to meet similar > considerations in that space. I think it is abundantly clear that we > do not want the criteria for signing the root KSK to be inclusion in > some browser root anchor list. > > X.509 is designed to deal with persistent keys, DNS is not designed to > persist data. =46rom my point of view, how you encapsulate the keys and represent the signatures, DNS or X.509 or PGP or whatever, is an issue of implementation convenience. Using DNS is appealing because it introduces minimal extra code and relies on no extra communication paths, but it's not required. I'm more interested in how the systems are actually being administered and how the key are actually being handled. I'm not familiar with the infrastructure you're talking about, or with what about X.509's design makes it particularly superior for this application. I don't see a big security difference among the formats, at least if you avoid actually trying to use all the baroque X.500 stuff that's buried under X.509 (that would surely trigger software bugs). But I'm prepared to learn. Both you and David Conrad seem to think there's a difference. X.509 (PKIX-ized variant, with all the schema stuff torn out) as a *technology* doesn't cause a lot of heartburn for us, because most Cisco products already include it. It's not as appealing as *only* having to include DNSSEC code, but it's not going to make product teams come after me with pitchforks. The CA and trust management *practices* I've seen associated with X.509 scare me, but I have no objection to adopting a version of X.509 that doesn't bring those practices along with it. One thing to remember that may bear on this, by the way: a lot of these products won't have any security-quality assurance that they know the date or time even *after* they come up, let alone when they're first trying to get DNS working. > I think that we should detach this problem from DNSSEC because we are > going to face the same problem for device keys. We have over the years > created quite a few consortiums that sign various CA certs for device > keys and we are in the process of creating more. > > Ultimately these devices are going to have to tie into enterprise > networks and recognize the root of trust for the enterprise regardless > of whether their function requires them to also process DNSSEC or not. I tend to think the opposite. I'd rather solve DNSSEC without making it depend on much of anything else. The whole can of worms you're talking about is turning into one of my daily obsessions... but it's a lot harder to solve. For one thing, in that context, I don't have the luxury of assuming that there's an identifiable "enterprise" which deserves absolute trust... not for every device, and sometimes not even for different parts of a single device. I don't even get to assume taht there's a well-defined name space. On the other hand, in the overwhelming majority of cases, there really is a single trust root and a single agreed-upon name space for the DNS, at least for the moment. And there's a really simple well-defined delegation architecture. Florian Weimer wrote: > Would it help you if there weren't any vanity key rollovers at all? > [analysis of cases] If IANA/ICANN were to explicitly adopt a "no rollovers except for compromise" policy, it would ease matters for us, but I don't think we're in a position to ask for a fundamental change in the DNS key management design, nor have I or anybody I know of really thought about the implications of such a thing. I'm not sure compromise is quite as black and white as you've presented it, though. In a limited compromise, we might still get more assurance from relying on the old key for a rollover than from relying on *nothing* for a rollover. At the very least, a revocation of the old key would put the device on notice that something was up. So that might mean that we still needed to include rollover code in our products, even if we didn't expect to use it. How well that code would work after a decade or two of non-use, I can't really say... Thierry Moreau wrote: > Just do IV.b. [trust a query for an unvalidated key] as the default, > and provide II.b. [use a new Cisco-signed root key] as an operator > command for those customers who have IT security auditors. >[...] > Otherwise, you rely on some other long term signature key (public data > integrity crypto material) and nobody wants to follow that route > explicitly (IANA might follow that route merely be postponing root KSK > rollover). I do. I've heard others here who seem to be willing to do it. I think I can reasonably expect to get Cisco to do it. In fact, (II)(b) also relies on a long-term key, just one held by Cisco rather than one held by somebody else. As far as I can tell, there are exactly three choices for default, no-touch behavior: 1. Rely on a long-term key of some kind 2. Grab a totally unauthenticated root key and trust it. 3. Don't do DNSSEC at all. Without human intervention, that's all that's available. Refusing to use a long-term key because it might get compromised doesn't improve security. It reduces security, because the only alternative is to use a totally unvalidated trust anchor. In practice, most admins probably do something very much like "dig -t dnskey . > trusted-key.dat" but that's their choice and there's not much we can do about it. And, to be honest, they'll do that because they don't necessarily have many really better options than the software itself has. What I did for the trust anchor in my own resolver wasn't too much better than that, because I had no way to rely on the available PGP keys. So, yes, a long-term key seems to be all that's possible. It's not actually exactly *a* long-term key for every device, but whatever key is wired into an individual device when it ships, or has its software upgraded, is clearly trusted by that device until somebody configures it otherwise or flashes new software on it. I think David Conrad mischaracterizes it a bit with "old trust roots would need to be forever"... they'd only need to be forever for devices that had nothing newer to rely on. > Neither the crypto nor protocol considerations have > prevented this from occurring already. Something about liability, I > guess. Liability is why the PKI operated by Cisco is "private," isn't > it? Er, no. In fact, IANAL, but it probably increases our liability slightly to run that PKI ourselves. We do it because it improves security by not spreading trust to entities that don't need to be trusted. On the other hand, using it for DNSSEC seems as though it *would* spread trust unnecessarily... and cost us money in the process. Brian Dickson wrote: > What if, rather than starting from "old trust roots", it was starting > from "privately-signed trust anchors"? Well, whoever signs it and however it's represented, that key is going to be old. If the device software is 3 years old and the device has no configuration, that key is, in my mind, an "old trust root". > I.e. have IANA have private keys which are used ONLY for this service. > The vendors would include the public keys as trust anchors for > boot-strapping purposes. The key transfer might happen offline, or at > least out-of-band. I imagine we could live with that. Smaller vendors might find it onerous. I think that the administrative complexity of having per-vendor or per-vendor-pool keys would probably actually lead to more exposures than just having one big key, though. And I don't think we want to have to decide which ones of our staff we're going to make into targets by sending them to a key ceremony somewhere... > Open question: > Does not publishing the key make it harder to compromise the key? If it does, I think we're all in deep doo-doo, because practically every security system dreamed up in the last 20 years relies on the assumption that public-key cryptography can be trusted. Usually in many places. Alex Bligh wrote: > So, how about > 1. When 'things go wrong', 'periodically', or 'on UI interaction' > (obviously the latter to be avoided), device makes a simple > http request to a known URL at LRV. > 2. Device downloads new bootstrap data. At this stage, it could > be bogus. No need to use anything more fancy than http. > 3. Device verifies it is genuine, e.g. by checking it is signed > with a private key (held securely by the LRV), the public key-pair > being in the firmware. If it is, genuine, it replaces the > current bootstrap data.=20 The trick with schemes like that is that it tends to be really hard to get them to interact cleanly with other security requirements. We want the user to be able to restore the product to a known state. The more exceptions and different sources of trust are in the device, the harder that is to analyze, and we have to analyze it anew for each class of products. So it's not a non-starter, but it's probably not simple for us, either. -- jbash --------------enigF1B32E40119B90E0CA19E2ED Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1C7RMACgkQQXYiJfd/JbY/MACgmhc/dfYz5cA33dEuDdDPAhpf cKoAnRkbz8XYd/2pjY4/tzwMdAYAWQN7 =zIjb -----END PGP SIGNATURE----- --------------enigF1B32E40119B90E0CA19E2ED-- From ajs@shinkuro.com Fri Jan 28 08:33:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06283A68D9 for ; Fri, 28 Jan 2011 08:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.266 X-Spam-Level: X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UuN6CoyzZji for ; Fri, 28 Jan 2011 08:33:53 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id BCA7C3A68D2 for ; Fri, 28 Jan 2011 08:33:53 -0800 (PST) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A85DE1ECB426 for ; Fri, 28 Jan 2011 16:36:59 +0000 (UTC) Date: Fri, 28 Jan 2011 11:36:56 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110128163656.GC30257@shinkuro.com> References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D42ED13.5030000@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 16:33:54 -0000 No hat. On Fri, Jan 28, 2011 at 11:21:39AM -0500, John Bashinski wrote: > Is there some particular S/MIME or PGP key that's guaranteed to be used > to sign every update in the future > Same question... if I wake up several years from now, is the > root key for that CA going to be the same, or am I going to be > able to trace a path from the key I have to the current key? > > The overriding requirement is that a device be able to choose its trust > anchor with no human intervention, based on information that may be > several years old. That amounts to a requirement that someone guarantee a key is not compromised. Nobody can promise that. This is why I am sceptical of claims that some mechanism other than DNSSEC keys is the right way to do this. I don't see why it's more harmful to say, "Replay the 5011 rollovers as they happened through history," with the possible exposure that one of those was compromised (the compromise being the reason for the rollover, than it is to say, "Trust this key forever." I see no reason to suppose one of those keys more likely to be corrupted than the other, in the case where one is doing regular key rolls. If one is _not_ doing regular key rolls, then things are different. In that case, of course the presence of a mismatch is either an attack or a roll because of compromise. But at that point, it seems to me, one does not want anything automatic. One wants analysis of the situation, no? (Why was the key compromised? What evidence is there that only that key was compromised? &c.) > One thing to remember that may bear on this, by the way: a lot of > these products won't have any security-quality assurance that they > know the date or time even *after* they come up, let alone when > they're first trying to get DNS working. They're going to have a hard time with DNSSEC signatures if they don't have accurate time. > I'm not sure compromise is quite as black and white as you've presented > it, though. In a limited compromise, we might still get more assurance > from relying on the old key for a rollover than from relying on > *nothing* for a rollover. I don't want to put words in Wouter's mouth, but I believe this to be one of the underlying assumptions of the trust-history draft. Indeed, it seems to me that if you have a real compromise, you can just not publish that event in the trust history. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From jabley@hopcount.ca Fri Jan 28 08:37:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015B33A68D2 for ; Fri, 28 Jan 2011 08:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iLS4A7MGyOH for ; Fri, 28 Jan 2011 08:37:09 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id D94533A6830 for ; Fri, 28 Jan 2011 08:37:09 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PirQm-000JvS-Ca; Fri, 28 Jan 2011 16:44:30 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <4D42ED13.5030000@cisco.com> Date: Fri, 28 Jan 2011 11:39:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5B604D69-7E13-438E-9F75-B9E7C5DFF30F@hopcount.ca> References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> To: John Bashinski X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext List , george.barwood@plueyonder.co.uk Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 16:37:11 -0000 Hi John, On 2011-01-28, at 11:21, John Bashinski wrote: > OK, now that I'm back on the Net, I'll respond to a few things: >=20 > Joe Abley wrote: >=20 >> 1. an XML file, which is signed separately using S/MIME and PGP. This >> file contains the current public key and also includes details of = all >> previous public keys, annotated XMLishly to indicate over what = periods >> of time they were intended to be used. >=20 > Is there some particular S/MIME or PGP key that's guaranteed to be = used > to sign every update in the future, and is that key reasonably well > controlled (it doesn't have to be perfect)? The PGP key we're using is published on next to the trust anchors next = on data.iana.org, as is a trust anchor for the IANA CA key we used to = produce the CRT and generate the S/MIME signature. We don't currently = publish practice statements for either key, and have made no assurances = about how stable they will be (i.e. when anybody might expect them to = roll). I appreciate that this is not a good answer for you. We are listening, = however, and the feedback you've provided in just a couple of e-mails is = very useful. >> 2. an X.509 certificate. One of the products of a key ceremony is an >> X.509 CSR, which we sign using an ICANN-maanged CA to produce the >> certificate. >=20 > Same question... if I wake up several years from now, is the > root key for that CA going to be the same, or am I going to be > able to trace a path from the key I have to the current key? >=20 > The overriding requirement is that a device be able to choose its = trust > anchor with no human intervention, based on information that may be > several years old. >=20 > We could work with that if we had a guarantee that: >=20 > o The ICANN CA was going to be around for the useful life of our = products > o It wasn't going to change its root key unless there was some reason > good enough to merit knocking hundreds of thousands of devices out > of DNS. > o The current X.509 cert would always be available in some well-known = place We are not yet ready to publish a Certificate Policy and Practice = Statement for the IANA CA, principally due to (staff) resource = constraints within the group at ICANN that is working on this stuff, but = we expect to publish one at some point. That document will describe the = details you're looking for. Joe= From jbash@cisco.com Fri Jan 28 08:46:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7937D3A67C1 for ; Fri, 28 Jan 2011 08:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KC7ExgM1nP41 for ; Fri, 28 Jan 2011 08:46:55 -0800 (PST) Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id 50CDB3A67B0 for ; Fri, 28 Jan 2011 08:46:55 -0800 (PST) Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id 1222D1A5303; Fri, 28 Jan 2011 11:49:59 -0500 (EST) Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id 174533061; Fri, 28 Jan 2011 11:49:58 -0500 (EST) Message-ID: <4D42F3B5.9070207@cisco.com> Date: Fri, 28 Jan 2011 11:49:57 -0500 From: John Bashinski Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Andrew Sullivan References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <20110128163656.GC30257@shinkuro.com> In-Reply-To: <20110128163656.GC30257@shinkuro.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7C886AE9B7944697DCC9B195" Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 16:46:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C886AE9B7944697DCC9B195 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-01-28 11:36, Andrew Sullivan wrote: >> The overriding requirement is that a device be able to choose its trus= t >> anchor with no human intervention, based on information that may be >> several years old. >=20 > That amounts to a requirement that someone guarantee a key is not > compromised. Actually, what it is is an *acceptance of the risk* that the key will be compromised. Because that's the smallest available risk to accept. The alternative isn't to have better assurance. The alternative is to have no assurance at all. Obviously, if we're going to go down this road, we want to minimize the risk that we accept, but we can't pretend it's not going to be zero. > Nobody can promise that. This is why I am sceptical of > claims that some mechanism other than DNSSEC keys is the right way to > do this. I don't see why it's more harmful to say, "Replay the 5011 > rollovers as they happened through history," with the possible > exposure that one of those was compromised (the compromise being the > reason for the rollover, than it is to say, "Trust this key forever." > I see no reason to suppose one of those keys more likely to be > corrupted than the other, in the case where one is doing regular key > rolls. I'm happy with replaying 5011. I'm also happy with having some key that will sign every new root, provided it's reasonably well controlled. > If one is _not_ doing regular key rolls, then things are different. > In that case, of course the presence of a mismatch is either an attack > or a roll because of compromise. But at that point, it seems to me, > one does not want anything automatic. One wants analysis of the > situation, no? (Why was the key compromised? What evidence is there > that only that key was compromised? &c.) Well, yes... although it's kind of hard to ask Aunt Minnie to evaluate that stuff. For some products, we're just going to have to hope that there's never a compromise, because if there is we're going to take a deluge of support calls. >> One thing to remember that may bear on this, by the way: a lot of >> these products won't have any security-quality assurance that they >> know the date or time even *after* they come up, let alone when >> they're first trying to get DNS working. >=20 > They're going to have a hard time with DNSSEC signatures if they don't > have accurate time. Some of them will rely on the time they have. Some of them probably just won't check. -- jbash --------------enig7C886AE9B7944697DCC9B195 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1C87YACgkQQXYiJfd/JbZUwACaAjSNf5tvLXSd8YTb0YR5BWZs Q4QAnRBA74TG9kW1TZu3NGjiubYhuUTa =NhCL -----END PGP SIGNATURE----- --------------enig7C886AE9B7944697DCC9B195-- From thierry.moreau@connotech.com Fri Jan 28 08:53:18 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926263A67B0 for ; Fri, 28 Jan 2011 08:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHm8GSMomaAN for ; Fri, 28 Jan 2011 08:53:17 -0800 (PST) Received: from bretelle.intaglionic.org (unknown [76.10.176.241]) by core3.amsl.com (Postfix) with ESMTP id 86ABB3A67AE for ; Fri, 28 Jan 2011 08:53:17 -0800 (PST) Received: from [192.168.1.200] (unknown [192.168.1.200]) by bretelle.intaglionic.org (Postfix) with ESMTPA id 3C9BB3076B; Fri, 28 Jan 2011 17:07:30 -0500 (EST) Message-ID: <4D42F4ED.6070502@connotech.com> Date: Fri, 28 Jan 2011 11:55:09 -0500 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: David Conrad References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> In-Reply-To: <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext List Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 16:53:18 -0000 David Conrad wrote: > On Jan 26, 2011, at 1:26 PM, Joe Abley wrote: >> Wouter's earlier proposal which is mentioned elsewhere in this thread had the principle defect that its use relied upon trusting signatures made by old keys, which in general some of us thought was a poor idea (e.g. in the event that a key was rolled because it was compromised). > > I don't think that's a risk. If a key is rolled because of a known compromise, it simply means you can't safely chain from the old-but-installed-key to the current-but-not-yet-installed key. Presumably, when a key is known to be compromised, the chain from old to current keys would be broken such that automated systems would require human intervention. > A known compromise might occur at T[n]-epsilon but detected at T[n]+delta (T[n] is the absolute time of rollover, and epsilon is less than previous cryptoperiod, i.e. T[n]-T[n-1]). Then, human intervention is pointless for systems that has been on-line (too late to do anything) and very much unlikely for those having been off-line during these troubled times. Note that RFC5011 could have been "practiced" (by who would you guess ... IANA) such that the next KSK is pre-announced at T[n-1]+mu (mu is small). If mu+epsilon As far as I can tell the real risk is that an attacker has an increased amount of time to secretly compromise any key in the old to current chain, thereby enabling a MITM attack to insert a branch to a new chain that will end in a malicious key. The continued use of the old keys for something valuable means the keys have to be much stronger and it sort of defeats the purpose of scheduled rolling of keys. > Correct, that is a risk or concern. As a more general observation, what is needed here, in essence, is a small assistance (sign current root KSK) from a public-key based notarization service (the foremost example of a PK scheme with long-term trust at the core of the mission statement). However, neither IETF standardization activities nor organizations involved in the DNS root operations ever considered the PK notarization seriously. Hence my general conclusion that DNSSEC validation must rely on some leap-of-faith somehow somewhere, like it or not. Root KSK recovery may require leap-of-faith. Unless the whole DNSSEC root zone management is revisited, which is not going to occur. Some may not like the color of the room where the leap-of-faith occurs (yes, I did watch portions of the ICANN-staged ceremonies, thanks for the webcast, but no, I don't recall the color of the room). If there is more to it, the requirements should be spelled out in terms of basic deployment strategies for public key capabilities. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 From paul.hoffman@vpnc.org Fri Jan 28 08:55:20 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F383A67B0 for ; Fri, 28 Jan 2011 08:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.745 X-Spam-Level: X-Spam-Status: No, score=-101.745 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrXK0QWoo-RN for ; Fri, 28 Jan 2011 08:55:16 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 0D5853A67AE for ; Fri, 28 Jan 2011 08:55:15 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0SGvxQh023111 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 28 Jan 2011 09:58:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D42F597.8090006@vpnc.org> Date: Fri, 28 Jan 2011 08:57:59 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> In-Reply-To: <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 16:55:20 -0000 Is there a reason that we are only focusing on one of the multiple proposals that this person proposed? Path II was: II. Provide our own key update service. This might be DNS-based or HTTP-based. It would provide either: a. The entire historical chain of DNS root KSKs, with older keys signing newer ones, so that the device could pick up from whatever key it had, OR b. Just the current root key, signed with a key validated by Cisco's private X.509 PKI (the same PKI we use to sign software), OR c. The chain of (a) further signed with a key from (b). We are obviously capable of this. We also obviously think it's inferior to (I). It is not clear that it is inferior to (I) if doing (I) makes the entire system more fragile by adding another moving part. I think (II)(b) looks quite sane, easy to do right now, and if this community ever agrees to a safe way to do (I) *and* implements it, doing a firmware update to switch over to it would not be hard. I would not hold my breath, though. We're talking pre-loaded trust anchors here. They have the same power as pre-loaded software. If (II)(b) works for your software, it should work just fine for your trust anchors. From nweaver@icsi.berkeley.edu Fri Jan 28 09:09:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2196F3A6914 for ; Fri, 28 Jan 2011 09:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcKFYGv1JvMo for ; Fri, 28 Jan 2011 09:09:24 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 66FBC3A68D2 for ; Fri, 28 Jan 2011 09:09:24 -0800 (PST) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 10B8A369FE9; Fri, 28 Jan 2011 09:12:31 -0800 (PST) References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> In-Reply-To: <4D42ED13.5030000@cisco.com> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Fri, 28 Jan 2011 09:12:30 -0800 To: John Bashinski X-Mailer: Apple Mail (2.1082) Cc: dnsext List , george.barwood@plueyonder.co.uk Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 17:09:26 -0000 It really seems to me that the only thing that works to bootstrap a = device which may have missed arbitrary key rollovers is the following: If the root KSK is due to 'once every 5 years/because we feel like it/we = want to see what happens' rollover event (98% chance): As long as all the historical data is available someplace that the = device knows about (eg. = http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02 . Or = pick whatever...), there is no excuse for not using this style of = mechanism. Its not only secure, but MORE secure than any other automatic = alternative because it doesn't add to the 'you need to trust' keyset. =20= Anything else MUST either add additional keys to the trusted root, = and/or becomes the trusted root instead. In the former you're weakening = the system (you now trust both the . KSK AND some 'random' PKI = certificate, as a compromise of EITHER is sufficient to break your = security), in the latter you're just replacing one key roll problem with = a second (how do you roll the PKI certificate?). And although the root SHOULD provide such a trust history, any vendor = COULD provide its own trust history as a backup/until IANA decides = formally it will provide such a mechanism. It doesn't increase the = trust in the vendor. Thus the only question on a normal rollover is what to do if the update = fails because the historic information is unavailable. My thought would be a 'limited leap of faith': Just ask the root for its = KSK, accept the result temporarily, but keep retrying to get the full = chain once a minute for the first 10 minutes, once every 10 minutes for = the first day, and once a day thereafter. Yet this temporary result should ONLY be used for validating A records = and the like, NOT be used for validating security records (eg, like the = DANE working group is proposing). =20 Fortunately, since using DNSSEC to validate security-relevenat records = requires new API calls, this should be a reasonable to implement = restriction. Thus a denial-of-service from a MitM will be able to muck with A records = fine, but can't muck with security records.=20 Since such a MitM could just as easily muck with the final traffic in = most cases, this is not a substantial increase in security risk, while = gaining the ability to automatically role the root for a device that has = been offline since who-knows-when, including being able to roll the = device when the history service fails. Instead, if the root KSK is rolled due to a key compromise: Well, things are ugly. But things have BEEN ugly for the whole period = of time when the compromise was unknown (and someone who compromises the = root key is going to have an incentive to keep it VERY quiet). =20 And if this requires human intervention to fix, so be it, its going to = be such a big mess that human-in-the-loop will be needed for so many = other things that, hey, thats life. Someone invents a practical quantum computer: Well, DNSSEC is FUBARed then. Back to the drawing board. From jbash@cisco.com Fri Jan 28 09:25:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672393A68D2 for ; Fri, 28 Jan 2011 09:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3irsiVrEVog for ; Fri, 28 Jan 2011 09:25:20 -0800 (PST) Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id 7B19C3A67C2 for ; Fri, 28 Jan 2011 09:25:20 -0800 (PST) Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id 21B861A5305; Fri, 28 Jan 2011 12:28:24 -0500 (EST) Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id F3FE76726; Fri, 28 Jan 2011 12:28:22 -0500 (EST) Message-ID: <4D42FCB6.70005@cisco.com> Date: Fri, 28 Jan 2011 12:28:22 -0500 From: John Bashinski Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Hoffman References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42F597.8090006@vpnc.org> In-Reply-To: <4D42F597.8090006@vpnc.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA8413E90374F2AED8CE658D3" Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 17:25:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA8413E90374F2AED8CE658D3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-01-28 11:57, Paul Hoffman wrote: > Is there a reason that we are only focusing on one of the multiple > proposals that this person proposed? Path II was: > > II. Provide our own key update service. This might be DNS-based or > HTTP-based. It would provide either: >=20 > a. The entire historical chain of DNS root KSKs, with older keys > signing newer ones, so that the device could pick up from > whatever key it had, OR >=20 > b. Just the current root key, signed with a key validated by > Cisco's private X.509 PKI (the same PKI we use to sign > software), OR >=20 > c. The chain of (a) further signed with a key from (b). >=20 > We are obviously capable of this. We also obviously think it's > inferior to (I). > It is not clear that it is inferior to (I) if doing (I) makes the > entire system more fragile by adding another moving part. I'm not sure I see how it does that. The new "moving part" isn't in the main trust path. It's off to the side, and it doesn't affect the basic system. It only affects devices that choose to validate by default and choose to bootstrap from old keys. If you do want to think of that as a new moving part, then if you have every vendor do it separately,what you've really done is to add N new moving parts instead of one. > I think (II)(b) looks quite sane, easy to do right now, and if this > community ever agrees to a safe way to do (I) *and* implements it, > doing a firmware update to switch over to it would not be hard. I > would not hold my breath, though. > We're talking pre-loaded trust anchors here. They have the same power > as pre-loaded software. If (II)(b) works for your software, it should > work just fine for your trust anchors. Actually, it's not quite the preloaded trust anchors we're talking about. It's the updated keys that get validated using those preloaded anchors. It's a given that you're going to start with some key to bootstrap your trust in DNSSEC, and that key is going to be preloaded. Then you're going to download some updated DNSSEC trust root, and validate it against your preloaded key. The question is how the downloaded key got signed. =46rom my point of view, some person or persons, inside or outside of Cisco, is going to have the ability to cause a new DNSSEC root key to get signed using that preloaded key. That person or persons is NOT going to be the same person or persons who generates the software loads. I'm adding a new trusted entity to the system. I think you're saying "well, let Cisco be trusted; it's trusted already anyway". That's true if you look at Cisco as a monolith, but I don't have that luxury. Something has to be set up inside Cisco to deal with handling these keys. The complexity still exists; it's just been made less visible from a certain point of view. So, the question is whether it's better to have a single, publicly visible process that may be able to break a very large number of devices, or a large number of hidden processes each of which can break a smaller number of devices. I tend to prefer the former. -- jbash --------------enigA8413E90374F2AED8CE658D3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1C/LYACgkQQXYiJfd/JbZjFwCgmcsqs1+rg0Oprqq64lw6LnWX y5kAoJCd8qQD+Kk9XT06Tq7WC0rgjLtq =kuXs -----END PGP SIGNATURE----- --------------enigA8413E90374F2AED8CE658D3-- From Ted.Lemon@nominum.com Fri Jan 28 09:29:17 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A96E3A6918 for ; Fri, 28 Jan 2011 09:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.439 X-Spam-Level: X-Spam-Status: No, score=-106.439 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeYPWZeu6N2u for ; Fri, 28 Jan 2011 09:29:15 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id CE23F3A67C2 for ; Fri, 28 Jan 2011 09:29:14 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTUL9pcDq1hxmPSiGosPJL5siKp9uIMt/@postini.com; Fri, 28 Jan 2011 09:32:21 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4E9591B82ED for ; Fri, 28 Jan 2011 09:32:21 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3D02119005D; Fri, 28 Jan 2011 09:32:21 -0800 (PST) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 28 Jan 2011 09:32:20 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu> Date: Fri, 28 Jan 2011 12:32:15 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu> To: Nicholas Weaver X-Mailer: Apple Mail (2.1082) Cc: george.barwood@plueyonder.co.uk, dnsext List Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 17:29:17 -0000 On Jan 28, 2011, at 12:12 PM, Nicholas Weaver wrote: > As long as all the historical data is available someplace that the = device knows about (eg. = http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02 . Or = pick whatever...), there is no excuse for not using this style of = mechanism. There's no way to validate this, so you might was well be trusting = instructions written on a bathroom wall. It's important to recognize two aspects of a key here: the value of the = key, and the security of the key. The root zone key is extraordinarily = valuable; if you have it, you can do all kinds of fun bad things with = it. So the incentive to compromise this key is very high. A corporate key for signing firmware is less valuable. Of course, if = it's used to sign firmware in millions of devices, it's not a *lot* less = valuable, but it is less valuable. The fewer devices it was used in, = the less valuable it is. This suggests another knob to tweak. Firmware in self-updating devices = should have a manufacturer-configured key, but the manufacturer should = use that key in no more than N devices, for some TBD value of N. This = reduces the value of the firmware key, more substantially the smaller N = is, to a limit of N=3D1. > Anything else MUST either add additional keys to the trusted root, = and/or becomes the trusted root instead. In the former you're weakening = the system (you now trust both the . KSK AND some 'random' PKI = certificate, as a compromise of EITHER is sufficient to break your = security), in the latter you're just replacing one key roll problem with = a second (how do you roll the PKI certificate?). I think it's important to realize that any device that auto-updates = already has one of these keys in it, and that key can be used to update = the root zone key on the device, if the device even has a root zone key = on it. So it's not the case that this mechanism makes things less = secure. It's certainly possible to contemplate some regime in which the device = key *couldn't* be used to update the root zone key, but I am skeptical = that this would be practiced. So in practice, this problem exists, and = is not going away, so it would be better to describe a set of best = practices for vendors who use this technique, rather than pretending the = technique isn't being used. We can certainly have a debate about which sort of compromise is more or = less likely, but I find the idea of a "limited leap of faith" sort of = like the idea of a "limited leap off a cliff." Unless the cliff is = only a few feet high, the absolute height of the cliff is immaterial. From alex@alex.org.uk Fri Jan 28 09:31:42 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22D2E3A6920 for ; Fri, 28 Jan 2011 09:31:42 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgDFbQFBnBHU for ; Fri, 28 Jan 2011 09:31:41 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 41C5E3A68CB for ; Fri, 28 Jan 2011 09:31:40 -0800 (PST) Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 78EC4C56648; Fri, 28 Jan 2011 17:34:46 +0000 (GMT) Date: Fri, 28 Jan 2011 17:34:45 +0000 From: Alex Bligh To: John Bashinski , Paul Hoffman Message-ID: <6E1BDC90802ED85AFE548AD0@Ximines.local> In-Reply-To: <4D42FCB6.70005@cisco.com> References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42F597.8090006@vpnc.org> <4D42FCB6.70005@cisco.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 28 Jan 2011 17:31:42 -0000 --On 28 January 2011 12:28:22 -0500 John Bashinski wrote: > That person or persons is NOT going to be the same person or persons > who generates the software loads. I'm adding a new trusted entity > to the system. Isn't the person who generates software loads already going to have to put the (then current) root key / zone into the image? If so, isn't this person already a trusted entity? -- Alex Bligh From jbash@cisco.com Fri Jan 28 09:49:38 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112143A6921 for ; Fri, 28 Jan 2011 09:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFaf0K7SSW1Y for ; Fri, 28 Jan 2011 09:49:37 -0800 (PST) Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id CE0E93A68CB for ; Fri, 28 Jan 2011 09:49:36 -0800 (PST) Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id B0E9E1A530B; Fri, 28 Jan 2011 12:52:38 -0500 (EST) Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id BA1B56726; Fri, 28 Jan 2011 12:52:37 -0500 (EST) Message-ID: <4D430265.8020100@cisco.com> Date: Fri, 28 Jan 2011 12:52:37 -0500 From: John Bashinski Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Lemon References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1C442EE4D881C2DB890C41C3" Cc: Nicholas Weaver , dnsext List , george.barwood@plueyonder.co.uk Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 17:49:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C442EE4D881C2DB890C41C3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-01-28 12:32, Ted Lemon wrote: > On Jan 28, 2011, at 12:12 PM, Nicholas Weaver wrote: >> As long as all the historical data is available someplace that the >> device knows about >> (eg. http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-0= 2 >> . Or pick whatever...), there is no excuse for not using this style >> of mechanism. > There's no way to validate this, so you might was well be trusting > instructions written on a bathroom wall. You validate it by tracing the signature chain from whatever key you start with through the first one. That does mean trusting the whole chain, but it's definitely validation. > This suggests another knob to tweak. Firmware in self-updating > devices should have a manufacturer-configured key, but the > manufacturer should use that key in no more than N devices, for some > TBD value of N. This reduces the value of the firmware key, more > substantially the smaller N is, to a limit of N=3D1. There are tradeoffs there, and they're not just cost tradeoffs. A system for managing a whole bunch of keys is necessarily more complex than a system for managing just one. It handles higher volumes of data. It updates things more frequently (which means updates can't be scrutinized as hard). It has more parts that have to be kept online or near-line. Those all hurt the security. >> Anything else MUST either add additional keys to the trusted root, >> and/or becomes the trusted root instead. In the former you're >> weakening the system (you now trust both the . KSK AND some 'random' >> PKI certificate, as a compromise of EITHER is sufficient to break >> your security), in the latter you're just replacing one key roll >> problem with a second (how do you roll the PKI certificate?). > I think it's important to realize that any device that auto-updates > already has one of these keys in it, and that key can be used to > update the root zone key on the device, if the device even has a root > zone key on it. So it's not the case that this mechanism makes things > less secure. Not all devices auto-update. In Cisco's case, I don't think we have ANY pro gear that auto-updates, and most of our consumer gear doesn't auto-update, either. What you're talking about is one of the reasons for that, and we probably won't have widespread auto-update until we have better answers. Of course, it's also true that it's probably pretty easy to trick most people into manually installing bogus software (or DNSSEC roots) on their devices, but we'd rather not make that an automated thing... > We can certainly have a debate about which sort of compromise is more > or less likely, but I find the idea of a "limited leap of faith" sort > of like the idea of a "limited leap off a cliff." Unless the cliff is > only a few feet high, the absolute height of the cliff is immaterial. That's a deeply misleading analogy, because the effects aren't similar at all. Temporal extent of exposure matters. You can: 1. Not validate at all. This makes you pretty easy to spoof, at any time anybody decides to spoof you. 2. Learn the root key by "pure faith" at initial installation. This is a very significant improvement; it means that anybody who wants to spoof you has to be prepared to do it at a specific time (which may be hard to predict). They have to plan in advance to target you specifically. And they have to get you on the first try. 3. Learn the root key by "limited faith". This is another siginificant improvement; it means that somebody has to keep a DoS or something running continuously from the moment you're installed up through the moment they want to feed you bad data. Which could be months. If they slip up at any time, you learn a good key and they lose the ability to hurt you. And they're very likely to be detected. 4. Learn the root key using a bootstrap key and never rely on "faith". Nobody can ever spoof you, although you still have exposures from key compromise or people leading the legitimate key holder to sign something it shouldn't. Those aren't remotely equivalent exposures. -- jbash --------------enig1C442EE4D881C2DB890C41C3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DAmUACgkQQXYiJfd/JbZJOQCfSsErtCd6xxuTcRd/+BpoWBaE DWkAn0ryN7ZwDTKJJ2FGM17ePb87jag+ =D2l9 -----END PGP SIGNATURE----- --------------enig1C442EE4D881C2DB890C41C3-- From jbash@cisco.com Fri Jan 28 09:54:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A643A6941 for ; Fri, 28 Jan 2011 09:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS6NkpBn0KGp for ; Fri, 28 Jan 2011 09:54:47 -0800 (PST) Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id 5ACB63A68CB for ; Fri, 28 Jan 2011 09:54:47 -0800 (PST) Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id 9C3E81A530B; Fri, 28 Jan 2011 12:57:50 -0500 (EST) Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id B7B836726; Fri, 28 Jan 2011 12:57:49 -0500 (EST) Message-ID: <4D43039D.4080604@cisco.com> Date: Fri, 28 Jan 2011 12:57:49 -0500 From: John Bashinski Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Alex Bligh References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42F597.8090006@vpnc.org> <4D42FCB6.70005@cisco.com> <6E1BDC90802ED85AFE548AD0@Ximines.local> In-Reply-To: <6E1BDC90802ED85AFE548AD0@Ximines.local> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF09041A195BF86AE1C66D9A7" Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 17:54:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF09041A195BF86AE1C66D9A7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-01-28 12:34, Alex Bligh wrote: >> That person or persons is NOT going to be the same person or persons >> who generates the software loads. I'm adding a new trusted entity >> to the system. >=20 > Isn't the person who generates software loads already going to have > to put the (then current) root key / zone into the image? If so, isn't > this person already a trusted entity? Yes, but originally I had *just* the software person. Now I have the software person *plus* the person who signs new DNSSEC keys for the DNSSEC discovery process. Also, the person generating software loads is only trusted at software installation time. The person generating DNSSEC keys is trusted at DNSSEC key learning time. So there's a temporal extension of trust as well. -- jbash --------------enigF09041A195BF86AE1C66D9A7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DA50ACgkQQXYiJfd/Jba1cACeKzCtELxXWrAGueiIt87MozQR 1GkAmgLjD6nsBoJ1FTMIYdwl3kRTNnap =Xuy8 -----END PGP SIGNATURE----- --------------enigF09041A195BF86AE1C66D9A7-- From Ed.Lewis@neustar.biz Fri Jan 28 10:07:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB393A6889 for ; Fri, 28 Jan 2011 10:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-9CvH7EbUBs for ; Fri, 28 Jan 2011 10:07:44 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E8F4B3A6859 for ; Fri, 28 Jan 2011 10:07:43 -0800 (PST) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p0SIAgBp008901; Fri, 28 Jan 2011 13:10:43 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.110] by Work-Laptop-2.local (PGP Universal service); Fri, 28 Jan 2011 13:10:49 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 28 Jan 2011 13:10:49 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D430265.8020100@cisco.com> References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu> <4D430265.8020100@cisco.com> Date: Fri, 28 Jan 2011 13:08:28 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [dnsext] A question about the need for "historical keys" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 18:07:45 -0000 This question is mostly aimed at Paul Wouter and others that are pushing for a DNS-based mechanism to update keys. Why is the updating of the DNSSEC root-zone KSK different than updating any other piece of data, configuration, or code (soft or firmware) in a dormant piece of equipment? I ask this to see if there is some requirement that leads to a crafted solution for this problem. I just don't see that this is a special case, we have other ways to update stuff already. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 With a week old newborn at home, I've discovered that the only difference between him and me is that I have to go to work daily. That's not fair! Ma! From paul.hoffman@vpnc.org Fri Jan 28 10:09:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52C83A690F for ; Fri, 28 Jan 2011 10:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.748 X-Spam-Level: X-Spam-Status: No, score=-101.748 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0quceYpLPECr for ; Fri, 28 Jan 2011 10:09:55 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CDF263A6908 for ; Fri, 28 Jan 2011 10:09:55 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0SID1XY026267 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 28 Jan 2011 11:13:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D43072D.6090503@vpnc.org> Date: Fri, 28 Jan 2011 10:13:01 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42F597.8090006@vpnc.org> <4D42FCB6.70005@cisco.com> In-Reply-To: <4D42FCB6.70005@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 18:09:56 -0000 On 1/28/11 9:28 AM, John Bashinski wrote: > On 2011-01-28 11:57, Paul Hoffman wrote: > >> Is there a reason that we are only focusing on one of the multiple >> proposals that this person proposed? Path II was: >> >> II. Provide our own key update service. This might be DNS-based or >> HTTP-based. It would provide either: >> >> a. The entire historical chain of DNS root KSKs, with older keys >> signing newer ones, so that the device could pick up from >> whatever key it had, OR >> >> b. Just the current root key, signed with a key validated by >> Cisco's private X.509 PKI (the same PKI we use to sign >> software), OR >> >> c. The chain of (a) further signed with a key from (b). >> >> We are obviously capable of this. We also obviously think it's >> inferior to (I). > >> It is not clear that it is inferior to (I) if doing (I) makes the >> entire system more fragile by adding another moving part. > > I'm not sure I see how it does that. The new "moving part" isn't in > the main trust path. It's off to the side, and it doesn't affect > the basic system. It only affects devices that choose to validate > by default and choose to bootstrap from old keys. A moving part that is "off to the side" but becomes "quite central when something goes wrong" is not really "off to the side". It goes from unimportant to completely critical just like very other moving part does. > If you do want to think of that as a new moving part, then if you have > every vendor do it separately,what you've really done is to add N > new moving parts instead of one. We fully disagree. Trust anchor loading (whether initial or while the system is running) is *always* unique to every vendor and, quite frankly, to every customer who actually cares about their trust anchors. You may not think this because 99.99% of users of trust anchor stores do this blindly, but many of Cisco's router customers (and folks like them that the DNSSEC community care about) do care about this. Having each vendor "do this" with DNS security is exactly the same as having each vendor "do this" with software security. The fact that Cisco has a PKIX signing key that verifies software loads differentiates it from some of its competitors who don't do any software validation, and makes it similar to some of its competitors that do it in similar ways. Trust anchors are the same. >> I think (II)(b) looks quite sane, easy to do right now, and if this >> community ever agrees to a safe way to do (I) *and* implements it, >> doing a firmware update to switch over to it would not be hard. I >> would not hold my breath, though. > >> We're talking pre-loaded trust anchors here. They have the same power >> as pre-loaded software. If (II)(b) works for your software, it should >> work just fine for your trust anchors. > > Actually, it's not quite the preloaded trust anchors we're talking > about. It's the updated keys that get validated using those preloaded > anchors. Those have identical security properties to the users. If their vendor made it hard or impossible to get the latter when needed, the users will (rightly, IMHO) blame the vendor for the users' reduction in security. > It's a given that you're going to start with some key to bootstrap your > trust in DNSSEC, and that key is going to be preloaded. Then you're > going to download some updated DNSSEC trust root, and validate it > against your preloaded key. > > The question is how the downloaded key got signed. Yep. > From my point of view, some person or persons, inside or outside of > Cisco, is going to have the ability to cause a new DNSSEC root key to > get signed using that preloaded key. > > That person or persons is NOT going to be the same person or persons > who generates the software loads. I'm adding a new trusted entity > to the system. It could be / should be a person who is trusted within Cisco to the same level as the person who generated the software loads. She doesn't have to be the same person. > I think you're saying "well, let Cisco be trusted; it's trusted already > anyway". That's true if you look at Cisco as a monolith, but I don't > have that luxury. Something has to be set up inside Cisco to deal with > handling these keys. If you trusted Employee A to fetch the DNS root key at time X and include it in the initial firmware loads, you can trust Employee A at time Y to do it again for updates, or you can trust Employee B at time Y if you would have trusted Employee B to do the firmware loads. > The complexity still exists; it's just been made > less visible from a certain point of view. Fully agree. > So, the question is whether it's better to have a single, publicly > visible process that may be able to break a very large number > of devices, or a large number of hidden processes each of which > can break a smaller number of devices. That's one way to phrase it. Another would be "whether it's better to have a single, publicly visible process that may be able to break a very large number of devices and is more complicated than the already-complicated process we have now, or a large number of hidden processes that have the same local security properties we have now where those hidden processes already can (and do!) break a smaller number of devices". > I tend to prefer the former. Understood. From a security and deployment standpoint, the latter is what we already have today, and it might be better to continue to do it (and maybe even document it) than to make the current DNSSEC infrastructure more fragile. From Ted.Lemon@nominum.com Fri Jan 28 10:18:54 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BB463A6939 for ; Fri, 28 Jan 2011 10:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlXOXtL5mswK for ; Fri, 28 Jan 2011 10:18:53 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 4F75C3A692E for ; Fri, 28 Jan 2011 10:18:53 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTUMJR5gbxAC7+QpgImfiuEflatUCtl5Z@postini.com; Fri, 28 Jan 2011 10:22:00 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 224DF1B82F5 for ; Fri, 28 Jan 2011 10:21:56 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E5FCC19005D; Fri, 28 Jan 2011 10:21:55 -0800 (PST) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 28 Jan 2011 10:21:55 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4D430265.8020100@cisco.com> Date: Fri, 28 Jan 2011 13:21:50 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu> <4D430265.8020100@cisco.com> To: John Bashinski X-Mailer: Apple Mail (2.1082) Cc: Nicholas Weaver , dnsext List , george.barwood@plueyonder.co.uk Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 18:18:54 -0000 > 3. Learn the root key by "limited faith". This is another siginificant > improvement; it means that somebody has to keep a DoS or something > running continuously from the moment you're installed up through > the moment they want to feed you bad data. Which could be > months. If they slip up at any time, you learn a good key and they > lose the ability to hurt you. And they're very likely to be > detected. I think the reason I disagree with you on this is that your threat model = is narrower than mine. I agree that for this threat model, and the = others you describe, "limited faith" is an improvement. But what I'm = concerned about are situations where the network is "owned," as Nicholas = likes to put it. In these situations, a compromise that allows the = attacker to present a consistent DNS using an old compromised root is a = lot harder to detect than one that requires the attacker to know the = specific key for your device that must be compromised. I am not arguing that consistency checks are a bad idea. If you can = catch your attacker in a lie, that's good. If your attacker can't = reliably lie to you, that's also good. But the particular leap of faith involved in tracing back history using = an unauthenticated history list is useless in the face of a key = compromise, because once you have that key, you can create a fake = history that looks just as legitimate as the real history would; the = fact that it validates does not mean that the later key is legitimate. > There are tradeoffs there, and they're not just cost tradeoffs. A > system for managing a whole bunch of keys is necessarily more complex > than a system for managing just one. It handles higher volumes of > data. It updates things more frequently (which means updates can't be > scrutinized as hard). It has more parts that have to be kept online or > near-line. Those all hurt the security. This isn't strictly true. DNSSEC is an example of a system that allows = for the management of a large set of keys in a secure manner, with the = sensitive secrets maintained offline, and yet with full validation = possible online. I don't mean to say that there would be no cost associated with a system = like the one I'm talking about, but I think the per-unit cost would be = reasonable for useful values of N. I won't get into the question of auto-update; suffice it to say that no = consensus exists that auto-update, done well, is *less* secure than = manual-only updates. From jbash@cisco.com Fri Jan 28 10:23:27 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE56E3A6932 for ; Fri, 28 Jan 2011 10:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7h6kAO1aiIhp for ; Fri, 28 Jan 2011 10:23:27 -0800 (PST) Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id D06C13A67D1 for ; Fri, 28 Jan 2011 10:23:26 -0800 (PST) Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id 2435B1A530B; Fri, 28 Jan 2011 13:26:31 -0500 (EST) Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id 519EC3061; Fri, 28 Jan 2011 13:26:30 -0500 (EST) Message-ID: <4D430A56.9040600@cisco.com> Date: Fri, 28 Jan 2011 13:26:30 -0500 From: John Bashinski Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Edward Lewis References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu> <4D430265.8020100@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB0C72AC147F87B55B9E71D00" Cc: dnsext@ietf.org Subject: Re: [dnsext] A question about the need for "historical keys" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 18:23:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB0C72AC147F87B55B9E71D00 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-01-28 13:08, Edward Lewis wrote: > Why is the updating of the DNSSEC root-zone KSK different than > updating any other piece of data, configuration, or code (soft or > firmware) in a dormant piece of equipment? Well, first of all, DNS is absolutely pervasive. Everything uses it. Second, you may need DNS as part of the network infrastructure to let you get the other updates. Third, DNS keys get updated on a schedule not under the vendor's control, by an entity not under the vendor's control, and we're only guaranteed 60 days' notice. And the users' trust for those data is fundamentally in that entity, not in the vendor, so it's *appropriate* that that entity get control over the keys. Fourth, for much of the equipment we're dealing with, this may be the *only* piece of information that ever gets updated during the entire lifetime of the product. Take the Linksys home routers. My guess is that maybe a couple of percent of them *ever* get firmware updates. Most users don't even change the factory default configuation. They plug the router in, plug some computers into the other side, and forget about it. At most they set up WiFi encryption, and that only reluctantly, because we force it on them. And that's an entirely local process in which they have to trust nothing. They definitely don't have to evaluate the trustworthiness of some random string of hex digits downloaded from some alphabet soup entity they've never heard of, in order to protect from a threat they don't understand. People install these things and forget them unless they break. The standard operational model simply does not include software updates. > I ask this to see if there is some requirement that leads to a crafted > solution for this problem. I just don't see that this is a special > case, we have other ways to update stuff already. Every device has its own specific way or ways to update its own specific set of data. So we can either fix DNS once, or we can rework every one of those thousands of update paths to support DNS. -- jbash --------------enigB0C72AC147F87B55B9E71D00 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DClYACgkQQXYiJfd/Jba/TwCgiXLky8IcKXwHGuGSqRNv0D8V iZgAoKH1nVm8Hr6ZMFgYJ3U2J6G0+1O+ =SRH7 -----END PGP SIGNATURE----- --------------enigB0C72AC147F87B55B9E71D00-- From Ted.Lemon@nominum.com Fri Jan 28 10:29:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450BB3A6911 for ; Fri, 28 Jan 2011 10:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd5E4jx9fReC for ; Fri, 28 Jan 2011 10:29:02 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 878913A6924 for ; Fri, 28 Jan 2011 10:29:01 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTUMLqIKPqDtdbtKPhGd3B5pyo+iKMFlh@postini.com; Fri, 28 Jan 2011 10:32:08 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3E8931B82F4 for ; Fri, 28 Jan 2011 10:32:08 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 291F119005D; Fri, 28 Jan 2011 10:32:08 -0800 (PST) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 28 Jan 2011 10:32:05 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4D430A56.9040600@cisco.com> Date: Fri, 28 Jan 2011 13:31:56 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu> <4D430265.8020100@cisco.com> <4D430A56.9040600@cisco.com> To: John Bashinski X-Mailer: Apple Mail (2.1082) Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] A question about the need for "historical keys" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 18:29:03 -0000 On Jan 28, 2011, at 1:26 PM, John Bashinski wrote: > Take the Linksys home routers. My guess is that maybe a couple of > percent of them *ever* get firmware updates. Before you use this as a basis for argument, it might be worth your = while to (not in this discussion) explore the question of *why* they = don't get updates. =46rom my own personal experience, this is not = because of a lack of demand. From jbash@cisco.com Fri Jan 28 10:51:14 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7F83A684F for ; Fri, 28 Jan 2011 10:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viVnpXpWkc11 for ; Fri, 28 Jan 2011 10:51:14 -0800 (PST) Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id CA5D33A67D1 for ; Fri, 28 Jan 2011 10:51:13 -0800 (PST) Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id BDA3D1A530B; Fri, 28 Jan 2011 13:54:15 -0500 (EST) Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id 6E8283061; Fri, 28 Jan 2011 13:54:14 -0500 (EST) Message-ID: <4D4310D6.7090007@cisco.com> Date: Fri, 28 Jan 2011 13:54:14 -0500 From: John Bashinski Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Lemon References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu> <4D430265.8020100@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF6D3467728423CBF74072E87" Cc: Nicholas Weaver , dnsext List , george.barwood@plueyonder.co.uk Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 18:51:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6D3467728423CBF74072E87 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-01-28 13:21, Ted Lemon wrote: >> 3. Learn the root key by "limited faith". This is another siginificant= >> improvement; it means that somebody has to keep a DoS or something >> running continuously from the moment you're installed up through >> the moment they want to feed you bad data. Which could be >> months. If they slip up at any time, you learn a good key and they >> lose the ability to hurt you. And they're very likely to be >> detected. > I think the reason I disagree with you on this is that your threat > model is narrower than mine. I agree that for this threat model, and > the others you describe, "limited faith" is an improvement. But what > I'm concerned about are situations where the network is "owned," as > Nicholas likes to put it. I think that maintaining "ownership" of the network for that long is roughly equivalent to "keeping a DoS or something going" for that long. It's going to be very, very hard to do that without getting busted. > In these situations, a compromise that > allows the attacker to present a consistent DNS using an old > compromised root is a lot harder to detect than one that requires the > attacker to know the specific key for your device that must be > compromised. So, the threat you're suggesting is an adversary which can: 1. Compromise a DNS root key, however old that key may be. 2. Completely or nearly completely control all traffic I receive from the Net (and presumably the the traffic I send, as well). I guess my answer is that enemies that powerful may indeed be out of scope for default behavior. If you're worried about that, you may need to do something out of band to validate your DNSSEC keys. The current plan requires every product to enable you to do that, by the way. We just plain may not have what it takes to address that threat by default. If it comes to a choice between not addressing that threat and not addressing *any* threat, I think it's pretty obvious that we'll shed that threat. > But the particular leap of faith involved in tracing back history > using an unauthenticated history list is useless in the face of a key > compromise, because once you have that key, you can create a fake > history that looks just as legitimate as the real history would; the > fact that it validates does not mean that the later key is legitimate. Well, yes, but "useless in the face of a key compromise" is "useless in the face of what we hope is a very improbable event, which if it does happen is probably going to be done by somebody who's going to make a bigger splash than just hitting me personally". All of DNSSEC is useless in the face of a compromise of the current root key, but I still think it adds valuable security. >> There are tradeoffs there, and they're not just cost tradeoffs. A >> system for managing a whole bunch of keys is necessarily more complex >> than a system for managing just one. It handles higher volumes of >> data. It updates things more frequently (which means updates can't be >> scrutinized as hard). It has more parts that have to be kept online or= >> near-line. Those all hurt the security. > This isn't strictly true. DNSSEC is an example of a system that > allows for the management of a large set of keys in a secure manner, > with the sensitive secrets maintained offline, and yet with full > validation possible online. It does that with a single ultimately trusted key. I thought that was what you wanted to avoid. Maybe I don't understand what you're suggesting? > I won't get into the question of auto-update; suffice it to say that > no consensus exists that auto-update, done well, is *less* secure than > manual-only updates. This is a complicated subject and it's off-topic. Suffice it to say that I do understand that. It's even more complicated than "no consensus that it's less secure". There's not even a consensus on how the security should be measured or which concerns matter. As far as I can tell, whether auto-update is more secure for you depends on who you are and what you care about. Nonetheless, we don't have auto-update right now, and we probably won't have widespread auto-update for quite a while, in part because we don't know how to address those very issues. -- jbash --------------enigF6D3467728423CBF74072E87 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DENYACgkQQXYiJfd/JbbVGwCfXox2L/Hskv6qAK+VhpVwFqLG KGoAoJfiQh5cy59ArTLkN0UzJ0aAuoPM =qeDF -----END PGP SIGNATURE----- --------------enigF6D3467728423CBF74072E87-- From paul@xelerance.com Fri Jan 28 11:09:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6333A680E for ; Fri, 28 Jan 2011 11:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agpHaKHNorzm for ; Fri, 28 Jan 2011 11:09:10 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 648283A67F7 for ; Fri, 28 Jan 2011 11:09:10 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 8967FC542; Fri, 28 Jan 2011 14:12:15 -0500 (EST) Date: Fri, 28 Jan 2011 14:12:15 -0500 (EST) From: Paul Wouters To: Ted Lemon In-Reply-To: Message-ID: References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu> <4D430265.8020100@cisco.com> <4D430A56.9040600@cisco.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] A question about the need for "historical keys" X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 19:09:11 -0000 On Fri, 28 Jan 2011, Ted Lemon wrote: > On Jan 28, 2011, at 1:26 PM, John Bashinski wrote: >> Take the Linksys home routers. My guess is that maybe a couple of >> percent of them *ever* get firmware updates. > > Before you use this as a basis for argument, it might be worth your while to (not in this discussion) explore the question of *why* they don't get updates. From my own personal experience, this is not because of a lack of demand. You can ask the firefox people. They have seen a massive increase in updates just by sneakilly downloading the update in the background and telling the user "the update is ready to be installed, proceed?". The users who tend not to be able to manually update a product is exactly the class of users that will say "if it aint broken, don't fix it". I think the case of the consumer router is a good one. We all have a box of these old routers. If our router, or a friends router breaks, we pull out a device and give it to them. Where we might update it before giving it, non-geeks will just hand it over. It worked two years ago, why would it not work now? The receiver will likely factory default it (because they and/or you forgot the password). Likely, at that moment they won't have an internet connection, because that's why they needed the router. It has just to work without updates. If this device now has an old root key and no automated way of updating it, your friend will not have a working internet connection, and the device is considered "broken". And there are many more scenarios. A more enterprise aimed product might require that you know the vendor login/password before you can download the upgrade. Paul From Ted.Lemon@nominum.com Fri Jan 28 11:32:45 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3D83A6962 for ; Fri, 28 Jan 2011 11:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJjaEghlTeKo for ; Fri, 28 Jan 2011 11:32:44 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id A93E73A695D for ; Fri, 28 Jan 2011 11:32:44 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTUMal6Qkh/efvoxafpj7wiWqiDbayM4n@postini.com; Fri, 28 Jan 2011 11:35:52 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7556E1B8314 for ; Fri, 28 Jan 2011 11:35:51 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 5246319005D; Fri, 28 Jan 2011 11:35:51 -0800 (PST) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 28 Jan 2011 11:35:50 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4D4310D6.7090007@cisco.com> Date: Fri, 28 Jan 2011 14:35:46 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <4118D421-D55D-46EF-8138-4470DAD7BB29@nominum.com> References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu> <4D430265.8020100@cisco.com> <4D4310D6.7090007@cisco.com> To: John Bashinski X-Mailer: Apple Mail (2.1082) Cc: Nicholas Weaver , dnsext List , george.barwood@plueyonder.co.uk Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 19:32:45 -0000 On Jan 28, 2011, at 1:54 PM, John Bashinski wrote: > I guess my answer is that enemies that powerful may indeed be out of > scope for default behavior. If you're worried about that, you may need > to do something out of band to validate your DNSSEC keys. The current > plan requires every product to enable you to do that, by the way. Your local ISP (or, indeed, the criminal with no arrest record who got a = job at your local ISP) is perfectly capable of setting this up. It's = not even difficult. From jbash@cisco.com Fri Jan 28 11:54:08 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C633A6975 for ; Fri, 28 Jan 2011 11:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzNu6yRqxUSk for ; Fri, 28 Jan 2011 11:54:06 -0800 (PST) Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id B19703A696E for ; Fri, 28 Jan 2011 11:54:06 -0800 (PST) Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id 0D6131A5319; Fri, 28 Jan 2011 14:57:10 -0500 (EST) Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id D5A216726; Fri, 28 Jan 2011 14:57:08 -0500 (EST) Message-ID: <4D431F94.4020701@cisco.com> Date: Fri, 28 Jan 2011 14:57:08 -0500 From: John Bashinski Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Hoffman References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42F597.8090006@vpnc.org> <4D42FCB6.70005@cisco.com> <4D43072D.6090503@vpnc.org> In-Reply-To: <4D43072D.6090503@vpnc.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC8ECF3732ACA28EB8D982353" Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 19:54:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC8ECF3732ACA28EB8D982353 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-01-28 13:13, Paul Hoffman wrote: >> I'm not sure I see how it does that. The new "moving part" isn't in >> the main trust path. It's off to the side, and it doesn't affect >> the basic system. It only affects devices that choose to validate >> by default and choose to bootstrap from old keys. >=20 > A moving part that is "off to the side" but becomes "quite central > when something goes wrong" is not really "off to the side". It goes > from unimportant to completely critical just like very other moving > part does. It doesn't become "quite central when something goes wrong". It's "quite central" when you want to validate by default without any operator intervention. It's not even part of the process if you maintain your anchors manually (as everybody does now). And it doesn't become any more central when anything goes wrong. It doesn't make any change in, say, how the system responds to key compromise, nor have I asked for any change in the key rollover schedule. All I've asked for is a history of rollovers, or something equivalent. If you want to have more assurance in your trust anchors, you can ALWAYS install them manually, or check their fingerprints manually, exactly as you would today. You can use whatever out of band methods you want. Nobody's suggested taking that away. In fact, I'm expecting to take heat for requiring some quite sophisticated trust anchor managment to be available in products where it'll almost never get used. The present draft requires: 1. User able to choose root keys (defaulting to whatever's learned from the system we're talking about now). 2. User able to override the root keys for any subzone: a. With a local anchor, or b. With DLV 3. User able to enable or disable RFC 5011 rollover for any anchor (on by default). 4. User able to choose trusted algorithms (although not presently per zone; maybe it should be). That's all meant to be required in your pocket camera as well as your backbone router. If there's something reasonable that I've missed, it can be added in. By the way, for further clarity, I'm not at present even asking devices to *support* updating any manually installed root key with this whole "historical key" thing, let alone to *force* it to to happen or even to do it by default. This is only for devices that are starting from scratch with no configuration. >> If you do want to think of that as a new moving part, then if you have= >> every vendor do it separately,what you've really done is to add N >> new moving parts instead of one. > > We fully disagree. Trust anchor loading (whether initial or while the > system is running) is *always* unique to every vendor and, quite > frankly, to every customer who actually cares about their trust > anchors. You may not think this because 99.99% of users of trust > anchor stores do this blindly, but many of Cisco's router customers > (and folks like them that the DNSSEC community care about) do care > about this. Um, it sort of sounds to me as though you've just defined "many" as "0.01 percent". But, in any case, all this stuff we're talking about is for the *default* behavior for devices that have no other DNSSEC information available. By definition, it only applies your 99.99 percent who have chosen not to take further control. They have delegated this matter to the defaults, basically saying "OK, Cisco or whoever, I trust you tell me, using this default key, what my DNSSEC root should be". I'm sure some of them would prefer to trust "Cisco". I'm also sure some of them would prefer to trust "whoever", if there were a good reason to assume that "whoever" was less likely to introduce a new risk than Cisco. It seems to me that the way that introduce the absolute *least* new risk is to trust only the public root keys, even the old ones. The second choice is to trust some new key managed by the same people under the same procedures as part of the same process. > Having each vendor "do this" with DNS security is exactly the same as > having each vendor "do this" with software security. =2E.. except that the software part is unavoidable, so the question doesn't arise. We create the software, and we're the only ones in a position to certify it. The DNS part is a *choice*. >> Actually, it's not quite the preloaded trust anchors we're talking >> about. It's the updated keys that get validated using those preloaded >> anchors. > > Those have identical security properties to the users. They have totally different temporal span, and temporal span is really the whole thing causing us heartburn in the first place. > If their vendor made it hard or impossible to get the latter when > needed, the users will (rightly, IMHO) blame the vendor for the users' > reduction in security. I guess that's true, but nobody's suggested that. >> From my point of view, some person or persons, inside or outside of >> Cisco, is going to have the ability to cause a new DNSSEC root key to >> get signed using that preloaded key. >> >> That person or persons is NOT going to be the same person or persons >> who generates the software loads. I'm adding a new trusted entity >> to the system. > > It could be / should be a person who is trusted within Cisco to the > same level as the person who generated the software loads. She doesn't > have to be the same person. Um. Let's suppose that I have two employees, A and B. I expect each of A and = B to behave properly with a probability of 99 percent (and thus expect each to behave improperly with a probability 1 percent). If I trust A with the ability to compromise my system, ignoring other factors, I have a probability of compromise of 1 percent. Same if I trust B. If I put trust in both A *and* B, such that either A *or* B can compromise me, my probability of compromise is now 1.99 percent. Very nearly doubled. I mean, assuming that A and B have independent probabilities of subversion, blah blah blah. You get the point. >> I think you're saying "well, let Cisco be trusted; it's trusted alread= y >> anyway". That's true if you look at Cisco as a monolith, but I don't >> have that luxury. Something has to be set up inside Cisco to deal with= >> handling these keys. > If you trusted Employee A to fetch the DNS root key at time X and > include it in the initial firmware loads, you can trust Employee A at > time Y to do it again for updates, Not at all. Things may change between time X and time Y. Maybe A wasn't mad at me at time X. Maybe A wasn't being bribed at time X. Maybe A wasn't having her family threatened at time X. Maybe A wasn't in an extreme phase of her undiagnosed and uncontrolled bipolar disorder at time X. Maybe A didn't happen to know how to patch the key in the software, but does know how to change the key in the update blob. All other things being equal, I'm much better off to trust A only once than to trust A twice. And I'm somewhat better off to trust N times than N+1 times, even for relatively large N. > or you can trust Employee B at time > Y if you would have trusted Employee B to do the firmware loads. No, that's a new risk, just as it would be if I trusted A at time Y. Actually, it's perhaps worse, because by implication B is now carrying out a process with which B is less experienced than, say, A might be, and B is more likely to make a mistake. I can mitigate all these risks by bringing in employees C, D, E, and F, and having lots of cross-checks and checklists and secret sharing and whatnot, very much the way that IANA does for the root key. Eventually, however, I'm going to have to explain to somebody why that router I sold them costs more than the competitor's box. So I'd better hope that person is among those of my customers who understand and care, and I'd better be able to show a genuine risk reduction over a simpler, cheaper system... like say trusting the people who already run the DNSSEC root to do something that they were going to be doing anyway. That may be kind of hard to do, since I haven't reduced trust in IANA or its system or its people very much, but I *have* added my system into the mix... and I'd better be able to explain how employees A, B, C, D, E, and F know they got the right root key from IANA... >> The complexity still exists; it's just been made >> less visible from a certain point of view. >=20 > Fully agree. >=20 >> So, the question is whether it's better to have a single, publicly >> visible process that may be able to break a very large number >> of devices, or a large number of hidden processes each of which >> can break a smaller number of devices. > That's one way to phrase it. Another would be "whether it's better to > have a single, publicly visible process that may be able to break a > very large number of devices and is more complicated than the > already-complicated process we have now, or a large number of hidden > processes that have the same local security properties we have now > where those hidden processes already can (and do!) break a smaller > number of devices". I still don't agree that any additional complexity is added for people who want to manage their own trust anchors. For people who *don't* want to manage their own trust anchors, there is *no* process now, so it can't get any more complicated. I also don't agree that those hidden processes have the same local security properties we have now. You've added complexity and trust to each and every one of them, over and above what exists for simply signing software. =2E.. which, by the way, is something most vendors, including Cisco, stil= l don't have universally deployed and still aren't entirely comfortable with. >> I tend to prefer the former. > Understood. From a security and deployment standpoint, the latter is > what we already have today, and it might be better to continue to do > it (and maybe even document it) than to make the current DNSSEC > infrastructure more fragile. =2E.. but nobody's suggesting that you have to change anything you're doing. This is completely optional default behavior, aimed at people who wouldn't even turn on DNSSEC at all if it weren't there. -- jbash --------------enigC8ECF3732ACA28EB8D982353 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DH5QACgkQQXYiJfd/JbYB9ACggCheOZpN4DoQ5o/dR4UHmF2V 1nYAni7RhZFgzXL19bzzJkPtXHLSNtio =ijiK -----END PGP SIGNATURE----- --------------enigC8ECF3732ACA28EB8D982353-- From paul@xelerance.com Fri Jan 28 12:27:28 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4289F3A6975 for ; Fri, 28 Jan 2011 12:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Bx-wlmdmbIW for ; Fri, 28 Jan 2011 12:27:27 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 74F483A6968 for ; Fri, 28 Jan 2011 12:27:27 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id B20C0BF8B; Fri, 28 Jan 2011 15:30:32 -0500 (EST) Date: Fri, 28 Jan 2011 15:30:32 -0500 (EST) From: Paul Wouters To: John Bashinski In-Reply-To: <4D431F94.4020701@cisco.com> Message-ID: References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42F597.8090006@vpnc.org> <4D42FCB6.70005@cisco.com> <4D43072D.6090503@vpnc.org> <4D431F94.4020701@cisco.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 20:27:28 -0000 On Fri, 28 Jan 2011, John Bashinski wrote: > 2. User able to override the root keys for any subzone: > > a. With a local anchor, or > b. With DLV Note that this can be complicated. If you have a private.example.com used internally only, then you have to "override" the DNSSEC signed data that would "proof" that private.example.com does not exist at the parent (used in the public view). unbound has supported this for a long time, and bind started suporting this only in 9.8.x. Be sure your validating stack can deal with this case. Paul From thierry.moreau@connotech.com Fri Jan 28 13:54:53 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA753A6975 for ; Fri, 28 Jan 2011 13:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.527 X-Spam-Level: X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[AWL=0.964, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIfXo6M4gds6 for ; Fri, 28 Jan 2011 13:54:53 -0800 (PST) Received: from bretelle.intaglionic.org (unknown [76.10.176.241]) by core3.amsl.com (Postfix) with ESMTP id E12473A68C8 for ; Fri, 28 Jan 2011 13:54:52 -0800 (PST) Received: from [192.168.1.200] (unknown [192.168.1.200]) by bretelle.intaglionic.org (Postfix) with ESMTPA id 1080D3076C; Fri, 28 Jan 2011 22:09:05 -0500 (EST) Message-ID: <4D433B9D.7030209@connotech.com> Date: Fri, 28 Jan 2011 16:56:45 -0500 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: John Bashinski References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42F597.8090006@vpnc.org> <4D42FCB6.70005@cisco.com> <4D43072D.6090503@vpnc.org> <4D431F94.4020701@cisco.com> In-Reply-To: <4D431F94.4020701@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 21:54:53 -0000 John Bashinski wrote: > > It's not even part of the process if you maintain > your anchors manually (as everybody does now). And it doesn't become any > more central when anything goes wrong. It doesn't make any change > in, say, how the system responds to key compromise, nor have I asked > for any change in the key rollover schedule. All I've asked for is > a history of rollovers, or something equivalent. > But once IANA (or whichever organization makes it "public") commits to "it" on a long term it becomes by definition more trustworthy than the root KSK. Then suddenly the trust foundation shifts from the root KSK to "it" and soon it becomes best practice to use it as the normal way to bootstrap DNSSEC resolution. At one point you reach the end of the world (the Earth is flat with respect to system-wide crypto key management). > If you want to have more assurance in your trust anchors, you can ALWAYS > install them manually, or check their fingerprints manually, exactly as > you would today. You can use whatever out of band methods you > want. Nobody's suggested taking that away. In fact, I'm expecting to > take heat for requiring some quite sophisticated trust anchor managment > to be available in products where it'll almost never get used. The > present draft requires: > > 1. User able to choose root keys (defaulting to whatever's learned > from the system we're talking about now). > Ah ah! Now "it" becomes the (default) new trust foundation. I knew it would come sooner than later. Have a good week-end and best regards, -- - Thierry Moreau From jbash@cisco.com Fri Jan 28 14:12:10 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007013A68BD for ; Fri, 28 Jan 2011 14:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COCdHPejOGmV for ; Fri, 28 Jan 2011 14:12:09 -0800 (PST) Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id 08B023A689E for ; Fri, 28 Jan 2011 14:12:09 -0800 (PST) Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id AF9541A5319; Fri, 28 Jan 2011 17:15:12 -0500 (EST) Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id A86C53061; Fri, 28 Jan 2011 17:15:11 -0500 (EST) Message-ID: <4D433FEF.9060406@cisco.com> Date: Fri, 28 Jan 2011 17:15:11 -0500 From: John Bashinski Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Thierry Moreau References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42F597.8090006@vpnc.org> <4D42FCB6.70005@cisco.com> <4D43072D.6090503@vpnc.org> <4D431F94.4020701@cisco.com> <4D433B9D.7030209@connotech.com> In-Reply-To: <4D433B9D.7030209@connotech.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAFFEE6D10ED492269F3CE62D" Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 22:12:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAFFEE6D10ED492269F3CE62D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-01-28 16:56, Thierry Moreau wrote: > But once IANA (or whichever organization makes it "public") commits to > "it" on a long term it becomes by definition more trustworthy than the > root KSK. How does that work? All validations are funneled through through the root KSK. Furthermore, once you're bootstrapped, all your trust anchor updates come as RFC 5011 signed by the root KSK. So there's no way to have anything more trusted than the root KSK. This is in the technical sense of "trusted", which is more or less equivalent to "able to spoil your day". The originally proposed form of "it" was for "it" to *be* the root KSK. You'd start with a root KSK, and if that KSK were still in use, you'd be done. If not, you'd get "it" in the form of a history of root KSK rollovers, run through the chain, and thereafter anchor yourself at the current root KSK. I still prefer that approach, but other people seem to prefer alternatives. Not even those the alternatives create anything that I can see as "more trusted" than the root. "Equally trusted" at most. > Then suddenly the trust foundation shifts from the root KSK > to "it" and soon it becomes best practice to use it as the normal way > to bootstrap DNSSEC resolution. Well, it certainly wouldn't be the only available way, but, yes, it probably would be the most common way. What do you believe should be the "normal way"? > Ah ah! Now "it" becomes the (default) new trust foundation. I knew it > would come sooner than later. In order to enable DNSSEC by default, it MUST be possible to bootstrap it without human intervention, using only the information available to you when you first get turned on. That's what "default" means. The current default is not to use DNSSEC at all. A tiny minority enables DNSSEC. That tiny minority would still be able to do whatever it wanted to set up trust anchors... including what it's doing today. So what's the alternative? -- jbash --------------enigAFFEE6D10ED492269F3CE62D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DP+8ACgkQQXYiJfd/JbakQwCfcdLhHQN88nfd5BomrrabdvpM tGkAoIGsX6CCxa3sQxYNE5eBDNIculfW =ikK/ -----END PGP SIGNATURE----- --------------enigAFFEE6D10ED492269F3CE62D-- From hallam@gmail.com Fri Jan 28 17:19:13 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCF23A6975 for ; Fri, 28 Jan 2011 17:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMk4dOW6wyPT for ; Fri, 28 Jan 2011 17:19:12 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 4A7F53A68F3 for ; Fri, 28 Jan 2011 17:19:12 -0800 (PST) Received: by gxk27 with SMTP id 27so1493698gxk.31 for ; Fri, 28 Jan 2011 17:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m3Z4VAjUuAjDI/+79+4krDjk4lcj/AxkPhv6BzudoeI=; b=Sl4MhPmfu4QpQuSKf+ca++7mmUQqRHX0kePg7DsRc/MhTy+EcnaP1L9AseptyJRALc QMIHbQU5hzhTigBxS89UGnY/7q8XOBho1OMf0jdRHVANtAWIcFh7skjZfB/q8iuUeFPx 5+kDc7dZiBxl80QfMfXqQQV1+3OqSp8SqortU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lSvD9Es0CF9VtzuhaDsn+VeRiPpejHKkzP9ZkVUo4caWPk2LXQ8+WCBSDjb5yZidrQ AE2teRMIIAM/y4W2DmiIRnoLhAPRnyM7Bnge0Q+ZC86/co+KY83nZsds7ZC+yg9xPqMH FAciQmbUych4AUfWHYHMCAEbqaAGB9DejQmGg= MIME-Version: 1.0 Received: by 10.100.34.1 with SMTP id h1mr2097915anh.188.1296264139322; Fri, 28 Jan 2011 17:22:19 -0800 (PST) Received: by 10.100.109.16 with HTTP; Fri, 28 Jan 2011 17:22:19 -0800 (PST) In-Reply-To: <20110128163656.GC30257@shinkuro.com> References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <20110128163656.GC30257@shinkuro.com> Date: Fri, 28 Jan 2011 20:22:19 -0500 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=0016e64652208f362f049af203a9 Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jan 2011 01:19:13 -0000 --0016e64652208f362f049af203a9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 28, 2011 at 11:36 AM, Andrew Sullivan wrote: > > That amounts to a requirement that someone guarantee a key is not > compromised. Nobody can promise that. This is why I am sceptical of > claims that some mechanism other than DNSSEC keys is the right way to > do this. If you plan to roll the root KSK on a regular basis, you are going to create a requirement to allow dependent applications to validate the current root. You can deal with this issue without change to the DNSSEC specs of working assumptions by committing to operate all KSKs for an extended period (20 years would be appropriate). In this model there might be an additional root introduced every 5 years or so and there would thus be up to 4 roots in operation simultaneously. You can also deal with the issue by stating that the root KSK will never roll. That is almost certainly what will happen in practice, but not committing to do so means that people cannot plan. Beyond that, I do not like the idea of a chain of historical roots. It means that compromise of any root will poison the ones downstream. There are five potential points of compromise in the following chain: A -> B, B->C, C->D, D->E This approach only ever has two at any given time: A->B, A->C, A->D, A->E A better approach is to have multiple signers and require multiple signatures for the root KSK: X1->A, X2->A, X3->A [Quorum = 2] In this scheme none of the signers has the ability to perform either a fraudulent signature or a denial of service attack without collusion with another signer. I don't think that it makes any sense to try to express such semantics in DNSSEC because the issues raised are not unique to DNSSEC. The hypothetical NAT box with DNSSEC support would be expected to also require: * Code signing to protect the integrity of firmware * Device authentication via 802.1X or similar * HTTP based configuration interface with TLS So this is not a problem that I see value in extending DNSSEC to serve since the same problems are raised in the other three cases, and those will affect every device sold, not just ones with DNS recursive resolvers. -- Website: http://hallambaker.com/ --0016e64652208f362f049af203a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 28, 2011 at 11:36 AM, Andrew= Sullivan <ajs@shi= nkuro.com> wrote:
That amounts to a requirement that someone guarantee a key is not
compromised. =A0Nobody can promise that. =A0This is why I am sceptical of claims that some mechanism other than DNSSEC keys is the right way to
do this.

If you plan to roll the root KSK = on a regular basis, you are going to create a requirement to allow dependen= t applications to validate the current root.

You can deal with this issue without change to the DNSSEC specs of working = assumptions by committing to operate all KSKs for an extended period (20 ye= ars would be appropriate). In this model there might be an additional root = introduced every 5 years or so and there would thus be up to 4 roots in ope= ration simultaneously.

You can also deal with the issue by stating that the ro= ot KSK will never roll. That is almost certainly what will happen in practi= ce, but not committing to do so means that people cannot plan.


Beyond that, I do not like the idea of a chai= n of historical roots. It means that compromise of any root will poison the= ones downstream. There are five potential points of compromise in the foll= owing chain:

A -> B, B->C, C->D, D->E

This approach only ever has two at any given time:

A->B, A->C, A->D, A->E


A better approach is to have multiple signers and require multip= le signatures for the root KSK:

X1->A, X2->A= , X3->A =A0[Quorum =3D 2]

In this scheme none o= f the signers has the ability to perform either a fraudulent signature or a= denial of service attack without collusion with another signer.


I don't think that it makes any sens= e to try to express such semantics in DNSSEC because the issues raised are = not unique to DNSSEC. The hypothetical NAT box with DNSSEC support would be= expected to also require:

* Code signing to protect the integrity of firmware
* Device authentication via 802.1X or similar
* HTTP based= configuration interface with TLS

So this is not a= problem that I see value in extending DNSSEC to serve since the same probl= ems are raised in the other three cases, and those will affect every device= sold, not just ones with DNS recursive resolvers.


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

--0016e64652208f362f049af203a9-- From paul@xelerance.com Fri Jan 28 18:47:27 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0892D3A6A90 for ; Fri, 28 Jan 2011 18:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR7cukBMOkDe for ; Fri, 28 Jan 2011 18:47:26 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 0D59C3A6A7E for ; Fri, 28 Jan 2011 18:47:26 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 3E4CDBF8B for ; Fri, 28 Jan 2011 21:50:32 -0500 (EST) Date: Fri, 28 Jan 2011 21:50:31 -0500 (EST) From: Paul Wouters To: dnsext@ietf.org In-Reply-To: Message-ID: References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <20110128163656.GC30257@shinkuro.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jan 2011 02:47:27 -0000 On Fri, 28 Jan 2011, Phillip Hallam-Baker wrote: > Beyond that, I do not like the idea of a chain of historical roots. It means that compromise of any root will poison the ones downstream. There are five > potential points of compromise in the following chain: > > A -> B, B->C, C->D, D->E > > This approach only ever has two at any given time: > > A->B, A->C, A->D, A->E But that requires the key move somewhere trusted so it can make a NEW signature for the A->C transition, after A has been retired for B. Or rather, when you deploy E, you have 5 root keys to protect instead of one. Unless you pregenerate all 5 root keys in advance (but then what to do for the sixth role and further) Wouter's draft has no such requirement - in fact the old private root key could be destroyed, which seems a much safer approach, then requiring ALL old private keys for 20 years. Paul From thierry.moreau@connotech.com Fri Jan 28 18:54:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD65C3A6A91 for ; Fri, 28 Jan 2011 18:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.366 X-Spam-Level: X-Spam-Status: No, score=0.366 tagged_above=-999 required=5 tests=[AWL=0.803, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMDoGPHuMr+h for ; Fri, 28 Jan 2011 18:54:01 -0800 (PST) Received: from bretelle.intaglionic.org (unknown [76.10.176.241]) by core3.amsl.com (Postfix) with ESMTP id 76A653A6A83 for ; Fri, 28 Jan 2011 18:54:01 -0800 (PST) Received: from [192.168.1.200] (unknown [192.168.1.200]) by bretelle.intaglionic.org (Postfix) with ESMTPA id 361993077D; Sat, 29 Jan 2011 03:08:13 -0500 (EST) Message-ID: <4D4381BB.9070407@connotech.com> Date: Fri, 28 Jan 2011 21:55:55 -0500 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: John Bashinski References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42F597.8090006@vpnc.org> <4D42FCB6.70005@cisco.com> <4D43072D.6090503@vpnc.org> <4D431F94.4020701@cisco.com> <4D433B9D.7030209@connotech.com> <4D433FEF.9060406@cisco.com> In-Reply-To: <4D433FEF.9060406@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jan 2011 02:54:03 -0000 Dear John, Some definitions and background about trust and "liability" in the context of root public keys (DNSSEC root KSK, open PKI root CA -- in the original model --, and to a lesser extent a private CA like Cisco's for software revisions). An organization stands behind a root public key because it controls the private key counterpart. The organization announces for which purposes the key pair is issued, along with some cryptoperiod expectation. Relying parties depend on the organization internal controls of the private key. Some factors make the organization's responsibilities more demanding: the value of surreptitious access to the private key, the expected computing power increase in the hands of "the enemy," the wear and tear of continuous internal controls, and, indirectly, the size of the relying party population. The cryptoperiod announcement says: after such a date, don't expect our internal controls to be at par with the cumulative risk exposure. It also says "a digital signature verification is meaningless after the end of the cryptperiod." More precisely, it says "don't blame us if a bogus digital signature floats around after the end of the cryptoperiod, we would have told you that the key was expired." What you are asking for is a long cryptoperiod, either because the history record relied upon in 2035 uses a KSK expired in 2021, or because a special-purpose signature key relied upon in 2035 has entered IANA internal controls before 2014, the manufacturing date for Cisco boxes. I am sure IANA does not wish to let "the world" to so rely on a long expired KSK without having been served this little warning "no good after KSK rollover which we will announce in advance." I write this from discussions surrounding the KSK internal controls, a time during which I was advocating a longer term commitment (with slightly different procedures) from IANA. IANA did an excellent job at this project for which there was no precedent, at least with an equivalent level of transparency. Their stubbornness (?) in making this little warning is an indication that their KSK operations are trustworthy *before* rollover. For the long-term commitment from IANA for (the internal controls required for) a special purpose signature key, I am less certain. But if they do make this commitment, then WOW! "The world" would have what you are looking for. Bootstrap from this super-WOW signature key whenever you feel you need more confidence in your DNS resolution. - You say *only*if* the current local KSK configuration is outdated. I would say it's up to any gear vendor, any security officer, or any sys admin, in any circumstances. - You say it's no better than the KSK, while in fact it is: it works across KSK rollovers. Suppose your unit goes back on-line in 2035 and sees the same KSK as was current in 2014, because a bogus root is being operated by a hacker in the network nearby. The super-WOW signature verification will prevent the bogus root attack. It's about the IANA embarrassment if something goes wrong. Semantically it does not turn into "liability" but that is just because secure electronic payments are not directly secured by DNSSEC validated RRsets near the top of the DNS hierarchy. I exposed the suggested course of action for Cisco in the first e-mail to you (it was off-list). It is a simple selection from what you already identified as operationally acceptable options. I hope it clarifies the link between long term public key crypto material and "trust" as the term applies to your problem statement (which I find very good). Hope it helps (I wish to abstain from further contributions to the IETF list on this issue). Regards, -- - Thierry Moreau John Bashinski wrote: > On 2011-01-28 16:56, Thierry Moreau wrote: > >> But once IANA (or whichever organization makes it "public") commits to >> "it" on a long term it becomes by definition more trustworthy than the >> root KSK. > > How does that work? All validations are funneled through through the > root KSK. Furthermore, once you're bootstrapped, all your trust anchor > updates come as RFC 5011 signed by the root KSK. So there's no way to > have anything more trusted than the root KSK. This is in the technical > sense of "trusted", which is more or less equivalent to "able to spoil > your day". > > The originally proposed form of "it" was for "it" to *be* the root > KSK. You'd start with a root KSK, and if that KSK were still in use, > you'd be done. If not, you'd get "it" in the form of a history of root > KSK rollovers, run through the chain, and thereafter anchor yourself at > the current root KSK. > > I still prefer that approach, but other people seem to prefer > alternatives. Not even those the alternatives create anything that I can > see as "more trusted" than the root. "Equally trusted" at most. > >> Then suddenly the trust foundation shifts from the root KSK >> to "it" and soon it becomes best practice to use it as the normal way >> to bootstrap DNSSEC resolution. > > Well, it certainly wouldn't be the only available way, but, yes, it > probably would be the most common way. > > What do you believe should be the "normal way"? > >> Ah ah! Now "it" becomes the (default) new trust foundation. I knew it >> would come sooner than later. > > In order to enable DNSSEC by default, it MUST be possible to bootstrap > it without human intervention, using only the information available to > you when you first get turned on. That's what "default" means. > > The current default is not to use DNSSEC at all. A tiny minority > enables DNSSEC. That tiny minority would still be able to do whatever > it wanted to set up trust anchors... including what it's doing today. > > So what's the alternative? > > -- jbash > From paul@xelerance.com Fri Jan 28 19:10:56 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770D83A6ADE for ; Fri, 28 Jan 2011 19:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iActFXo6J2I1 for ; Fri, 28 Jan 2011 19:10:53 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 2836F3A6ADB for ; Fri, 28 Jan 2011 19:10:52 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 6A16CC542 for ; Fri, 28 Jan 2011 22:13:59 -0500 (EST) Date: Fri, 28 Jan 2011 22:13:59 -0500 (EST) From: Paul Wouters To: dnsext@ietf.org In-Reply-To: Message-ID: References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <20110128163656.GC30257@shinkuro.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jan 2011 03:10:56 -0000 On Fri, 28 Jan 2011, Paul Wouters wrote: > On Fri, 28 Jan 2011, Phillip Hallam-Baker wrote: > >> Beyond that, I do not like the idea of a chain of historical roots. It >> means that compromise of any root will poison the ones downstream. There >> are five >> potential points of compromise in the following chain: >> >> A -> B, B->C, C->D, D->E >> >> This approach only ever has two at any given time: >> >> A->B, A->C, A->D, A->E > > But that requires the key move somewhere trusted so it can make a NEW > signature for the A->C transition, after A has been retired for B. Or > rather, when you deploy E, you have 5 root keys to protect instead of Oops, as Phillip said, it is only two. I misunderstood. But it still requires two private root keys to be available, instead of one. Paul From hallam@gmail.com Sat Jan 29 08:40:19 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996193A6833 for ; Sat, 29 Jan 2011 08:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+V8JEJPmD4V for ; Sat, 29 Jan 2011 08:40:18 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 187F23A6823 for ; Sat, 29 Jan 2011 08:40:18 -0800 (PST) Received: by yxt33 with SMTP id 33so1661700yxt.31 for ; Sat, 29 Jan 2011 08:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WqD8ug/lDjJgMbB3F5nIC3G67EG6rs4SXhL2yX41LrQ=; b=c2gU9Z+O6ahc1vYM1l6N5TAaNmKeJ28jy5HJu330dyeXcA0a2NYUBBeblIPPeOtYce enYNZswxe4ZH0YG2BQYp+U2Urfp7Gt1yIpWEXkyUwRua+WbFkPKrfcKOp6j2xu8jQcFC HdLVk0f+cpGjxcV9ocbBMmI3mI+nqWmujT9FM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gt9LAbUFI7unTBs+/QF/RaLDTjmvNR3dsQUxbOZKiQZfJ5Rt7ZxhAGH/mHZW1tjVVA vMS8AHdwAGppb8av/gbJharQML+7d6KfghfnBhLoiX0NzOd4d9AZqo/J4VkIB3x1Sikz Uln1epYvmSvwvCCkdXGrFgYpq+LqhKYopuqWY= MIME-Version: 1.0 Received: by 10.100.8.9 with SMTP id 9mr2571372anh.120.1296319406263; Sat, 29 Jan 2011 08:43:26 -0800 (PST) Received: by 10.100.109.16 with HTTP; Sat, 29 Jan 2011 08:43:26 -0800 (PST) In-Reply-To: References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <20110128163656.GC30257@shinkuro.com> Date: Sat, 29 Jan 2011 11:43:26 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e6441dd8b9ce3b049afee1b4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jan 2011 16:40:19 -0000 --0016e6441dd8b9ce3b049afee1b4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 28, 2011 at 9:50 PM, Paul Wouters wrote: > On Fri, 28 Jan 2011, Phillip Hallam-Baker wrote: > > Beyond that, I do not like the idea of a chain of historical roots. It >> means that compromise of any root will poison the ones downstream. There are >> five >> potential points of compromise in the following chain: >> >> A -> B, B->C, C->D, D->E >> >> This approach only ever has two at any given time: >> >> A->B, A->C, A->D, A->E >> > > But that requires the key move somewhere trusted so it can make a NEW > signature for the A->C transition, after A has been retired for B. Or > rather, when you deploy E, you have 5 root keys to protect instead of > one. Unless you pregenerate all 5 root keys in advance (but then what > to do for the sixth role and further) > > Wouter's draft has no such requirement - in fact the old private root > key could be destroyed, which seems a much safer approach, then requiring > ALL old private keys for 20 years. Neither would cause me the slightest concern in the context of offline root key management. HSMs used for this type of application are capable of storing hundreds of private keys. For an application like DNSSEC the HSMs should be used for DNSSEC and no other purpose whatsoever. Offline root key management bears very little relationship to management of application keys. EVERY risk that has been identified should already be highly improbable. The cumulative probability of any risk being realized should be negligible (much less than 1%). I think we need to start with a set of requirements and at the very least involve people with first hand experience of the ICANN root key management processes. The video suggests that there was something like thirty people in the room when the keys were generated so they can hardly be trade secrets. This issue was clearly understood at the time that the ICANN processes were developed and it looks to me like the decision to not support a long term validation root was quite deliberate, though the reasons for making that choice are not. Regardless of the reasons for the decision, it should be obvious that lack of a technical proposal was not one of them. So before discussing a technical proposal, I suggest we gather some information. The ICANN people will be at RSA next month, so will Cisco people who have responsibility for crypto and many others who might have relevant ideas or experience. If this is really an issue we should have a meeting and discuss the full set of requirements and the issues involved. -- Website: http://hallambaker.com/ --0016e6441dd8b9ce3b049afee1b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 28, 2011 at 9:50 PM, Paul Wo= uters <paul@xele= rance.com> wrote:
On Fri, 28 Jan 2011, Phillip Hallam-Baker wrote:

Beyond that, I do not like the idea of a chain of historical roots. It mean= s that compromise of any root will poison the ones downstream. There are fi= ve
potential points of compromise in the following chain:

A -> B, B->C, C->D, D->E

This approach only ever has two at any given time:

A->B, A->C, A->D, A->E

But that requires the key move somewhere trusted so it can make a NEW
signature for the A->C transition, after A has been retired for B. Or rather, when you deploy E, you have 5 root keys to protect instead of
one. Unless you pregenerate all 5 root keys in advance (but then what
to do for the sixth role and further)

Wouter's draft has no such requirement - in fact the old private root key could be destroyed, which seems a much safer approach, then requiring ALL old private keys for 20 years.

Neither = would cause me the slightest concern in the context of offline root key man= agement.

HSMs used for this type of application ar= e capable of storing hundreds of private keys. For an application like DNSS= EC the HSMs should be used for DNSSEC and no other purpose whatsoever.


Offline root key management bears very l= ittle relationship to management of application keys.

<= div>EVERY risk that has been identified should already be highly improbable= . The cumulative probability of any risk being realized should be negligibl= e (much less than 1%).


I think we need to start with a set of r= equirements and at the very least involve people with first hand experience= of the ICANN root key management processes. The video suggests that there = was something like thirty people in the room when the keys were generated s= o they can hardly be trade secrets.


This issue was clearly understood at the= time that the ICANN processes were developed and it looks to me like the d= ecision to not support a long term validation root was quite deliberate, th= ough the reasons for making that choice are not.

Regardless of the reasons for the decision, it should b= e obvious that lack of a technical proposal was not one of them.
=
So before discussing a technical proposal, I suggest we gath= er some information. The ICANN people will be at RSA next month, so will Ci= sco people who have responsibility for crypto and many others who might hav= e relevant ideas or experience.

If this is really an issue we should have a meeting and= discuss the full set of requirements and the issues involved.

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

--0016e6441dd8b9ce3b049afee1b4-- From fanf2@hermes.cam.ac.uk Sun Jan 30 11:34:01 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97BFF3A6853 for ; Sun, 30 Jan 2011 11:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIeFUd4i0pmH for ; Sun, 30 Jan 2011 11:34:00 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id 60B423A6849 for ; Sun, 30 Jan 2011 11:33:58 -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 [87.115.151.106] (port=54135 helo=[192.168.0.5]) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1Pjd5A-0007y1-QC (Exim 4.72) (return-path ); Sun, 30 Jan 2011 19:37:08 +0000 References: <4D3F233C.7000900@vpnc.org> <10A3D861-EC02-49FF-BBD1-44843378C9CB@icsi.berkeley.edu> <82r5bymfdw.fsf@mid.bfk.de> <49385.1296154316@nsa.vix.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Tony Finch Date: Sun, 30 Jan 2011 19:36:16 +0000 To: Phillip Hallam-Baker Sender: Tony Finch Cc: "dnsext@ietf.org" Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 30 Jan 2011 19:34:01 -0000 On 27 Jan 2011, at 20:34, Phillip Hallam-Baker wrote: >=20 > If the root KSK is compromised the consequences will be exhausted long bef= ore the scheduled rollover occurs. People would be required to get on planes= and roll a new root. If they implemented RFC 5011 properly there would be a pre-published standby= KSK. Also remember that loss is more likely than compromise. Tony. -- f.anthony.n.finch http://dotat.at/= From fanf2@hermes.cam.ac.uk Sun Jan 30 11:43:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166523A684C for ; Sun, 30 Jan 2011 11:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMBR+oJFim3E for ; Sun, 30 Jan 2011 11:43:36 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id 092BC3A6814 for ; Sun, 30 Jan 2011 11:43:36 -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 [87.115.151.106] (port=54138 helo=[192.168.0.5]) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1PjdET-0001ly-S2 (Exim 4.72) (return-path ); Sun, 30 Jan 2011 19:46:45 +0000 References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> In-Reply-To: <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> X-Mailer: iPhone Mail (8C148) From: Tony Finch Date: Sun, 30 Jan 2011 19:45:52 +0000 To: David Conrad Sender: Tony Finch Cc: dnsext List Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 30 Jan 2011 19:43:37 -0000 On 28 Jan 2011, at 06:06, David Conrad wrote: >=20 > I don't think that's a risk. If a key is rolled because of a known comprom= ise, it simply means you can't safely chain from the old-but-installed-key t= o the current-but-not-yet-installed key. Presumably, when a key is known to= be compromised, the chain from old to current keys would be broken such tha= t automated systems would require human intervention. If you implement RFC5011 you can maintain a chain of trust in the face of N-= 1 key compromises where N is the number of keys in the trust anchor. Tony. -- f.anthony.n.finch http://dotat.at/= From jabley@hopcount.ca Sun Jan 30 11:47:25 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E463A67D1 for ; Sun, 30 Jan 2011 11:47:25 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b57E3J7S2Rxj for ; Sun, 30 Jan 2011 11:47:24 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 6E7E83A67DA for ; Sun, 30 Jan 2011 11:47:24 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PjdMH-000FRD-Oz; Sun, 30 Jan 2011 19:54:51 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> Date: Sun, 30 Jan 2011 14:50:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> To: Tony Finch X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext List Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 30 Jan 2011 19:47:25 -0000 On 2011-01-30, at 14:45, Tony Finch wrote: > On 28 Jan 2011, at 06:06, David Conrad wrote: >>=20 >=20 >> I don't think that's a risk. If a key is rolled because of a known = compromise, it simply means you can't safely chain from the = old-but-installed-key to the current-but-not-yet-installed key. = Presumably, when a key is known to be compromised, the chain from old to = current keys would be broken such that automated systems would require = human intervention. >=20 > If you implement RFC5011 you can maintain a chain of trust in the face = of N-1 key compromises where N is the number of keys in the trust = anchor. I thought this whole thread was about how to handle an initial = bootstrap, e.g. in a new device, in a device that has been off-line for = longer than the 5011 key introduction period, or in the event that an = emergency key roll results in a change in KSK without 5011 timing or = publishing semantics. Joe= From paul.hoffman@vpnc.org Sun Jan 30 13:53:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE263A6872 for ; Sun, 30 Jan 2011 13:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.753 X-Spam-Level: X-Spam-Status: No, score=-101.753 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URTjD0K-Yokr for ; Sun, 30 Jan 2011 13:53:23 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9AE523A6B33 for ; Sun, 30 Jan 2011 13:53:23 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0ULuZak029023 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 30 Jan 2011 14:56:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D45DE93.9090508@vpnc.org> Date: Sun, 30 Jan 2011 13:56:35 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> In-Reply-To: <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 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, 30 Jan 2011 21:53:24 -0000 On 1/30/11 11:50 AM, Joe Abley wrote: > > On 2011-01-30, at 14:45, Tony Finch wrote: > >> On 28 Jan 2011, at 06:06, David Conrad wrote: >>> >> >>> I don't think that's a risk. If a key is rolled because of a known compromise, it simply means you can't safely chain from the old-but-installed-key to the current-but-not-yet-installed key. Presumably, when a key is known to be compromised, the chain from old to current keys would be broken such that automated systems would require human intervention. >> >> If you implement RFC5011 you can maintain a chain of trust in the face of N-1 key compromises where N is the number of keys in the trust anchor. > > I thought this whole thread was about how to handle an initial bootstrap, e.g. in a new device, in a device that has been off-line for longer than the 5011 key introduction period, or in the event that an emergency key roll results in a change in KSK without 5011 timing or publishing semantics. Joe is correct. From brian.peter.dickson@gmail.com Sun Jan 30 21:17:59 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E648F3A6B77 for ; Sun, 30 Jan 2011 21:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUtlx6vR0T1H for ; Sun, 30 Jan 2011 21:17:58 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 46B8E3A6B0E for ; Sun, 30 Jan 2011 21:17:58 -0800 (PST) Received: by fxm9 with SMTP id 9so5715986fxm.31 for ; Sun, 30 Jan 2011 21:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7dPQV0Li9ODyq68t1SWVJAZsvDOuBzK4aDjOG5/t5EY=; b=xUbMH0O1Fl5Af48OBKwM5HSwoPPtB0FmNnehN4tHL/MmNuRytlP9krewCFuNj01BMg xAD+4N43gGBcnhXBUF7TomGBDViaBubr+ZYOc2tPXvs/yxmG1s0QU+gOZ/rOcmbfY1fq GLx5JPoDHxQxr6WS5BEsdggxUxO3D5wVcKCEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XXIb+g1j8YV50jZUM66ZNyGLv3oLMxsdBSMN9+U8I0Cx6UFhTXYytTS+UGmcOl+3/N XmGln/TyeK62pqlfqeIo2+SYfD4v0cHpB+UfDxLVk2G1XKZB3912tGXFmp+eQFGYish5 4lgmkp9XEXa0i96ZAz5q75EdyfK8H82vuW1uw= MIME-Version: 1.0 Received: by 10.223.86.12 with SMTP id q12mr4993949fal.18.1296451270849; Sun, 30 Jan 2011 21:21:10 -0800 (PST) Received: by 10.223.108.71 with HTTP; Sun, 30 Jan 2011 21:21:10 -0800 (PST) In-Reply-To: <4D45DE93.9090508@vpnc.org> References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> Date: Mon, 31 Jan 2011 01:21:10 -0400 Message-ID: From: Brian Dickson To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 05:18:00 -0000 On Sun, Jan 30, 2011 at 5:56 PM, Paul Hoffman wrote= : > On 1/30/11 11:50 AM, Joe Abley wrote: >> >> On 2011-01-30, at 14:45, Tony Finch wrote: >> >>> On 28 Jan 2011, at 06:06, David Conrad =A0wrote: >>>> >>> >>>> I don't think that's a risk. If a key is rolled because of a known >>>> compromise, it simply means you can't safely chain from the >>>> old-but-installed-key to the current-but-not-yet-installed key. =A0Pre= sumably, >>>> when a key is known to be compromised, the chain from old to current k= eys >>>> would be broken such that automated systems would require human >>>> intervention. >>> >>> If you implement RFC5011 you can maintain a chain of trust in the face = of >>> N-1 key compromises where N is the number of keys in the trust anchor. >> >> I thought this whole thread was about how to handle an initial bootstrap= , >> e.g. in a new device, in a device that has been off-line for longer than= the >> 5011 key introduction period, or in the event that an emergency key roll >> results in a change in KSK without 5011 timing or publishing semantics. > > Joe is correct. Yes, but.... I think that there are two different considerations (at least): - whatever bootstrap mechanism gets used, should be at least as secure as 5011(of the current root or one of its predecessors) and/or as secure as the current root - if we presume the device will also ship with the current root key and attempt to authenticate it, or failing that to 5011 it, in the latter case there may be risks (known) A bootstrap mechanism that uses only one trust anchor, will necessarily fall in to two categories: - the bootstrap anchor is the current root (public) key - the bootstrap anchor is some other key We don't know ahead of time, who might be interested in compromising either kind of key, or why, or what resources they might have. However, we should not assume that only one group or person has (or will have) such intentions. If one group is interested in compromising the root key, and they succeed, *and* the current root key is used for the bootstrap process, then the bootstrap process will be compromised as a side-effect, i.e. be collateral damage. This is not good. If a group is interested in compromising the bootstrap process, and the bootstrap process does not rely exclusively on the current root key, then those efforts would not have a side-effect of compromising the root key. This is a good thing. >From that perspective alone, there are distinct benefits to not *exclusively* relying on the current root key for the bootstrap process. HOWEVER, and this is important, requiring TWO trust anchors of equal strength (same algorithm, same number of bits) to BOTH chain-validate the current root key properly as part of the bootstrap, where one of those is a previous root key, has some distinct advantages: - two keys (at least) would need to be compromised to compromise the target - the possible compromise of a root key, followed by rolling the key, means that the risk from following 5011 with that key, is only a problem if the other bootstrap key is also compromised - the value of compromising just the other bootstrap key is nearly zero, since that is necessary but not sufficient to compromise the target - thus limiting the value of this effort dramatically ----> having one trust anchor only (which is not based on the root key) does NOT have this benefit - minimizing the window of opportunity for attack (a one-time-only affair) further limits the value, and consequently lowers the likelihood of even an attempt being made Because of things like Moore's law, it will make sense over time, to not only roll keys, but algorithms too - and probably both at once (i.e. new key using new alg). The periodicity of this can reasonably be expected to linear, e.g. every N years, without increasing the likelihood of brute force attacks succeeding. By chaining both bootstrap methods, one using the current root key, and one using a separate key, means old devices will always be *able* to successfully bootstrap, while each new generation of gear will get the next pair of keys in the respective chains. This means the pool of potential targets at the generation-mark will be finite, decreasing monotonically, and likely be a curve with a fat beginning and very skinny tail. While the value of breaking the current root key may be obvious, the rolling of the key renders work towards that goal moot. The extra cost, extremely small window, and ever-shrinking pool of targets, makes breaking both of an old key pair nearly pointless, and doesn't present a significant risk to old gear. In diagram form, there would be two chained keysets: R1->R2->R3... (root keys) B1->B2->B3... (bootstrap keys) Both would be of equal type (algorithm, size) and rolled on similar periods (probably). When gear is built, it is configured with Rn and Bm (for current n and m, i.e. latest versions). The current root key Rc is retrieved and validated using 5011-type logic from Rn, and further validated using the latest signature Bc (which is itself retrieved using 5011-type logic from Bm). Only if all checks succeed, is Rc installed. Rn is never installed, but only ever used for the one-time validation of Rc. IMHO, the incremental cost of maintaining a second chain of keys is small, especially if they are managed by the same group, and using HSMs as is currently the case. But, I'll let those who maintain this speak for themselves, ditto the potential clients. And, of course, this is all for unmanaged, fire-and-forget usage. It isn't meant to replace best practices, but rather to limit the damage if best practices are not followed (or are unable to be comprehended). Brian From fanf2@hermes.cam.ac.uk Mon Jan 31 02:38:12 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE203A68F9 for ; Mon, 31 Jan 2011 02:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icK9d7t3hlYF for ; Mon, 31 Jan 2011 02:38:11 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id 6B8CB3A68F6 for ; Mon, 31 Jan 2011 02:38:11 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35371) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1PjrCD-0003I3-RA (Exim 4.72) (return-path ); Mon, 31 Jan 2011 10:41:21 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PjrCD-0001E3-D6 (Exim 4.67) (return-path ); Mon, 31 Jan 2011 10:41:21 +0000 Date: Mon, 31 Jan 2011 10:41:21 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Joe Abley In-Reply-To: <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> Message-ID: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> 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 List Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 10:38:12 -0000 On Sun, 30 Jan 2011, Joe Abley wrote: > > I thought this whole thread was about how to handle an initial > bootstrap, e.g. in a new device, in a device that has been off-line for > longer than the 5011 key introduction period, or in the event that an > emergency key roll results in a change in KSK without 5011 timing or > publishing semantics. Yes, but the bootstrap problem is made much worse by the current way the root zone uses RFC 5011 (assuming that it does in fact use RFC 5011). In particular if you go for a very long key introduction period then you avoid most of the horrific problems that occur for software distributed just before a rollover, and many emergency key rollovers should be non-events. RFC 5011 is designed so that you can publish your next key now, though it won't be deployed until 2014. In the event of loss or compromise of the active key, you can rollover to the standby key without operational effect since validators will already trust it. Software that is published just before the rollover (and devices with embedded software) will already know the right trust anchor to use after the rollover. Remember that "just before" is measured in years. The RFC 5011 add hold-down time is a minimum to mitigate some attack scenarios. It isn't intended to be an actual pre-publication interval used in real deployments, because if you do that the N-1 compromise resistance is useless. Question: Is it in fact practical to keep the standby key in a manner that makes it unlikely to be lost or compromised when the live key is? (How do you know you haven't lost the standby key if you never use it?!) Perhaps it is possible to come up with a better replacement for RFC 5011, because no longer need to worry about managing thousands of trust anchors, so we could tolerate a more elaborate scheme for establishing trust in the one root key. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From jabley@hopcount.ca Mon Jan 31 04:11:26 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3598F3A6BE6 for ; Mon, 31 Jan 2011 04:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYrSUk4Uifn0 for ; Mon, 31 Jan 2011 04:11:25 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 20B8D3A6938 for ; Mon, 31 Jan 2011 04:11:25 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PjsiZ-000Lbe-E9; Mon, 31 Jan 2011 12:18:52 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: Date: Mon, 31 Jan 2011 07:14:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> To: Tony Finch X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext List Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 12:11:26 -0000 On 2011-01-31, at 05:41, Tony Finch wrote: > Question: Is it in fact practical to keep the standby key in a manner = that > makes it unlikely to be lost or compromised when the live key is? (How = do > you know you haven't lost the standby key if you never use it?!) = Perhaps > it is possible to come up with a better replacement for RFC 5011, = because > no longer need to worry about managing thousands of trust anchors, so = we > could tolerate a more elaborate scheme for establishing trust in the = one > root key. The DNSSEC Policy and Practice Statements for the root zone have been = published for a long time -- there should be no mystery here. There is no pre-generated standby KSK for the root zone. If there *was* one, then it would presumably be generated using separate = ceremonies and stored in deliberately different places from the current = one (otherwise pretty much any compromise scenario for the production = KSK might also invalidate the standby key). Even then there would still = be elements in common, since the same organisation would be responsible = for managing both keys. As you note, there are also operational = challenges in maintaining a key that is not regularly exercised. The root zone KSK management procedures and facilities are designed to = minimise the threat of compromise: there are two separate, autonomous, = well-guarded and well-monitored facilities; procedures are audited; = ceremonies are scrutinised; etc. The approach is intended to minimise = the probability of compromise. RFC 5011 is a mechanism for scheduled key rollovers. There is always the = possibility that emergency key rollovers will happen, and that 5011 = semantics (in particular the 30-day dual-publish window) might not be = followed. I think the open question is not whether we need a better mechanism to = accommodate scheduled key rollovers -- the open question is how best to = bootstrap a validator that (for whatever reason) has no working trust = anchor installed. Joe From wouter@nlnetlabs.nl Mon Jan 31 05:06:48 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377D03A6C08 for ; Mon, 31 Jan 2011 05:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nniwcYZeZmv7 for ; Mon, 31 Jan 2011 05:06:47 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id D2DB43A6BEB for ; Mon, 31 Jan 2011 05:06:46 -0800 (PST) Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p0VD9vOR056209 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 31 Jan 2011 14:09:59 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4D46B4A5.1090502@nlnetlabs.nl> Date: Mon, 31 Jan 2011 14:09:57 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 31 Jan 2011 14:09:59 +0100 (CET) Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 13:06:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Joe, On 01/31/2011 01:14 PM, Joe Abley wrote: > RFC 5011 is a mechanism for scheduled key rollovers. There is always > the possibility that emergency key rollovers will happen, and that > 5011 semantics (in particular the 30-day dual-publish window) might > not be followed. The approaches under discussion that I made rely on a 30-day dual-publish window, the trust-history draft and the unbound-anchor tool. Because the approaches extend the 5011 mechanism with downtime compensation. You can see from the 5011 state why it is failing, and 30-days downtime caused it. Increased speed for the bootstrap mechanism would make that bootstrap mechanism less safe (because it can be used to circumvent the 30-day timer in 5011), hence I chose to wait until 5011 is known to fail (30-days passed) so that this 'add-on' to 5011 would not lower security. Thus a fast rollover would break those deployments: both 5011 and the bootstrap mechanism will fail, and the failure mode is that the key is unchanged. This is a feature, ... if you want software deployed that does something else, then, it is good to have this discussion :-) Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1GtKUACgkQkDLqNwOhpPjctQCfTAqOmPcmtXVmNkShmpzZ0Xao 3QUAnjCWf2NM751Q3GhsxAbRLWY/Yh5s =OlbS -----END PGP SIGNATURE----- From hallam@gmail.com Mon Jan 31 05:11:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7755F3A6C13 for ; Mon, 31 Jan 2011 05:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFPlGIrs5QEK for ; Mon, 31 Jan 2011 05:11:31 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id CB96E3A6C06 for ; Mon, 31 Jan 2011 05:11:30 -0800 (PST) Received: by ywk9 with SMTP id 9so2263966ywk.31 for ; Mon, 31 Jan 2011 05:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nQrXbaQnbx6yrpBzkrwbW4aeOH4FyWgvigeU/fUVm50=; b=uENCCR5NInO/xFXJU6cGjTcYbNVJbKF/dw7hq8jclAxr3fR3DYLVk31q3wshiljuJJ o4ABEy6lDOwk9KtoZlzTmirSIQrs7/UTv/Dk57sUt873Xc/AA7+sbrgFe+CBbKasPtkn cE92lmEyZCtN36VkYjvzKykFALtU6J8cBelWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eX+sAB/dF0U0qT5dv3rf5b8WdQyLixObkywQHex5yODs+rypHlspTlK3t+kuAvQWNi jy/LlCjKXvMgT7yAreztzsbVHdfFC3QUhp7V0JOS+qJb2fE+z5VWSxB2RSKXmMGl+JZE 6ajx5P1ZK+YiRQlYjHjmmmf4uZJx8gEZPdLLs= MIME-Version: 1.0 Received: by 10.100.8.9 with SMTP id 9mr3910289anh.120.1296479684856; Mon, 31 Jan 2011 05:14:44 -0800 (PST) Received: by 10.100.109.16 with HTTP; Mon, 31 Jan 2011 05:14:44 -0800 (PST) In-Reply-To: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> Date: Mon, 31 Jan 2011 08:14:44 -0500 Message-ID: From: Phillip Hallam-Baker To: Brian Dickson Content-Type: multipart/alternative; boundary=0016e6441dd8130b86049b2433cb Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 13:11:32 -0000 --0016e6441dd8130b86049b2433cb Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 31, 2011 at 12:21 AM, Brian Dickson < brian.peter.dickson@gmail.com> wrote: > > HOWEVER, and this is important, requiring TWO trust anchors of equal > strength (same algorithm, same number of bits) to BOTH chain-validate > the current root key properly as part of the bootstrap, where one of > those is a previous root key, has some distinct advantages: > - two keys (at least) would need to be compromised to compromise the target > - the possible compromise of a root key, followed by rolling the key, > means that the risk from following 5011 with that key, is only a > problem if the other bootstrap key is also compromised > - the value of compromising just the other bootstrap key is nearly > zero, since that is necessary but not sufficient to compromise the > target - thus limiting the value of this effort dramatically > ----> having one trust anchor only (which is not based on the root > key) does NOT have this benefit > - minimizing the window of opportunity for attack (a one-time-only > affair) further limits the value, and consequently lowers the > likelihood of even an attempt being made > I think it would be a good idea to have a separate chain of trust in this instance. ICANN has reserved the right to roll the root and according to one post requires the ability to do so at 60 days notice. To me that says that ICANN does not want to be the ultimate root of trust for everything on the Internet. They would be very ill advised to change that decision. The main challenge in setting up an alternative chain would be to find a party willing to run it that everyone involved can trust. Which is probably impossible. My view is that any ultimate root of trust would have to have a multiple signer configuration and would have to be available for more than just one technology. The cost of doing such a root right would be considerable. Using it for DNS alone would be a waste. Besides DNS there are many other critical roots that are at issue. Device authentication for example, there is a similar issue with RFID. Running such schemes becomes complicated because they end up hitting government security concerns. If every electronic device requires an identifier issued by a single entity under the control of one government, other governments wonder if that might be used as a weapon in a trade dispute. -- Website: http://hallambaker.com/ --0016e6441dd8130b86049b2433cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 31, 2011 at 12:21 AM, Brian = Dickson <brian.peter.dickson@gmail.com> wrote:

HOWEVER, and this is important, requiring TWO trust anchors of equal
strength (same algorithm, same number of bits) to BOTH chain-validate
the current root key properly as part of the bootstrap, where one of
those is a previous root key, has some distinct advantages:
- two keys (at least) would need to be compromised to compromise the target=
- the possible compromise of a root key, followed by rolling the key,
means that the risk from following 5011 with that key, is only a
problem if the other bootstrap key is also compromised
- the value of compromising just the other bootstrap key is nearly
zero, since that is necessary but not sufficient to compromise the
target - thus limiting the value of this effort dramatically
----> having one trust anchor only (which is not based on the root
key) does NOT have this benefit
- minimizing the window of opportunity for attack (a one-time-only
affair) further limits the value, and consequently lowers the
likelihood of even an attempt being made

I think it would be a good idea to have a separate chain of trust in this= instance.

ICANN has reserved the right to roll th= e root and according to one post requires the ability to do so at 60 days n= otice. To me that says that ICANN does not want to be the ultimate root of = trust for everything on the Internet. They would be very ill advised to cha= nge that decision.

The main challenge in setting up an alternative c= hain would be to find a party willing to run it that everyone involved can = trust. Which is probably impossible.


My view is that any ultimate root of trust would have to have a multip= le signer configuration and would have to be available for more than just o= ne technology. The cost of doing such a root right would be considerable. U= sing it for DNS alone would be a waste.=A0

Besides DNS there are many other critical roots that ar= e at issue. Device authentication for example, there is a similar issue wit= h RFID.

Running such schemes becomes complicated b= ecause they end up hitting government security concerns. If every electroni= c device requires an identifier issued by a single entity under the control= of one government, other governments wonder if that might be used as a wea= pon in a trade dispute.=A0

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

--0016e6441dd8130b86049b2433cb-- From jabley@hopcount.ca Mon Jan 31 05:21:27 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E38A3A6BFE for ; Mon, 31 Jan 2011 05:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByKlftOM5IEm for ; Mon, 31 Jan 2011 05:21:26 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id E6C7D3A6BF1 for ; Mon, 31 Jan 2011 05:21:25 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PjtoJ-000Nup-Ot; Mon, 31 Jan 2011 13:28:52 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: Date: Mon, 31 Jan 2011 08:24:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 13:21:27 -0000 On 2011-01-31, at 08:14, Phillip Hallam-Baker wrote: > ICANN has reserved the right to roll the root and according to one = post requires the ability to do so at 60 days notice. Since we have a published DPS, let's refer to that rather than pulling = numbers out of e-mail threads. https://www.iana.org/dnssec/icann-dps.txt Joe 4.5.3. Entity private key compromise procedures 4.5.3.1. Key Signing Key compromise ICANN has established and maintains Emergency KSK roll-over procedures to ensure readiness for key compromise situations. Upon the suspected or known compromise of a Root Zone Key Signing Key, IKOS will assess the situation, develop an appropriate action plan, and implement the action plan with approval from the PMA and ICANN executive management. As part of the KSK emergency roll-over procedures, ICANN maintains the capability of being able to generate and publish an interim Trust Anchor within 48 hours. In favorable circumstances, this interim Trust Anchor may be used to facilitate an orderly RFC 5011 [RFC5011] automatic KSK roll-over to a new and sanctioned Trust Anchor generated at a new scheduled key ceremony, held within reasonable time. ICANN will inform the community of any emergency as soon as possible using the channels stipulated in section 2.1. 4.5.3.2. Key Signing Key loss If the private component of a Trust Anchor is permanently lost, the latest point in time where this loss is detected, will inevitably be at the key ceremony when it is supposed to be used. At this point in time, the Root Zone Maintainer/ZSK Operator has signatures for at least 33 days (see 6.6) of independent operations. If possible, a new KSK will be generated at this key ceremony or another ceremony scheduled within 48 hours. If ICANN is unable to accommodate the key ceremony, an interim KSK must be generated by ICANN and published as a Trust Anchor within the stipulated 48 hours. The community is then given a minimum of 30 days notice to add the new Trust Anchors to the validating resolvers before the DNSKEY RRset has to be re-signed with the new Trust Anchor. Failure to update a validating resolver will render that resolver inoperable. ICANN will inform the community of any emergency as soon as possible using the channels stipulated in section 2.1. The old Trust Anchor will remain untouched in the key set for one 10 days time slot (see section Section 6.6). In the next consecutive time slot, the old Trust Anchor will be marked as revoked, and after this time slot the lost key is permanently removed. 4.5.3.3. Zone Signing Key Compromise ICANN will support Root Zone Zone Signing Key emergency rollover in the case of RZ ZSK compromise while following VeriSign's procedural directions. Refer to the Root Zone ZSK Operator's DPS for details. From brian.peter.dickson@gmail.com Mon Jan 31 10:19:16 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2073A6B32 for ; Mon, 31 Jan 2011 10:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.222 X-Spam-Level: X-Spam-Status: No, score=-3.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19oQLVBW6i+Y for ; Mon, 31 Jan 2011 10:19:15 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 269483A6AD9 for ; Mon, 31 Jan 2011 10:19:14 -0800 (PST) Received: by ewy8 with SMTP id 8so2943406ewy.31 for ; Mon, 31 Jan 2011 10:22:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Lh8Y01O4338gX+xLNR955llNl2vWwvOOSM4HDD2iF4c=; b=ozjqIU65M1CBx6LnHS6yPSvT5EvIbgWzA9TPFGTFXoe5OP/csu1EDI/BL6E9/1MF9P v285bG+TgLDTf6JDdOoo0JZsYlqlgi/IVC4ZKUlRIYZOVkIVWsF6WOBuC4mUDOyTSbYe vCjvmWaZMqaDvht13wl4GLgC9f7Hkj5RVS3u8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jvktWavQoqzXayGLuIlQ9M9Sp/62YqMRMvr8kBZamIdIkRlFJyYUQN5BGQDd+vbcBL iGL7dLh7cgaqGtW1CCL7PkHPOujXq8axg8eG2CExFOut2SUnAaGvTH2DqpqrXYemvNMP p/ZwOLHYaIl1OgqSvP7dVLNiM0z+BaGxJwDUc= MIME-Version: 1.0 Received: by 10.223.86.12 with SMTP id q12mr5812593fal.18.1296498149431; Mon, 31 Jan 2011 10:22:29 -0800 (PST) Received: by 10.223.108.71 with HTTP; Mon, 31 Jan 2011 10:22:29 -0800 (PST) In-Reply-To: <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> Date: Mon, 31 Jan 2011 14:22:29 -0400 Message-ID: From: Brian Dickson To: Joe Abley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 18:19:16 -0000 On Mon, Jan 31, 2011 at 9:24 AM, Joe Abley wrote: > > Since we have a published DPS, let's refer to that rather than pulling nu= mbers out of e-mail threads. > > =A0https://www.iana.org/dnssec/icann-dps.txt Thanks for pointing that out. Having read it, it appears that any new RZ KSK is pre-published and signed by the old KSK for about 50 days only. After that point in time, an old trust anchor would no longer be able to automagically validate the new KSK (5011 method). So, it appears that an automagic bootstrap method would have to rely on something other than the RZ KSK (or specifically its trust anchor/public key). The simplest bootstrap method would be to have a series of BSK (bootstrap keys), created on a periodic basis (every N years), and used as follows: - keep all the keys indefinitely (e.g. until such time as it can reasonably be expected that the vast majority of consumers of the key have bootstrapped, or that it is unreasonable to keep a particular key due to operational constraints.) - sign the current RZ KSK using all the keys, with appropriate signature intervals/durations/effort, such as annually pre-generating M signatures with validity durations of 60 days and overlaps of 7 days at each end - publish the latest key and sign it along with the RZ KSK - any one BSK would be able to validate the current RZ KSK - any manufacturer would be able to validate the current BSK, both via its own self-signature, and via the current RZ ZSK and standard validation. The current RZ KSK itself can be installed/validated using the ICANN-published procedures/mechanisms. A slightly more secure method would involve two (or more) independent series of such keys, but that may be overkill or too "expensive". The number of consumers of the current key would vary (up and/or down, as devices are manufactured and bootstrapped respectively). The number of consumers of previous keys would be monotonically decreasing. Bootstrap would be a one-step process (retrieve RZ KSK and validate using the trust anchor), unless there were multiple bootstrap trust anchors, in which case it would be an X step process (X being the number of trust anchors installed). Brian From paul@xelerance.com Mon Jan 31 11:12:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCA93A6965 for ; Mon, 31 Jan 2011 11:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHm4fKkePPrD for ; Mon, 31 Jan 2011 11:12:32 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id E1B1E3A6C21 for ; Mon, 31 Jan 2011 11:12:31 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 93B10C4FE; Mon, 31 Jan 2011 14:15:45 -0500 (EST) Date: Mon, 31 Jan 2011 14:15:45 -0500 (EST) From: Paul Wouters To: Brian Dickson In-Reply-To: Message-ID: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:12:32 -0000 On Mon, 31 Jan 2011, Brian Dickson wrote: > Having read it, it appears that any new RZ KSK is pre-published and > signed by the old KSK for about 50 days only. > > After that point in time, an old trust anchor would no longer be able > to automagically validate the new KSK (5011 method). > > So, it appears that an automagic bootstrap method would have to rely > on something other than the RZ KSK (or specifically its trust > anchor/public key). > > The simplest bootstrap method would be to have a series of BSK > (bootstrap keys), created on a periodic basis (every N years), and I think the simplest method is the TALINK one described in Wouter's draft. Keep the historic 5011 information in a special zone (and ignore the expired RRSIGs in them) I don't think we realistically can change the current root key management. Paul From jabley@hopcount.ca Mon Jan 31 11:17:08 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730463A6A7A for ; Mon, 31 Jan 2011 11:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Alc4XGkDLnoz for ; Mon, 31 Jan 2011 11:17:07 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 69D003A6C4D for ; Mon, 31 Jan 2011 11:17:01 -0800 (PST) Received: from [127.0.0.1] (helo=[IPv6:::1]) by monster.hopcount.ca with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PjzMU-0009dL-Ae; Mon, 31 Jan 2011 19:24:31 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: Date: Mon, 31 Jan 2011 14:20:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> To: Brian Dickson X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:17:08 -0000 On 2011-01-31, at 13:22, Brian Dickson wrote: > On Mon, Jan 31, 2011 at 9:24 AM, Joe Abley wrote: >>=20 >> Since we have a published DPS, let's refer to that rather than = pulling numbers out of e-mail threads. >>=20 >> https://www.iana.org/dnssec/icann-dps.txt >=20 > Thanks for pointing that out. >=20 > Having read it, it appears that any new RZ KSK is pre-published and > signed by the old KSK for about 50 days only. For a scheduled KSK roll, yes. Note that that's not what we're talking = about. Joe= From hallam@gmail.com Mon Jan 31 11:19:47 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D843A6C55 for ; Mon, 31 Jan 2011 11:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZNm62gK-2I8 for ; Mon, 31 Jan 2011 11:19:46 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 559A83A6B32 for ; Mon, 31 Jan 2011 11:19:46 -0800 (PST) Received: by gwb20 with SMTP id 20so2477360gwb.31 for ; Mon, 31 Jan 2011 11:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BtGD8ZRtU3XGS0p8ztDyUBJ/R1Hbg1bIPSXpJrZS27Y=; b=XlpV7gWPFgdXC3eRUxweP1RaqJZXWYpfIlNzLvVWbej+RdNkczFlh3vmnuyNk4clNf XZBNnGfI2n7ppUvNUpObxkAySdtbdgDh8uYtnXH9OkoTjRsG151WyAazQh2cmiHkvB/T 1zezUQMgnKAZo2eBpf/R+Fo9e9I8pXLOSGX5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kCCqzO8wE2O21ThrQOybIotEfJXdeFPw05oPYwqsir4C6Di0qK1hwIHfFP2UyRGIxc GszJgt47tQjWA7jqKkLBWNUdftqUNo4VxUA/5I9XuRQ1p8tuk3uD+cXJ/G3Ukyx7EUZc 2B+P9N8ECb1GFRHEqUGeCu0ZnGXmZzE+r8bqc= MIME-Version: 1.0 Received: by 10.100.134.10 with SMTP id h10mr4165826and.86.1296501780751; Mon, 31 Jan 2011 11:23:00 -0800 (PST) Received: by 10.100.109.16 with HTTP; Mon, 31 Jan 2011 11:23:00 -0800 (PST) In-Reply-To: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> Date: Mon, 31 Jan 2011 14:23:00 -0500 Message-ID: From: Phillip Hallam-Baker To: Brian Dickson Content-Type: multipart/alternative; boundary=0016e644c70817a80c049b29587e Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:19:47 -0000 --0016e644c70817a80c049b29587e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 31, 2011 at 1:22 PM, Brian Dickson < brian.peter.dickson@gmail.com> wrote: > On Mon, Jan 31, 2011 at 9:24 AM, Joe Abley wrote: > > > > Since we have a published DPS, let's refer to that rather than pulling > numbers out of e-mail threads. > > > > https://www.iana.org/dnssec/icann-dps.txt > > Thanks for pointing that out. > > Having read it, it appears that any new RZ KSK is pre-published and > signed by the old KSK for about 50 days only. > > After that point in time, an old trust anchor would no longer be able > to automagically validate the new KSK (5011 method). > > So, it appears that an automagic bootstrap method would have to rely > on something other than the RZ KSK (or specifically its trust > anchor/public key). > > The simplest bootstrap method would be to have a series of BSK > (bootstrap keys), created on a periodic basis (every N years), and > used as follows: If a compromise has occurred then the first thing to ask would be why. There are only three places where a compromise can logically occur - in the cryptographic algorithm, in the cryptographic hardware manufacturer or in ICANN, If its the algorithm then the whole series of BSKs is compromised. If it is the manufacturer of the HSM, same thing. If the issue was ICANN it is unlikely we would want to re-implement the scheme that had failed. -- Website: http://hallambaker.com/ --0016e644c70817a80c049b29587e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 31, 2011 at 1:22 PM, Brian D= ickson <brian.peter.dickson@gmail.com> wrote:
On Mon, Jan 31, 2011 at 9:24 AM, Joe Abley <jabley@hopcount.ca> wrote:
>
> Since we have a published DPS, let's refer to that rather than pul= ling numbers out of e-mail threads.
>
> =A0https://www.iana.org/dnssec/icann-dps.txt

Thanks for pointing that out.

Having read it, it appears that any new RZ KSK is pre-published and
signed by the old KSK for about 50 days only.

After that point in time, an old trust anchor would no longer be able
to automagically validate the new KSK (5011 method).

So, it appears that an automagic bootstrap method would have to rely
on something other than the RZ KSK (or specifically its trust
anchor/public key).

The simplest bootstrap method would be to have a series of BSK
(bootstrap keys), created on a periodic basis (every N years), and
used as follows:


If a compro= mise has occurred then the first thing to ask would be why.

<= /div>
There are only three places where a compromise can logically occu= r - in the cryptographic algorithm, in the cryptographic hardware manufactu= rer or in ICANN,

If its the algorithm then the whole series of BSKs is c= ompromised.

If it is the manufacturer of the HSM, = same thing.

If the issue was ICANN it is unlikely = we would want to re-implement the scheme that had failed.




--
We= bsite: http://hallambaker.com/
<= br> --0016e644c70817a80c049b29587e-- From nweaver@icsi.berkeley.edu Mon Jan 31 11:28:41 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3DE3A6C58 for ; Mon, 31 Jan 2011 11:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eiwdfm6C+nKL for ; Mon, 31 Jan 2011 11:28:40 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 56AE03A6C57 for ; Mon, 31 Jan 2011 11:28:40 -0800 (PST) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 7D77B36A037; Mon, 31 Jan 2011 11:31:55 -0800 (PST) References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <899F4D8E-2E75-44C3-A001-612582209C86@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Mon, 31 Jan 2011 11:31:55 -0800 To: Joe Abley X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:28:41 -0000 On Jan 31, 2011, at 11:20 AM, Joe Abley wrote: >=20 > On 2011-01-31, at 13:22, Brian Dickson wrote: >=20 >> On Mon, Jan 31, 2011 at 9:24 AM, Joe Abley = wrote: >>>=20 >>> Since we have a published DPS, let's refer to that rather than = pulling numbers out of e-mail threads. >>>=20 >>> https://www.iana.org/dnssec/icann-dps.txt >>=20 >> Thanks for pointing that out. >>=20 >> Having read it, it appears that any new RZ KSK is pre-published and >> signed by the old KSK for about 50 days only. >=20 > For a scheduled KSK roll, yes. Note that that's not what we're talking = about. I thought we WERE talking about for scheduled KSK rolls. If we have either an algorithm or KSK key compromise, we have a far = bigger problem and going to a more human-centric route is probably = doable. ESPECIALLY if a failure for the TALINK-like mechanism (which fails for = compromise-cases) is 'do leap of faith for the root for NON-secure = records', so even then the name lookups etc will still work, only = cryptographic trust mechanisms built on top of DNSSEC would fail. From brian.peter.dickson@gmail.com Mon Jan 31 11:29:07 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7D23A6C68 for ; Mon, 31 Jan 2011 11:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.236 X-Spam-Level: X-Spam-Status: No, score=-3.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obt2mZejiN1n for ; Mon, 31 Jan 2011 11:29:06 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 8632F3A6C6C for ; Mon, 31 Jan 2011 11:29:06 -0800 (PST) Received: by fxm9 with SMTP id 9so6519719fxm.31 for ; Mon, 31 Jan 2011 11:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=t9pg7Egwe3tDLZU5bVlWKirFckwQ0aKIBMwUXe44oWk=; b=TPsdENiRFEQa+mDVIG7Pot+4i06WNbLoRVPWG9WKGGVHFGEWn7FjYF8FbeEHtdMohG q0LgEPZzYww2PDdAPpBH3QEnJuoxMBFOQYlHJQC9mvd5YyucDrjIz/iH6hUI/ibcLwst /IwzbjvgcUBF+ke0PPKe+JAHG5z6hitvyFhkg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZGoDG0KNBK8jyc2bLauAF2N8B7PGw1j7gBlTEEe38jCl/Um3HT7RQ2ujhP9qVzrcuU nZEmiGWs3Pwk1L5S8phlnMNV/ketKh896yd+RQSxJ/1pUyzhUJnDsJGemBLP/vxyFuFl Xuoq+Aa6nZ3lukytnsvGEF5rc3Dysbn7N/KG4= MIME-Version: 1.0 Received: by 10.223.93.139 with SMTP id v11mr6321031fam.132.1296502340878; Mon, 31 Jan 2011 11:32:20 -0800 (PST) Received: by 10.223.108.71 with HTTP; Mon, 31 Jan 2011 11:32:20 -0800 (PST) In-Reply-To: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> Date: Mon, 31 Jan 2011 15:32:20 -0400 Message-ID: From: Brian Dickson To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:29:08 -0000 On Mon, Jan 31, 2011 at 3:23 PM, Phillip Hallam-Baker wrote: > > > On Mon, Jan 31, 2011 at 1:22 PM, Brian Dickson > wrote: >> The simplest bootstrap method would be to have a series of BSK >> (bootstrap keys), created on a periodic basis (every N years), and >> used as follows: > > If a compromise has occurred then the first thing to ask would be why. > There are only three places where a compromise can logically occur - in the > cryptographic algorithm, in the cryptographic hardware manufacturer or in > ICANN, No, there is a fourth place: brute force attack on the key/signature, to find the key. The brute force success on one key, compromises that key only, plus any data signed by it or derived therefrom. If another key of the same algorithm, held in the same hardware and operated by the same party exists, but is not dependent upon the first key, it remains secure. Brian From jabley@hopcount.ca Mon Jan 31 11:29:24 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7753A6C62; Mon, 31 Jan 2011 11:29:24 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9xI2KV46Hhs; Mon, 31 Jan 2011 11:29:23 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id EE37C3A6C4C; Mon, 31 Jan 2011 11:29:22 -0800 (PST) Received: from [127.0.0.1] (helo=[IPv6:::1]) by monster.hopcount.ca with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PjzYT-000A53-6g; Mon, 31 Jan 2011 19:36:54 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Joe Abley Date: Mon, 31 Jan 2011 14:32:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> To: dnsext List , "dnsop@ietf.org WG" X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: Knight Dave Subject: [dnsext] draft-jabley-dnsop-validator-bootstrap-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "dnsop@ietf.org WG" List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:29:24 -0000 Hi all, Per below, Dave and I scribbled some thoughts down about how we might = recommend validators obtain a useful root zone trust anchor on startup. It's scrappy, and it's little more than I have said on this list in the = past week, but I thought it might be handy to have in written form. I = used a dnsop tag rather than a dnsext one at Andrew Sullivan's = suggestion, since this looks like operations more than it looks like = protocol work. dnsoppers: there's a party going on in dnsext. Look over the fence for = context. Reply-To set. Joe Begin forwarded message: > From: IETF I-D Submission Tool > Date: 31 January 2011 14:24:56 EST > To: Joe Abley > Cc: Dave Knight > Subject: New Version Notification for = draft-jabley-dnsop-validator-bootstrap-00=20 >=20 >=20 > A new version of I-D, draft-jabley-dnsop-validator-bootstrap-00.txt = has been successfully submitted by Joe Abley and posted to the IETF = repository. >=20 > Filename: draft-jabley-dnsop-validator-bootstrap > Revision: 00 > Title: Establishing an Appropriate Root Zone DNSSEC = Trust Anchor at Startup > Creation_date: 2011-01-31 > WG ID: Independent Submission > Number_of_pages: 17 >=20 > Abstract: > Domain Name System Security Extensions (DNSSEC) allow cryptographic > signatures to be used to validate responses received from the Domain > Name System (DNS). A DNS client which validates such signatures is > known as a validator. >=20 > The choice of appropriate root zone trust anchor for a validator is > expected to vary over time as the corresponding cryptographic keys > used in DNSSEC are changed. >=20 > This document provides guidance on how validators might determine an > appropriate trust anchor for the root zone to use at start-up, or > when other mechanisms intended to allow key rollover to be tolerated > gracefully are not available. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 From nweaver@icsi.berkeley.edu Mon Jan 31 11:33:21 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D763A6C40 for ; Mon, 31 Jan 2011 11:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsPMe2KbXamj for ; Mon, 31 Jan 2011 11:33:20 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 396A43A6C3F for ; Mon, 31 Jan 2011 11:33:20 -0800 (PST) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 6768E36A037; Mon, 31 Jan 2011 11:36:35 -0800 (PST) References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <4EEDA682-9A6B-4B5A-9DBD-1D2CB6DA1735@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Mon, 31 Jan 2011 11:36:35 -0800 To: Brian Dickson X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:33:21 -0000 On Jan 31, 2011, at 11:32 AM, Brian Dickson wrote: > On Mon, Jan 31, 2011 at 3:23 PM, Phillip Hallam-Baker = wrote: >>=20 >>=20 >> On Mon, Jan 31, 2011 at 1:22 PM, Brian Dickson >> wrote: >=20 >>> The simplest bootstrap method would be to have a series of BSK >>> (bootstrap keys), created on a periodic basis (every N years), and >>> used as follows: >>=20 >> If a compromise has occurred then the first thing to ask would be = why. >> There are only three places where a compromise can logically occur - = in the >> cryptographic algorithm, in the cryptographic hardware manufacturer = or in >> ICANN, >=20 > No, there is a fourth place: brute force attack on the key/signature, > to find the key. >=20 > The brute force success on one key, compromises that key only, plus > any data signed by it or derived therefrom. NO THERE IS NOT! Repeat after me: "If you are in even the remotest danger of a brute force attack by = anything less than a cubic-earth of sci-fi nanotech, you need to use a = larger key." Cryptographic attacks may happen, which if it makes it possible to = brute-force one key implies that the cryptosystem itself has broken. =20 Brute force alone, outside the context of a cryptographic attack, WILL = NOT HAPPEN. From hallam@gmail.com Mon Jan 31 11:34:43 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BFF03A6C58 for ; Mon, 31 Jan 2011 11:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcJka991Kzpm for ; Mon, 31 Jan 2011 11:34:41 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 998BE3A6C40 for ; Mon, 31 Jan 2011 11:34:41 -0800 (PST) Received: by yie19 with SMTP id 19so2452709yie.31 for ; Mon, 31 Jan 2011 11:37:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/clOmxsAZQf+Wx8ih/saONiF08WtXmOjaOCUcMjUhS0=; b=L4TbtGACHKl4vl/8bPAOj38uRPhGcaGjthZ7viWbbEi2mSj0uBlyHnN4R8Mwe3gBJs rmtwdpRLN7KMSPK4lRkn6RXJFsrE59Vqn+axvKrKN40KBnfJv/5j8Qw9lAD29BN8ORKb VWazoDZVpAAkpI0eTUwiRXkoe/ct8+K1KOgk0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jeXyx98x+mT9b6SqVlyzoe01r40KLqTn2LcQjQEhQ0m3BInYyN6CbycvJV/h/xqHfM ZFM64rmBEfs4slGLG0etwhw/YEN797MEe6ZW37TiRsAacNLdmd4JEbkhpRFzZ9P8DnXI FLldNR/4XcQwESHj6npnZvY6lE1h4xIUl3aHM= MIME-Version: 1.0 Received: by 10.100.48.3 with SMTP id v3mr4242685anv.154.1296502676066; Mon, 31 Jan 2011 11:37:56 -0800 (PST) Received: by 10.100.109.16 with HTTP; Mon, 31 Jan 2011 11:37:55 -0800 (PST) In-Reply-To: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> Date: Mon, 31 Jan 2011 14:37:55 -0500 Message-ID: From: Phillip Hallam-Baker To: Joe Abley Content-Type: multipart/alternative; boundary=0016e645b8c4751132049b298d0c Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:34:43 -0000 --0016e645b8c4751132049b298d0c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 31, 2011 at 2:20 PM, Joe Abley wrote: > > On 2011-01-31, at 13:22, Brian Dickson wrote: > > > On Mon, Jan 31, 2011 at 9:24 AM, Joe Abley wrote: > >> > >> Since we have a published DPS, let's refer to that rather than pulling > numbers out of e-mail threads. > >> > >> https://www.iana.org/dnssec/icann-dps.txt > > > > Thanks for pointing that out. > > > > Having read it, it appears that any new RZ KSK is pre-published and > > signed by the old KSK for about 50 days only. > > For a scheduled KSK roll, yes. Note that that's not what we're talking > about. That is the one that I was talking about. If we ever got to the stage where we did an emergency roll we are in unknown territory. Its like planning for what to do in case of civil war in the US. So many other things would have to change before it was a possibility that planning is futile. ICANN can eliminate the problem of rollovers for scheduled rolls by announcing that it will never roll the key except in an emergency. We faced this problem in the PKI world and found that 20 year roots were a better solution. So far the only issues caused have been due to doubts as to the security of the cryptographic algorithm which in turn is perhaps excusable given that the state of cryptography was not as good in the 1990s as it is today [*] I know that it is fashionable to roll keys every so often. But in the case of a root key it causes more problems than it solves. [*] Use of MD5 is discouraged for new signatures but it is not yet compromised in a way that invalidates MD5 signed roots. -- Website: http://hallambaker.com/ --0016e645b8c4751132049b298d0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 31, 2011 at 2:20 PM, Joe Abl= ey <jabley@hopco= unt.ca> wrote:

On 2011-01-31, at 13:22, Brian Dickson wrote:

> On Mon, Jan 31, 2011 at 9:24 AM, Joe Abley <jabley@hopcount.ca> wrote:
>>
>> Since we have a published DPS, let's refer to that rather than= pulling numbers out of e-mail threads.
>>
>> https://www.iana.org/dnssec/icann-dps.txt
>
> Thanks for pointing that out.
>
> Having read it, it appears that any new RZ KSK is pre-published and > signed by the old KSK for about 50 days only.

For a scheduled KSK roll, yes. Note that that's not what we'r= e talking about.

That is the one that I was= talking about.

If we ever got to the stage where = we did an emergency roll we are in unknown territory. Its like planning for= what to do in case of civil war in the US. So many other things would have= to change before it was a possibility that planning is futile.


ICANN can eliminate the problem of rollo= vers for scheduled rolls by announcing that it will never roll the key exce= pt in an emergency.

We faced this problem in the P= KI world and found that 20 year roots were a better solution. So far the on= ly issues caused have been due to doubts as to the security of the cryptogr= aphic algorithm which in turn is perhaps excusable given that the state of = cryptography was not as good in the 1990s as it is today [*]

I know that it is fashionable to roll keys every so oft= en. But in the case of a root key it causes more problems than it solves.= =A0


[*] Use of MD5 is discouraged = for new signatures but it is not yet compromised in a way that invalidates = MD5 signed roots.
--
Website: http://hallambaker.com/=

--0016e645b8c4751132049b298d0c-- From hallam@gmail.com Mon Jan 31 11:39:47 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33BAA3A6C36 for ; Mon, 31 Jan 2011 11:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eppznv6G-OhM for ; Mon, 31 Jan 2011 11:39:46 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 172733A684E for ; Mon, 31 Jan 2011 11:39:45 -0800 (PST) Received: by ywk9 with SMTP id 9so2462707ywk.31 for ; Mon, 31 Jan 2011 11:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sMWK+68FPVnBK6AYCnIUHV0BaDFmRr78S3kGfBZUd0g=; b=maHTkMlNEa79uhdY/NGeCGW9fehlvu7TCXg301cqYSytj2eEel4yG+kcuYMwIe+R1B nCG9L4twqCGLh6sb51PmUhYf4nAIgUsInA+AQpCTryFaoEDNqvHzgauDGQ4uGERk/2y6 A78q7ygNrj/KL1f6VFWFlBFEGY3z++5JLA6pw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iWYuSKoR6cb6EQEIeP6B68mRkEseEVUwLmWlJweTufOpXTWY65D0IpyxV9JftPfgk2 8+lJj+06Yyr8I1BGi4tMUL7S3TJO0UK3dX+gZT/5k4kghbfA/fDFnzRA7nmv0KsDPDQS wm4xJMhzUTcOn4FL5/4mjkHgJAyaeClk6DR1Q= MIME-Version: 1.0 Received: by 10.100.134.10 with SMTP id h10mr4179381and.86.1296502979922; Mon, 31 Jan 2011 11:42:59 -0800 (PST) Received: by 10.100.109.16 with HTTP; Mon, 31 Jan 2011 11:42:59 -0800 (PST) In-Reply-To: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> Date: Mon, 31 Jan 2011 14:42:59 -0500 Message-ID: From: Phillip Hallam-Baker To: Brian Dickson Content-Type: multipart/alternative; boundary=0016e644c708918e6e049b299fbf Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:39:47 -0000 --0016e644c708918e6e049b299fbf Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 31, 2011 at 2:32 PM, Brian Dickson < brian.peter.dickson@gmail.com> wrote: > On Mon, Jan 31, 2011 at 3:23 PM, Phillip Hallam-Baker > wrote: > > > > > > On Mon, Jan 31, 2011 at 1:22 PM, Brian Dickson > > wrote: > > >> The simplest bootstrap method would be to have a series of BSK > >> (bootstrap keys), created on a periodic basis (every N years), and > >> used as follows: > > > > If a compromise has occurred then the first thing to ask would be why. > > There are only three places where a compromise can logically occur - in > the > > cryptographic algorithm, in the cryptographic hardware manufacturer or in > > ICANN, > > No, there is a fourth place: brute force attack on the key/signature, > to find the key. > No, that would be a cryptographic algorithm weakness which was the first case I gave. -- Website: http://hallambaker.com/ --0016e644c708918e6e049b299fbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 31, 2011 at 2:32 PM, Brian D= ickson <brian.peter.dickson@gmail.com> wrote:
On Mon, Jan 31, 2011 at 3:23 PM, Phillip Hallam-Baker <= ;hallam@gmail.com> wrote:
>
>
> On Mon, Jan 31, 2011 at 1:22 PM, Brian Dickson
> <brian.peter.dicks= on@gmail.com> wrote:

>> The simplest bootstrap method would be to = have a series of BSK
>> (bootstrap keys), created on a periodic basis (every N years), and=
>> used as follows:
>
> If a compromise has occurred then the first thing to ask would be why.=
> There are only three places where a compromise can logically occur - i= n the
> cryptographic algorithm, in the cryptographic hardware manufacturer or= in
> ICANN,

No, there is a fourth place: brute force attack on the key/signature,=
to find the key.

No, that would be a cr= yptographic algorithm weakness which was the first case I gave.
<= br>

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

--0016e644c708918e6e049b299fbf-- From jabley@hopcount.ca Mon Jan 31 11:59:47 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC873A6C70 for ; Mon, 31 Jan 2011 11:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x17eEy5djPw for ; Mon, 31 Jan 2011 11:59:46 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 4BC8C3A6C57 for ; Mon, 31 Jan 2011 11:59:46 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pk01q-000B6S-UX; Mon, 31 Jan 2011 20:07:15 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <899F4D8E-2E75-44C3-A001-612582209C86@icsi.berkeley.edu> Date: Mon, 31 Jan 2011 15:02:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <63AEECED-2D62-4FC4-81C8-87464D37A72E@hopcount.ca> References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> <899F4D8E-2E75-44C3-A001-612582209C86@icsi.berkeley.edu> To: Nicholas Weaver X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:59:47 -0000 On 2011-01-31, at 14:31, Nicholas Weaver wrote: > If we have either an algorithm or KSK key compromise, we have a far = bigger problem and going to a more human-centric route is probably = doable. The problem space we're considering is that of embedded devices (think = 5,000,000 deployed linksys home gateways) for which a human-centric path = is effectively not an option. No? > ESPECIALLY if a failure for the TALINK-like mechanism (which fails for = compromise-cases) is 'do leap of faith for the root for NON-secure = records', so even then the name lookups etc will still work, only = cryptographic trust mechanisms built on top of DNSSEC would fail. The problem with the TALINK and similar trust-chaining proposals is that = in the cases where you really need them, they can't work. I don't think the scheme I just posted (and have described here before) = is particularly elegant, but it has the benefit that it's immediately = deployable and doesn't introduce any trust points into the system that = aren't already there. Joe= From jbash@cisco.com Mon Jan 31 13:41:11 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66FC63A6CA1; Mon, 31 Jan 2011 13:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UARwYky9uEoc; Mon, 31 Jan 2011 13:41:09 -0800 (PST) Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id A86373A6AF9; Mon, 31 Jan 2011 13:41:09 -0800 (PST) Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id B2C961A536D; Mon, 31 Jan 2011 16:44:18 -0500 (EST) Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id 9AFF238F1; Mon, 31 Jan 2011 16:44:17 -0500 (EST) Message-ID: <4D472D2C.9090108@cisco.com> Date: Mon, 31 Jan 2011 16:44:12 -0500 From: John Bashinski Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: "dnsop@ietf.org WG" References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> In-Reply-To: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5C1D5D75B6338C2F3D4FA8AB" Cc: Knight Dave , dnsext List Subject: Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:41:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5C1D5D75B6338C2F3D4FA8AB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-01-31 14:32, Joe Abley wrote: > Per below, Dave and I scribbled some thoughts down about how we might > recommend validators obtain a useful root zone trust anchor on > startup. Wow, that's fast service. :-) > Individual trust anchors are also packaged as X.509 identity > certificates, signed by various Certificate Authorities (CAs). How firmly are you attached to your approach? Would you be prepared to consider supporting alternatives, if consensus could be gathered behind them? If so, what would be your concerns? We've heard a lot about my/our requirements. What are *your* requirements? What would an alternative bootstrap scheme have to do before you could support it? What procedural guarantees can you provide, and what guarantees can't you provide? =46rom what I'm seeing, I kind of doubt we'll get consensus on anything else quickly enough to be useful on our timetable, so I *suspect* we're going to have to do what you suggest, at least until something better comes along, and maybe forever. For the longer term, maybe we could think about other things. Given our own constraints, under your draft we (Cisco) would need to maintain our own bootstrapping service. Specifically, we'd need to play the role of the X.509 CA signing the root KSKs in your section 5.3: > Individual trust anchors are also packaged as X.509 identity > certificates, signed by various Certificate Authorities (CAs). If we do have to roll our own as you suggest, we may want to give customers more assurance than your draft specifies, by augmenting your procedure. Specifically, we might do as you suggest, but *additionally* retrieve from Cisco a signed 5011 rollover list. The idea there would be that somebody would have to compromise *both* Cisco and at least one historical root KSK. Of course, the downside would be that any non-5011 key roll would break the devices. We'll probably have to think about that. Of course, it's even less likely that you'd want to suggest it to others than that we'd do it ourselves. Prodedural details =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I assume you *are* saying that the http://data.iana.org/root-anchors/root-anchors.xml URL is guaranteed good for a long time? I'm not sure what procedure we're meant to use to get the validated CSRs to create the X.509 certificates for new KSKs. Can you say anything about that? I assume that the "ultimate" way to do it is to send some people to a key ceremony. To be honest, I'm not sure that I could convince management (or even myself) that that gave enough extra assurance to be worth it. I suspect what we'd end up doing, absent other guidance, would be just grabbing the CSR from wherever, and looking at the root KSK in use on our own internal systems to see if it was right... then signing it. Some comments on the draft itself: Finding CAs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D You say: > URLs > to allow those certificates to be retrieved are included as optional > elements in the XML document. I don't actually see any CA URLs in the XML at the moment. Obviously you can't just grab a root cert from such a URL and trust it, anyway... you have to have either a wired-in copy of the cert itself, or at least a wired-in copy of its public key. So I'm not sure I see what having the URLs in the XML would do for anybody. > alternatively a vendor may instantiate its own CA and make > arrangements with the root zone KSK manager to have the corresponding > identity certificate locations published in root-anchors.xml. Our devices already have copies of our own CA's root cert for other reasons, so we'd just let them rely on that. I'd assume others would do similarly. Time =3D=3D=3D=3D > 3.1 Initial State > [...] > A validator must confirm that its local clock is sufficiently > accurate before trust anchors can be established, and before > processing of DNSSEC signatures can proceed. Discussion of timing > considerations can be found in Section 4. How? I know I brought it up, but I'm getting a little nervous about using the home router as the only reference point. Nonetheless, it's a good paradigmatic case, and I'll go with it for now. You're a home router. You've just been plugged in, either new from the box or after being in a closet for a long time. Do you: 1. Rely on your local real-time clock? I'm not saying this is impossible,= but: a. Much existing hardware (not just Linksys; many home routers) doesn't have RTCs. Putting one in would significantly increase the build cost of the hardware, I'm guessing by several percent. And it would reduce the reliability and shelf life. b. If you've been in a closet for a while, your RTC may have drifted enough to matter. Perhaps more likely, the battery for your RTC may have died... an event you may or may not be able to detect and usually can't report. c. The user may have set the RTC wrong before you went into that closet. This is perhaps more likely for a PC than for a router, but it could happen... and PCs are also in scope. 2. Rely on NTP? If so, then: a. How do you know which NTP sources to trust? b. How do you set up authentication with them? Public NTP is unauthenticated, and if I remember correctly it's not *possible* to authenticate NTP in a public network. The public-key stuff is used to distribute shared keys. I could be wrong; it's been a while. But that's how I remember it. Anyway, you'd need some kind of NTP trust anchor... which puts us back where we started. 3. GPS? WWVB (or non-US equivalent)? Can't receive either one where my router is, even if it had the hardware. And both are jammable. WWVB, at least, is easily falsified, as are the similar but incompatible systems in use in various places outside North America... those where such systems exists, that is. I haven't looked into GPS, but I suspect= it's spoofable too. 4. Make the user enter the time? How does the user know she needs to do that? For us, another question is how we keep the user from buying the competitor's box that doesn't do DNSSEC and doesn't ask for the time. Users see all this stuff as a hassle. I was told today that even entering a PIN to get WiFi up causes a noticeable number of products to go back to the store. The state of the art in enterprise networks is *unauthenticated* NTP with internal hosts. The state of the art in consumer is unauthenticated NTP with a pool on the public Internet. This is a huge problem for us with bootstrapping all kinds of crypto protocols, actually, not just DNSSEC. There's this pervasive assumption that the time of day is not only known, but known with such certainty that it can be trusted to ensure the security of systems that are otherwise engineered to take CPU-aeons to compromise. The problem is that it's just not an assumption we know how to meet. In a lot of cases, we just end up having to assume that keys are valid from the beginning of time to the end of time. I'd very much like to not have that be true, but I don't know how to fix it. I could imagine a distributed system of digital notaries and time stampers that at least let you establish that it was "no earlier than" some particular time, and that also gave you some assurance that some set of past events had happened in a particular sequence and within particular time parameters. You could build that with mutually distrustful "authorities", and use a quorum or something to prevent any one of them from messing it up. I think that sort of thing is (part of) what Phillip Hallam-Baker is getting at. But I'm not sure we can deploy it sanely in time to be useful for this application... and I don't think you can build *anything* that lets you detect lies about the time if an attacker controls *all* your communications. Trust =3D=3D=3D=3D=3D I'm not sure I understand the phrase "trust anchor" the same way you do. > 5.1 Retrieval of Trust Anchors from Local Sources > > A trust anchor which is packaged with validator software can never be > trusted, [...] >=20 > Validators should never use local trust anchors for bootstrapping. I think that by "trust anchor" here, you really mean "DNSSEC root KSK", because below you say: > 5.3 Retrieval of Trust Anchors from the Root Zone KSK Manager > [...] > > 3. Retrieve the corresponding X.509 identity certificates for the > key identified in the previous step, for use in establishing > trust in the retrieved trust anchor (see Section 6). > [...] > 6. Establishing Trust in Candidate Trust Anchors >=20 > Once a candidate trust anchor has been retrieved, the validator must > establish that it is authentic before it can be used. This document > recommends that this be carried out by checking the signatures on > each of the X.509 identity certificates retrieved in the previous > step until a certificate is found which matches a CA trust anchor > > This verification phase requires that validators ship with a useful > set of CA trust anchors, and that corresponding identity certificates > are published by the root zone KSK manager. Either way, it's a local trust anchor... and I don't see why X.509 keys are any less compromisable than DNS keys... -- jbash --------------enig5C1D5D75B6338C2F3D4FA8AB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1HLTEACgkQQXYiJfd/JbbMnACdHURmjpvQrv2MZaSQo6SSZ4EB DtUAniYyRTMADcGmgqViP7uXR3THXKOe =bpcw -----END PGP SIGNATURE----- --------------enig5C1D5D75B6338C2F3D4FA8AB-- From jabley@hopcount.ca Mon Jan 31 14:11:36 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4161B3A6C78; Mon, 31 Jan 2011 14:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlqpM1PxG1oK; Mon, 31 Jan 2011 14:11:34 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id CDCC53A67F7; Mon, 31 Jan 2011 14:11:32 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pk25O-000FQ9-8P; Mon, 31 Jan 2011 22:19:03 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <4D472D2C.9090108@cisco.com> Date: Mon, 31 Jan 2011 17:14:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> To: John Bashinski X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: "dnsop@ietf.org WG" , dnsext List , Knight Dave Subject: Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 22:11:36 -0000 [we should probably choose either dnsop or dnsext for this, and stop = posting to both, sorry for starting that trend] On 2011-01-31, at 16:44, John Bashinski wrote: > On 2011-01-31 14:32, Joe Abley wrote: >=20 >> Individual trust anchors are also packaged as X.509 identity >> certificates, signed by various Certificate Authorities (CAs). >=20 > How firmly are you attached to your approach? Would you be prepared to > consider supporting alternatives, if consensus could be gathered = behind > them? Publishing the trust anchor as a CSR and subsequently signing that to = produce a certificate is part of the existing workflow for KSK = ceremonies, and changing it will not happen quickly. Change is certainly = possible, however. My hope with this document was to present it in Prague, and suggest that = the (a) working group adopt it. I think the general subject area needs = work, and I think a working group is likely to do a better job than a = pair of individuals. I don't think anybody is married to any particular approach. > Prodedural details > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I assume you *are* saying that the >=20 > http://data.iana.org/root-anchors/root-anchors.xml >=20 > URL is guaranteed good for a long time? It's specified in the KSK manager's DNSSEC Practice Statement, and the = IANA people at ICANN are happy to support it for as long as we manage = the key. > I'm not sure what procedure we're meant to use to get the validated = CSRs > to create the X.509 certificates for new KSKs. Can you say anything > about that? We (IANA, again) expect to find a workflow that suits the CA in = question. If that means that IANA staff provide attestations and a copy = of the CSR in a tamper-evident bag with corresponding documentation for = a chain of custody, we can do that. > I assume that the "ultimate" way to do it is to send some people to a > key ceremony. To be honest, I'm not sure that I could convince > management (or even myself) that that gave enough extra assurance to = be > worth it. I suspect what we'd end up doing, absent other guidance, > would be just grabbing the CSR from wherever, and looking at the root > KSK in use on our own internal systems to see if it was right... then > signing it. The participants who attended the first ceremony were able to witness = the generation of the key and the corresponding hash on a screen = connected directly to the ceremony laptop. Subsequent ceremonies have = principally been concerned with processing the set of key material = supplied by VeriSign for the next quarter, and have not involved key = generation. > Some comments on the draft itself: >=20 > Finding CAs > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > You say: >=20 >> URLs >> to allow those certificates to be retrieved are included as optional >> elements in the XML document. >=20 > I don't actually see any CA URLs in the XML at the moment. Right, this is something that occurred to me as we were discussing the = bootstrap problem. I have a rev to the trust anchor document ready to go = that includes those optional elements. > Obviously you can't just grab a root cert from such a URL and trust > it, anyway... you have to have either a wired-in copy of the cert > itself, or at least a wired-in copy of its public key. So I'm > not sure I see what having the URLs in the XML would do for anybody. The certificates you pull from those URLs would be of the form http://data.iana.org/root-anchors/Kxxxxxx.crt (the current name for the certificate produced using the IANA CA) http://data.iana.org/root-anchors/Kxxxxxx.crt.cisco (if that's the kind of thing cisco decided to do) http://data.iana.org/root-anchors/Kxxxxxx.crt.some-commercial-CA (and so on) The idea of inserting optional elements into the XML schema was to allow = a device parsing root-anchors.xml to enumerate a list of URLs for = candidate certificates. Whether or not you decided to trust that certificate would depend on = whether you had shipped with an appropriate CA trust anchor (e.g. the = IANA one, or a cisco one, or the some-commercial-CA one). >> alternatively a vendor may instantiate its own CA and make >> arrangements with the root zone KSK manager to have the corresponding >> identity certificate locations published in root-anchors.xml. >=20 > Our devices already have copies of our own CA's root cert for other > reasons, so we'd just let them rely on that. I'd assume others would > do similarly. Then perhaps this scheme is not as unwieldy for cisco as it might first = have seemed -- if that cisco CA key can be exercised to process the CSR = containing the root zone KSK public key, and we can publish that in a = reasonable place, the extra process involved might be fairly small. > Time > =3D=3D=3D=3D >=20 >> 3.1 Initial State >> [...] >> A validator must confirm that its local clock is sufficiently >> accurate before trust anchors can be established, and before >> processing of DNSSEC signatures can proceed. Discussion of timing >> considerations can be found in Section 4. >=20 > How? Good question. The fact that the answer is not obvious doesn't eliminate = the requirement to set the local clock, though. > Trust > =3D=3D=3D=3D=3D > I'm not sure I understand the phrase "trust anchor" the same way you > do. >=20 >> 5.1 Retrieval of Trust Anchors from Local Sources >>=20 >> A trust anchor which is packaged with validator software can never be >> trusted, [...] >>=20 >> Validators should never use local trust anchors for bootstrapping. >=20 > I think that by "trust anchor" here, you really mean "DNSSEC root > KSK", because below you say: Yes, I mean a copy of the root zone KSK public key, or a hash of it. > Either way, it's a local trust anchor... and I don't see why X.509 > keys are any less compromisable than DNS keys... The difference is that X.509 keys, as deployed by CAs, have expected = lifetimes measured in decades. Right now we don't know what the expected = lifetime of the root zone KSK is. Joe= From hallam@gmail.com Mon Jan 31 15:33:37 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB90B3A6C26 for ; Mon, 31 Jan 2011 15:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NWIf6Azq5mz for ; Mon, 31 Jan 2011 15:33:36 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 7C8683A6B88 for ; Mon, 31 Jan 2011 15:33:36 -0800 (PST) Received: by ywk9 with SMTP id 9so2555600ywk.31 for ; Mon, 31 Jan 2011 15:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VTKj7i1mV4HdhpEMQEgrlVO4/sBpRbX3RdT6FXRzm64=; b=dbXydzvDNZ0t/4aTNrj7OmsWJSUNy4uOevuOAlvzX5tLKo7+nVValtLEb0Z3xkFAP7 lGeW58wfMtz1cteFqQfm6EhTF/OdbfdEnr7VTV0LpL8vTPUUc/14LlIbMIGam85GF6He iQwsQnutYaY+6gPFcFzcl7RTtXZwl931hXlWs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RIDnZywGoDBaNcKbp2Nsls3EkbzkCOQFVUCdQOyk2Ohh69YbbfRVoIiC7UvdVZTtUx WKdV+mx1pRyGs+adGVNd6IOFKToranbgdwwHqijHF3c+/2eU1VGBBJ4vN5kTID//187j pwmtncF5hpuGV02I8QX8R/hm5aw9UIvQUMmac= MIME-Version: 1.0 Received: by 10.100.34.1 with SMTP id h1mr4416843anh.188.1296517010991; Mon, 31 Jan 2011 15:36:50 -0800 (PST) Received: by 10.100.109.16 with HTTP; Mon, 31 Jan 2011 15:36:50 -0800 (PST) In-Reply-To: <63AEECED-2D62-4FC4-81C8-87464D37A72E@hopcount.ca> References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> <899F4D8E-2E75-44C3-A001-612582209C86@icsi.berkeley.edu> <63AEECED-2D62-4FC4-81C8-87464D37A72E@hopcount.ca> Date: Mon, 31 Jan 2011 18:36:50 -0500 Message-ID: From: Phillip Hallam-Baker To: Joe Abley Content-Type: multipart/alternative; boundary=0016e6465220e2ac1e049b2ce3b8 Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 23:33:38 -0000 --0016e6465220e2ac1e049b2ce3b8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 31, 2011 at 3:02 PM, Joe Abley wrote: > > On 2011-01-31, at 14:31, Nicholas Weaver wrote: > > > If we have either an algorithm or KSK key compromise, we have a far > bigger problem and going to a more human-centric route is probably doable. > > The problem space we're considering is that of embedded devices (think > 5,000,000 deployed linksys home gateways) for which a human-centric path is > effectively not an option. No? > > > ESPECIALLY if a failure for the TALINK-like mechanism (which fails for > compromise-cases) is 'do leap of faith for the root for NON-secure records', > so even then the name lookups etc will still work, only cryptographic trust > mechanisms built on top of DNSSEC would fail. > > The problem with the TALINK and similar trust-chaining proposals is that in > the cases where you really need them, they can't work. > > I don't think the scheme I just posted (and have described here before) is > particularly elegant, but it has the benefit that it's immediately > deployable and doesn't introduce any trust points into the system that > aren't already there. It does not add any trust points and it does not add any stability either. All you are doing is sticking another turtle underneath the pile. If you want to make a difference then you have to either decide that this is an acceptable risk and you are not going to deal with it or you have to think about something that isn't a turtle. -- Website: http://hallambaker.com/ --0016e6465220e2ac1e049b2ce3b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 31, 2011 at 3:02 PM, Joe Abl= ey <jabley@hopco= unt.ca> wrote:

On 2011-01-31, at 14:31, Nicholas Weaver wrote:

> If we have either an algorithm or KSK key compromise, we have a far bi= gger problem and going to a more human-centric route is probably doable.
The problem space we're considering is that of embedded devices (= think 5,000,000 deployed linksys home gateways) for which a human-centric p= ath is effectively not an option. No?

> ESPECIALLY if a failure for the TALINK-like mechanism (which fails for= compromise-cases) is 'do leap of faith for the root for NON-secure rec= ords', so even then the name lookups etc will still work, only cryptogr= aphic trust mechanisms built on top of DNSSEC would fail.

The problem with the TALINK and similar trust-chaining proposals is t= hat in the cases where you really need them, they can't work.

I don't think the scheme I just posted (and have described here before)= is particularly elegant, but it has the benefit that it's immediately = deployable and doesn't introduce any trust points into the system that = aren't already there.


It does not add any trust points and it = does not add any stability either.

All you are doi= ng is sticking another turtle underneath the pile. If you want to make a di= fference then you have to either decide that this is an acceptable risk and= you are not going to deal with it or you have to think about something tha= t isn't a turtle.

=A0


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

--0016e6465220e2ac1e049b2ce3b8-- From jabley@hopcount.ca Mon Jan 31 15:52:33 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E99D3A6C95 for ; Mon, 31 Jan 2011 15:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1unioMoNRLdu for ; Mon, 31 Jan 2011 15:52:32 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 2A38C3A68B1 for ; Mon, 31 Jan 2011 15:52:30 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pk3f2-000IhG-OQ; Tue, 01 Feb 2011 00:00:01 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: Date: Mon, 31 Jan 2011 18:55:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <09DC661D-5974-44A4-BF58-E5152945B60B@hopcount.ca> References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> <899F4D8E-2E75-44C3-A001-612582209C86@icsi.berkeley.edu> <63AEECED-2D62-4FC4-81C8-87464D37A72E@hopcount.ca> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 23:52:33 -0000 On 2011-01-31, at 18:36, Phillip Hallam-Baker wrote: > It does not add any trust points and it does not add any stability = either. I'm not sure what you mean by that... > All you are doing is sticking another turtle underneath the pile. If = you want to make a difference then you have to either decide that this = is an acceptable risk and you are not going to deal with it or you have = to think about something that isn't a turtle. ... or by any of that, to be honest. Perhaps you could rephrase? Joe From hallam@gmail.com Mon Jan 31 16:37:22 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516133A6CA0; Mon, 31 Jan 2011 16:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YBdIWvMSYj6; Mon, 31 Jan 2011 16:37:21 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 046D93A6C97; Mon, 31 Jan 2011 16:37:20 -0800 (PST) Received: by yxt33 with SMTP id 33so2574172yxt.31 for ; Mon, 31 Jan 2011 16:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=A5kVdQ+FkrqJPw6YPmcJr6TRCBPBn32ZtVwMCxs9VVA=; b=eG2Os0Rj7RTkU8Q3TA1lOc6+ix1VeLRJwqgRnAQm/GAiAY0lcbJRBBoEeC4r62RnoE MCdr4U9kr9jPxA68HEnXpNqBBCoFFRG5x4gzJZeY0rN4gHszhIn4JS2Ai4tNWoYoN+CS elqywC3T8b0HVudTXoxvA3o+WD+29ZIpYVcAw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bbkRGOyquEq2ckHyJnjvvKkgH1cT/ztITRYR0t2pfPNWcyQJ5U0Ck7g+Ux5ICbffWw wU7D86HYewgMtvuldysi/0OA/Zsthsxex8M5hZOFQGCjNgrN2Kb7lHWP+VHMmQgLICB7 yZhWfJ78JuLQ1ZdjTX2GBtq1qce1RGOrEyf1s= MIME-Version: 1.0 Received: by 10.100.6.7 with SMTP id 7mr4332571anf.256.1296520835864; Mon, 31 Jan 2011 16:40:35 -0800 (PST) Received: by 10.100.109.16 with HTTP; Mon, 31 Jan 2011 16:40:35 -0800 (PST) In-Reply-To: <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> Date: Mon, 31 Jan 2011 19:40:35 -0500 Message-ID: From: Phillip Hallam-Baker To: Joe Abley Content-Type: multipart/alternative; boundary=0016e642d3badd99a6049b2dc72a Cc: "dnsop@ietf.org WG" , Knight Dave , dnsext List Subject: Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 00:37:22 -0000 --0016e642d3badd99a6049b2dc72a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 31, 2011 at 5:14 PM, Joe Abley wrote: > > > Either way, it's a local trust anchor... and I don't see why X.509 > > keys are any less compromisable than DNS keys... > > The difference is that X.509 keys, as deployed by CAs, have expected > lifetimes measured in decades. Right now we don't know what the expected > lifetime of the root zone KSK is. > To be precise here, there is no difference in the likelihood that the keys will be compromised. The difference is that the X.509 protocol is designed to support keys that are persistent over long periods (decades) and DNSSEC is not. In particular an X.509 self-signed certificate is an assertion that the key holder will maintain and use the associated private key in accordance with the specified practices for the specified length of time. You can easily find out how long Comodo or Symantec or whoever is going to maintain their SSL CA roots, the information is right there in the cert store and is irrevocable in that the CA can extend the time period (through recertification) but cannot reduce it. My advice to Cisco would be to use their existing root to sign the published CSR for the DNS root KSK in the short term at least. In the longer term we are going to have to have a look at the problem at a higher level and work out how we are going to solve it in a scalable way across all the platforms that involve a root key. We are starting to make quite a little collection of industry forums that are doing this root key management as a sideline. -- Website: http://hallambaker.com/ --0016e642d3badd99a6049b2dc72a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 31, 2011 at 5:14 PM, Joe Abl= ey <jabley@hopco= unt.ca> wrote:

> Either way, it's a local trust anchor... and I don't see why X= .509
> keys are any less compromisable than DNS keys...

The difference is that X.509 keys, as deployed by CAs, have expected = lifetimes measured in decades. Right now we don't know what the expecte= d lifetime of the root zone KSK is.

To be precise here, there is no difference in the likelihood that the keys = will be compromised.

The difference is that the X.= 509 protocol is designed to support keys that are persistent over long peri= ods (decades) and DNSSEC is not.

In particular an X.509 self-signed certificate is an as= sertion that the key holder will maintain and use the associated private ke= y in accordance with the specified practices for the specified length of ti= me.=A0

You can easily find out how long Comodo or Symantec or = whoever is going to maintain their SSL CA roots, the information is right t= here in the cert store and is irrevocable in that the CA can extend the tim= e period (through recertification) but cannot reduce it.


My advice to Cisco would be=A0to use the= ir existing root to sign the published CSR for the DNS root KSK in the shor= t term at least.
=A0
In the longer term we are going to= have to have a look at the problem at a higher level and work out how we a= re going to solve it in a scalable way across all the platforms that involv= e a root key.

We are starting to make quite a little collection of in= dustry forums that are doing this root key management as a sideline.=A0

--
Website: http://hall= ambaker.com/

--0016e642d3badd99a6049b2dc72a-- From paul.hoffman@vpnc.org Mon Jan 31 17:45:59 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74003A6CB3 for ; Mon, 31 Jan 2011 17:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-ZyhAEUtk7P for ; Mon, 31 Jan 2011 17:45:59 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 0A19C3A6CAD for ; Mon, 31 Jan 2011 17:45:58 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p111nD63090730 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 31 Jan 2011 18:49:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D476699.5060105@vpnc.org> Date: Mon, 31 Jan 2011 17:49:13 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dnsext@ietf.org References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 01:45:59 -0000 On 1/31/11 4:40 PM, Phillip Hallam-Baker wrote: > To be precise here, there is no difference in the likelihood that the > keys will be compromised. Quite right. > The difference is that the X.509 protocol is designed to support keys > that are persistent over long periods (decades) and DNSSEC is not. Poppycock. Both PKIX and DNSSEC are agnostic on how long the keys are meant to last. Pretending that PKIX has some advantage here is nonsense. > In particular an X.509 self-signed certificate is an assertion that the > key holder will maintain and use the associated private key in > accordance with the specified practices for the specified length of time. Bosh. If you are talking about the "notAfter" field, it is defined as the end of "the time interval during which the CA warrants that it will maintain information about the status of the certificate"; that is quite different than "maintain and use". If you are speaking of something else, please quote from the PKIX spec. > You can easily find out how long Comodo or Symantec or whoever is going > to maintain their SSL CA roots, the information is right there in the > cert store and is irrevocable in that the CA can extend the time period > (through recertification) but cannot reduce it. Balderdash. When I look in Comodo's certificate in my "cert store", I don't see anything about how long you are going to maintain your SSL CA root. I see something that says you will maintain *information about the status* of the certificate; note the difference. As for "irrevocable", that's just silly: Comodo can revoke it at any time. There is no contract here. > My advice to Cisco would be to use their existing root to sign the > published CSR for the DNS root KSK in the short term at least. Signing is the easy part: making their systems use that signed key is much more difficult. That difficulty is what started this thread; handwaving it away won't help Cisco or anyone. > In the longer term we are going to have to have a look at the problem at > a higher level and work out how we are going to solve it in a scalable > way across all the platforms that involve a root key. > > We are starting to make quite a little collection of industry forums > that are doing this root key management as a sideline. Now everyone can rest assured: industry forums to the rescue! From hallam@gmail.com Mon Jan 31 18:20:32 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE9E3A6B33 for ; Mon, 31 Jan 2011 18:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsPQUg3B6CGR for ; Mon, 31 Jan 2011 18:20:31 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id D36F23A68EA for ; Mon, 31 Jan 2011 18:20:30 -0800 (PST) Received: by ywk9 with SMTP id 9so2610232ywk.31 for ; Mon, 31 Jan 2011 18:23:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tZj2myGUenb8wERMX+kugQOhs4uinVHd0aGKORAP8vo=; b=WvOsL+KiwmxfBRK/9Yu7AjGIoIIYuP/CT/Gj58qVN0AoqTK/qsbTX5J2WFpRzGnSbq 4LoMCGNSKuZoNS3cSroINP9kQsk5LQwrc78Hv+LPlAuz1FACg0fUb8nEJsVDTARbhumM ZWm/D8EZGIugkozXU2PUnWj3FbTImnOW8tLvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uVpuyzCR69pJ7QtAQDVopx1Q+PaU8f6uodWGo3YSrZAjFE1Eg5A4hTp7spW5xJMIp0 9sy65+mxxxATJhOfshKEI5F8Aia2L0oLbgfFQuIAcvCpCG90vxM0f1zyNr0ewyhmiS5w uJZUWElSI5W0Ht0GAR3/3NzG0fz14VNiGevuc= MIME-Version: 1.0 Received: by 10.100.34.1 with SMTP id h1mr4528636anh.188.1296527026139; Mon, 31 Jan 2011 18:23:46 -0800 (PST) Received: by 10.100.109.16 with HTTP; Mon, 31 Jan 2011 18:23:45 -0800 (PST) In-Reply-To: <09DC661D-5974-44A4-BF58-E5152945B60B@hopcount.ca> References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> <899F4D8E-2E75-44C3-A001-612582209C86@icsi.berkeley.edu> <63AEECED-2D62-4FC4-81C8-87464D37A72E@hopcount.ca> <09DC661D-5974-44A4-BF58-E5152945B60B@hopcount.ca> Date: Mon, 31 Jan 2011 21:23:45 -0500 Message-ID: From: Phillip Hallam-Baker To: Joe Abley Content-Type: multipart/alternative; boundary=0016e6465220d5b57b049b2f3896 Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 02:20:32 -0000 --0016e6465220d5b57b049b2f3896 Content-Type: text/plain; charset=ISO-8859-1 The original reference was to a possibly apocryphal tale told by Bertrand Russell in his autobiography describing the nature of infinity. http://en.wikipedia.org/wiki/Turtles_all_the_way_down Regularly rolling the root does not improve security. All that is achieved is that one point of vulnerability becomes two points until such time as the original root is no longer trusted for ANY purpose. If you change the management rules to require a permanent chain of roots to be kept you have precisely the same exposure to the legacy root plus the additional exposure incurred through establishing a second root and the distribution mechanism. Without wanting to put too fine a point on the matter, the only way you are going to be able to rely on an ICANN issued root key in twenty years time is if ICANN decides that this is something that they are going to support. And if they did decide to offer such support there are much simpler ways to do so than the draft proposed. On Mon, Jan 31, 2011 at 6:55 PM, Joe Abley wrote: > > On 2011-01-31, at 18:36, Phillip Hallam-Baker wrote: > > > It does not add any trust points and it does not add any stability > either. > > I'm not sure what you mean by that... > > > All you are doing is sticking another turtle underneath the pile. If you > want to make a difference then you have to either decide that this is an > acceptable risk and you are not going to deal with it or you have to think > about something that isn't a turtle. > > ... or by any of that, to be honest. Perhaps you could rephrase? > > > Joe > > -- Website: http://hallambaker.com/ --0016e6465220d5b57b049b2f3896 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The original reference was to a possibly apocryphal tale told by Bertr= and Russell in his autobiography describing the nature of infinity.



Regularly rolling the root does not improve s= ecurity. All that is achieved is that one point of vulnerability becomes tw= o points until such time as the original root is no longer trusted for ANY = purpose.

If you change the management rules to require a permanent ch= ain of roots to be kept you have precisely the same exposure to the legacy = root plus the additional exposure incurred through establishing a second ro= ot and the distribution mechanism.


Without wanting to put too fine a point = on the matter, the only way you are going to be able to rely on an ICANN is= sued root key in twenty years time is if ICANN decides that this is somethi= ng that they are going to support. And if they did decide to offer such sup= port there are much simpler ways to do so than the draft proposed.




= On Mon, Jan 31, 2011 at 6:55 PM, Joe Abley <jabley@hopcount.ca> wrote:

On 2011-01-31, at 18:36, Phillip Hallam-Baker wrote:

> It does not add any trust points and it does not add any stability eit= her.

I'm not sure what you mean by that...

> All you are doing is sticking another turtle underneath the pile. If y= ou want to make a difference then you have to either decide that this is an= acceptable risk and you are not going to deal with it or you have to think= about something that isn't a turtle.

... or by any of that, to be honest. Perhaps you could rephrase?


Joe




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

--0016e6465220d5b57b049b2f3896-- From jabley@hopcount.ca Mon Jan 31 18:39:03 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B473A6CBD for ; Mon, 31 Jan 2011 18:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmQK3Kc2NSh8 for ; Mon, 31 Jan 2011 18:39:03 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id D9A2C3A68F1 for ; Mon, 31 Jan 2011 18:39:02 -0800 (PST) Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pk6GC-000OGv-EK; Tue, 01 Feb 2011 02:46:33 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: Date: Mon, 31 Jan 2011 21:42:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> <899F4D8E-2E75-44C3-A001-612582209C86@icsi.berkeley.edu> <63AEECED-2D62-4FC4-81C8-87464D37A72E@hopcount.ca> <09DC661D-5974-44A4-BF58-E5152945B60B@hopcount.ca> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 02:39:03 -0000 On 2011-01-31, at 21:23, Phillip Hallam-Baker wrote: > Regularly rolling the root does not improve security. All that is = achieved is that one point of vulnerability becomes two points until = such time as the original root is no longer trusted for ANY purpose. The draft I submitted doesn't address scheduled key rolls. Rather, it = addresses the problem of how a validator establishes an initial trust = anchor to be used for continuing operation. I appreciate the distinction is muddied by the fact that a validator = that fails to catch a key roll with 5011 semantics is effectively left = in a state where it needs to bootstrap itself again. > If you change the management rules to require a permanent chain of = roots to be kept you have precisely the same exposure to the legacy root = plus the additional exposure incurred through establishing a second root = and the distribution mechanism. Indeed. The proposal I posted doesn't establish a second root; it uses = established ones. > Without wanting to put too fine a point on the matter, the only way = you are going to be able to rely on an ICANN issued root key in twenty = years time is if ICANN decides that this is something that they are = going to support. And if they did decide to offer such support there are = much simpler ways to do so than the draft proposed. ICANN has committed to support the current publication mechanisms for as = long as they retain the role of KSK manager; it's in the IANA functions = contract with NTIA (by reference). I think we can assume that the same = requirement would be imposed on any new NTIA contractor in the event = that some other organisation took over the role. What support could ICANN provide that would facilitate a simpler = bootstrapping method? (The proposal Dave and I posted seemed pretty simple to me: you pull an = XML document using HTTP, then the certificates referred to by that XML = doc and use one of the X.509 CA keys you already have to verify any one = of them. Until you find a suitable cert, you operate without DNSSEC.) Joe= From paul@xelerance.com Mon Jan 31 19:19:39 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA053A6833 for ; Mon, 31 Jan 2011 19:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dw3YbR-BluR for ; Mon, 31 Jan 2011 19:19:38 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id A7E863A67D3 for ; Mon, 31 Jan 2011 19:19:38 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id EC3D4C4FE; Mon, 31 Jan 2011 22:22:52 -0500 (EST) Date: Mon, 31 Jan 2011 22:22:52 -0500 (EST) From: Paul Wouters To: Joe Abley In-Reply-To: Message-ID: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> <899F4D8E-2E75-44C3-A001-612582209C86@icsi.berkeley.edu> <63AEECED-2D62-4FC4-81C8-87464D37A72E@hopcount.ca> <09DC661D-5974-44A4-BF58-E5152945B60B@hopcount.ca> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dnsext@ietf.org Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 03:19:39 -0000 On Mon, 31 Jan 2011, Joe Abley wrote: > The proposal I posted doesn't establish a second root; it uses established ones I do agree you are not only adding a second root. You are potentially adding many roots by requiring one or more PKIX Certificate Agencies. > (The proposal Dave and I posted seemed pretty simple to me: you pull an XML document using HTTP, then the certificates referred to by that XML doc and use one of the X.509 CA keys you already have to verify any one of them. Until you find a suitable cert, you operate without DNSSEC.) This of course, mixes two different trust anchor schemes. DNSSEC should not depend on PKIX. TALINK on the other end, does not depend on PKIX. Paul From hallam@gmail.com Mon Jan 31 20:21:51 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18813A6907 for ; Mon, 31 Jan 2011 20:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0InrpKJlFLGr for ; Mon, 31 Jan 2011 20:21:50 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 2E2AF3A6833 for ; Mon, 31 Jan 2011 20:21:50 -0800 (PST) Received: by gxk27 with SMTP id 27so2665863gxk.31 for ; Mon, 31 Jan 2011 20:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sJSs6GchoZuQe0Tv7OSTKzLt9u/20wSvX4douHe+xWE=; b=E/qfjoh3whBHbpMMC1D91c6SFE2b70B0F8hvx+pv7RWY94as4hpctfj86Pnn2Kohxb mGX5Uv5jk2QmtFVgGZHkIkeSi5oLB9Q96zP/Xo+H+kvK/tHUfpWgjDQQMvgV6NZdUewB NG2VzqOGR1qc7tzQ2b4RcJqrVJnFqQDTZvn6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sYYgtgTe2MEAWgQ7JFToRiUwXVIYohnXxOKQWcsRuvKzyS3tzqxKx9/WTnY8tXkr8y Rsoa5d5rPBgLQBCf+Ogk+oOINcAWhUknOxilq/WfDurl93oYQ+DdJQ55eqY9Frg+EEck +C0HZAL6HRxhJbE6WW4SKlOAJbIf4vWnavTV8= MIME-Version: 1.0 Received: by 10.100.8.9 with SMTP id 9mr4536200anh.120.1296534304499; Mon, 31 Jan 2011 20:25:04 -0800 (PST) Received: by 10.100.109.16 with HTTP; Mon, 31 Jan 2011 20:25:04 -0800 (PST) In-Reply-To: <4D476699.5060105@vpnc.org> References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <4D476699.5060105@vpnc.org> Date: Mon, 31 Jan 2011 23:25:04 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e6441dd8a8a809049b30ea63 Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 04:21:51 -0000 --0016e6441dd8a8a809049b30ea63 Content-Type: text/plain; charset=ISO-8859-1 I was going to reply to this post, then I read it and saw that you cannot converse in a civil fashion. On Mon, Jan 31, 2011 at 8:49 PM, Paul Hoffman wrote: > On 1/31/11 4:40 PM, Phillip Hallam-Baker wrote: > >> To be precise here, there is no difference in the likelihood that the >> keys will be compromised. >> > > Quite right. > > > The difference is that the X.509 protocol is designed to support keys >> that are persistent over long periods (decades) and DNSSEC is not. >> > > Poppycock. Both PKIX and DNSSEC are agnostic on how long the keys are meant > to last. Pretending that PKIX has some advantage here is nonsense. > > > In particular an X.509 self-signed certificate is an assertion that the >> key holder will maintain and use the associated private key in >> accordance with the specified practices for the specified length of time. >> > > Bosh. If you are talking about the "notAfter" field, it is defined as the > end of "the time interval during which the CA warrants that it will maintain > information about the status of the certificate"; that is quite different > than "maintain and use". If you are speaking of something else, please quote > from the PKIX spec. > > > You can easily find out how long Comodo or Symantec or whoever is going >> to maintain their SSL CA roots, the information is right there in the >> cert store and is irrevocable in that the CA can extend the time period >> (through recertification) but cannot reduce it. >> > > Balderdash. When I look in Comodo's certificate in my "cert store", I don't > see anything about how long you are going to maintain your SSL CA root. I > see something that says you will maintain *information about the status* of > the certificate; note the difference. As for "irrevocable", that's just > silly: Comodo can revoke it at any time. There is no contract here. > > > My advice to Cisco would be to use their existing root to sign the >> published CSR for the DNS root KSK in the short term at least. >> > > Signing is the easy part: making their systems use that signed key is much > more difficult. That difficulty is what started this thread; handwaving it > away won't help Cisco or anyone. > > > In the longer term we are going to have to have a look at the problem at >> a higher level and work out how we are going to solve it in a scalable >> way across all the platforms that involve a root key. >> >> We are starting to make quite a little collection of industry forums >> that are doing this root key management as a sideline. >> > > Now everyone can rest assured: industry forums to the rescue! > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --0016e6441dd8a8a809049b30ea63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I was going to reply to this post, then I read it and saw that you cannot c= onverse in a civil fashion.



On Mon, Jan 31, 2011 at 8:49 PM, Paul Hoffman <= paul.hoffman@vpnc.org> wrote:
On 1/31/11 4:40 PM, Phill= ip Hallam-Baker wrote:
To be precise here, there is no difference in the likelihood that the
keys will be compromised.

Quite right.


The difference is that the X.509 protocol is designed to support keys
that are persistent over long periods (decades) and DNSSEC is not.

Poppycock. Both PKIX and DNSSEC are agnostic on how long the keys are meant= to last. Pretending that PKIX has some advantage here is nonsense.


In particular an X.509 self-signed certificate is an assertion that the
key holder will maintain and use the associated private key in
accordance with the specified practices for the specified length of time.

Bosh. If you are talking about the "notAfter" field, it is define= d as the end of "the time interval during which the CA warrants that i= t will maintain information about the status of the certificate"; that= is quite different than "maintain and use". If you are speaking = of something else, please quote from the PKIX spec.


You can easily find out how long Comodo or Symantec or whoever is going
to maintain their SSL CA roots, the information is right there in the
cert store and is irrevocable in that the CA can extend the time period
(through recertification) but cannot reduce it.

Balderdash. When I look in Comodo's certificate in my "cert store&= quot;, I don't see anything about how long you are going to maintain yo= ur SSL CA root. I see something that says you will maintain *information ab= out the status* of the certificate; note the difference. As for "irrev= ocable", that's just silly: Comodo can revoke it at any time. Ther= e is no contract here.


My advice to Cisco would be to use their existing root to sign the
published CSR for the DNS root KSK in the short term at least.

Signing is the easy part: making their systems use that signed key is much = more difficult. That difficulty is what started this thread; handwaving it = away won't help Cisco or anyone.


In the longer term we are going to have to have a look at the problem at a higher level and work out how we are going to solve it in a scalable
way across all the platforms that involve a root key.

We are starting to make quite a little collection of industry forums
that are doing this root key management as a sideline.

Now everyone can rest assured: industry forums to the rescue!

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



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

--0016e6441dd8a8a809049b30ea63-- From brian.peter.dickson@gmail.com Mon Jan 31 20:58:55 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27F53A6B60 for ; Mon, 31 Jan 2011 20:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfuxUn9WNNxq for ; Mon, 31 Jan 2011 20:58:54 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 6E8673A6B5D for ; Mon, 31 Jan 2011 20:58:54 -0800 (PST) Received: by fxm9 with SMTP id 9so6994747fxm.31 for ; Mon, 31 Jan 2011 21:02:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BbGVCJb5qXw56u5DEJIMWFOhb1FdJq+p/9Fkt63+6EI=; b=wxxMjchjr+SXRBlcUwBuNxnjX+GQLQa5zunEAGHDsEtOMs6PeO1L4PZtfv5FDRvSvY DKT7P7Hbs5ZuxmZLG9QSNHDcccdql5t9fPwta2FBJAjRb9xTm36Mjx02CB/rzFIFMyYB 8R4bU3PmdL46WVWJoAlM1toTmFECBMBOSGD70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vFKU15D7NBqcYKzeZl6mtII/gGyT9fGzCM1JBC3wOdI2GamamGKTZwDxCObsBZweuc z46we2KMe2rt3S9JHmq2io9x1XYUJqS565BJMt8QnAIY89iQ5B2DmbLN+9u8v2kif/Vg scEwVDND8C8InnzhfCR+ECpKHGnx1UYw5cb2I= MIME-Version: 1.0 Received: by 10.223.83.11 with SMTP id d11mr6908257fal.37.1296536529731; Mon, 31 Jan 2011 21:02:09 -0800 (PST) Received: by 10.223.108.71 with HTTP; Mon, 31 Jan 2011 21:02:09 -0800 (PST) In-Reply-To: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> Date: Tue, 1 Feb 2011 01:02:09 -0400 Message-ID: From: Brian Dickson To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 04:58:55 -0000 On Mon, Jan 31, 2011 at 3:23 PM, Phillip Hallam-Baker wrote: > > On Mon, Jan 31, 2011 at 1:22 PM, Brian Dickson > wrote: >> The simplest bootstrap method would be to have a series of BSK >> (bootstrap keys), created on a periodic basis (every N years), and >> used as follows: > > If a compromise has occurred then the first thing to ask would be why. > There are only three places where a compromise can logically occur - in the > cryptographic algorithm, in the cryptographic hardware manufacturer or in > ICANN, > If its the algorithm then the whole series of BSKs is compromised. I think it is helpful to use as explicit a form of language as necessary, to clearly communicate ideas. So, when I ask you to clarify this into particulars, it is with the intent of understanding what you meant. "If a compromise has occurred" - a compromise of what, exactly, are you talking about? It could be that there has been a theoretical weakness in the algorithm, which makes it slightly more feasible to break, but that the root zone key's private parts have not been exposed. In which case, this is "theoretically weak". On the other hand, it could be that the root zone key has had its private parts found, in which case the term "compromised" has the very real, concrete meaning in that someone has directly compromised its security. In both cases, the impact on another key, which is neither dependent, nor whose security depends on, the root zone key, is non-existent, other than that it implies that the other key is equally "theoretically weak". In other words, the BSKs might be "weak", but not "compromised", per se - and using that term doesn't facilitate clear and rational discussion, of something pretty darned important for a large class of operational problems (bootstrapping). As to the cost of compromising multiple keys: If two keys share only the algorithm and key size, the expected effort for both is equal. If the required effort to discover the private keys for either key is, on average, what would require six months of the combined effort of 10,000,000 zombie machines, then: - it would take a botnet of 10,000,000 machines six months (on average) to break the root zone key - it would also take the same botnet six months (on average) to break any single one of the BSKs - combined, it would take a year of the whole botnet's combined resources to compromise one BSK and the root zone key, which would then create a theoretical ability to forge answers to queries for both zones, for a small number of devices during a one-time, small window when they bootstrap - the BSKs are independent, so for N BSKs, it would take N+1 times the total resource requirements, to have all the BSKs compromised I'd suggest that the very large resource requirements, the very small window of opportunity, and the requirement that both forgery attempts succeed, for a one-time attack on one single device, puts the likelihood of success sufficiently close to zero to discourage anyone or any organization from making the attempt. Brian From brian.peter.dickson@gmail.com Mon Jan 31 21:41:27 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D80A3A6B72; Mon, 31 Jan 2011 21:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.261 X-Spam-Level: X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSkd2anvB5Zy; Mon, 31 Jan 2011 21:41:26 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 9DEC93A6B68; Mon, 31 Jan 2011 21:41:25 -0800 (PST) Received: by fxm9 with SMTP id 9so7019419fxm.31 for ; Mon, 31 Jan 2011 21:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=zyysIuI4bM+0IsoztmRh0PMHZx1PAsRDLEmvAMa64ls=; b=VXzh0+NbGA0j8l31zkUJKTCMNpsYRWFKsbngzxzM/KSsxNadTUXCj/hP8sCXrJvAdH VehqMVZ0gai/tsvnuwyAZbjBQTiads5TEPBDa1Rr1C+MJkqMKpk7shHUG57KRyuI87E4 islK6tl1X46GWGoyJUr8UfuL7yOnly3s4OQI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rU8ggN0nmr499Zgcb14wyckRXMdzKDYmN0U4xkrSNPAwTi/PADwQH5YppHaFTeqluU LKJgKnolPxqSWcD0evGzsc93fLHFq9sob+U6rrXhJSI15UXVepJIJ1iLGWZUPttX2eg6 80LwSxBUPIevHqUnJNHRgvD3J5c6B1lVQ44pM= MIME-Version: 1.0 Received: by 10.223.83.194 with SMTP id g2mr2370592fal.75.1296539080116; Mon, 31 Jan 2011 21:44:40 -0800 (PST) Received: by 10.223.108.71 with HTTP; Mon, 31 Jan 2011 21:44:40 -0800 (PST) Date: Tue, 1 Feb 2011 01:44:40 -0400 Message-ID: From: Brian Dickson To: John Bashinski Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dnsop@ietf.org WG" , dnsext List , Knight Dave Subject: [dnsext] Time vs bootstrap (was Re: draft-jabley-dnsop-validator-bootstrap-00) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 05:41:27 -0000 Top-replying here, to attempt a high-level suggestion on how to get some close approximation of time, using DNS/DNSSEC exclusively. (Warning to those with weak stomachs - this is mildly evil stuff.) First, without any assurances on the accuracy of local time, the best that can be achieved regarding bootstrap-to-trust-anchor is consistency validation. Having multiple ways to validate the consistency of answers received over DNSSEC, can create a high degree of confidence in the validity of the root key, but cannot get to 100% (I don't think, anyway). However, once you have a trust anchor (root key) that you have a lot of confidence in, you can then do some cute DNSSEC tricks to get a rough idea of time, and then a better idea of time. First, look at the contents of the RRSIGs for the root. If you believe the RRSIGs, you also necessarily believe that the current time must be within the start/end time of those RRSIGs. That might not be close enough for your needs, but may be enough to further validate the root key. (If it is, validate it before continuing.) Next, consider what needs to happen for TLDs that update very frequently. When they update, their SOA SN needs to change. And, if they are signed zones, the SOA record's RRSIG needs to be generated when this happens. Using the start date/time of such an RRSIG on the SOA for such a zone, should give a pretty good value for the current time, to at least an accuracy of a couple of minutes. This may be good enough for DNSSEC purposes. (If you do use RRSIG timestamps, be sure to validate the RRSIG first before trusting the values on the timestamp!!!) While horribly kludgey and mildly evil, it does get an answer that is reasonably trustworthy, moderately accurate/precise, and only uses DNSSEC. (It borrows the main idea from using GPS for clock as well as position.) Brian On Mon, Jan 31, 2011 at 5:44 PM, John Bashinski wrote: > On 2011-01-31 14:32, Joe Abley wrote: > > > Time > =3D=3D=3D=3D > >> 3.1 Initial State >> [...] >> A validator must confirm that its local clock is sufficiently >> accurate before trust anchors can be established, and before >> processing of DNSSEC signatures can proceed. =A0Discussion of timing >> considerations can be found in Section 4. > > How? > > I know I brought it up, but I'm getting a little nervous about using the > home router as the only reference point. Nonetheless, it's a good > paradigmatic case, and I'll go with it for now. You're a home > router. You've just been plugged in, either new from the box or after > being in a closet for a long time. > > > The state of the art in enterprise networks is *unauthenticated* NTP > with internal hosts. The state of the art in consumer is unauthenticated > NTP with a pool on the public Internet. > > This is a huge problem for us with bootstrapping all kinds of crypto > protocols, actually, not just DNSSEC. There's this pervasive assumption > that the time of day is not only known, but known with such certainty > that it can be trusted to ensure the security of systems that are > otherwise engineered to take CPU-aeons to compromise. The problem is > that it's just not an assumption we know how to meet. > > In a lot of cases, we just end up having to assume that keys are valid > from the beginning of time to the end of time. I'd very much like to not > have that be true, but I don't know how to fix it. > > I could imagine a distributed system of digital notaries and time > stampers that at least let you establish that it was "no earlier than" > some particular time, and that also gave you some assurance that some > set of past events had happened in a particular sequence and within > particular time parameters. You could build that with mutually > distrustful "authorities", and use a quorum or something to prevent any > one of them from messing it up. I think that sort of thing is (part of) > what Phillip Hallam-Baker is getting at. But I'm not sure we can deploy > it sanely in time to be useful for this application... and I don't > think you can build *anything* that lets you detect lies about the > time if an attacker controls *all* your communications. From hallam@gmail.com Mon Jan 31 21:56:44 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134643A68B8 for ; Mon, 31 Jan 2011 21:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3foSqM4QAaC for ; Mon, 31 Jan 2011 21:56:42 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 27B643A687B for ; Mon, 31 Jan 2011 21:56:40 -0800 (PST) Received: by gyd12 with SMTP id 12so2668743gyd.31 for ; Mon, 31 Jan 2011 21:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7DfmFz5PgL9hmMk3Dk7H/id7onVW9a/t7VMUPPv/6xU=; b=Kz0yyuhWeJ4iZV4H7Wva4zyIMlL4d5Lvf57S2rLhL37j1VnmDfmAynhzmpIQHZXvlE yIRWFExrlPhZDE6zgBBTIG36q1b3oxT7SjbASn+42hz8QZURzC32mLut5RQOwboV/tsq X16udyicGp0TkLrvtkjLbTd/twMOHm4wuqAF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vMOEG8g8u9bAT7OJ+l55m7mPyP33X1VMUiykUSziAa2X9BORE3ixO5u1+q92j6m6PN 3PJibiPDE733Hmw9IWtVffBbZLubhxhM1Ao67GL0iVNFUu+oWgwvdlFJ8Q9Z5Wp2Dhrd kb91ouHEn7fhBV4gwxhO09b/lczhHP4/avP8U= MIME-Version: 1.0 Received: by 10.100.48.3 with SMTP id v3mr4658739anv.154.1296539995763; Mon, 31 Jan 2011 21:59:55 -0800 (PST) Received: by 10.100.109.16 with HTTP; Mon, 31 Jan 2011 21:59:55 -0800 (PST) In-Reply-To: References: <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> Date: Tue, 1 Feb 2011 00:59:55 -0500 Message-ID: From: Phillip Hallam-Baker To: Brian Dickson Content-Type: multipart/alternative; boundary=0016e645b8c4e27720049b323d57 Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] historal root keys for upgrade path? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 05:56:44 -0000 --0016e645b8c4e27720049b323d57 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 1, 2011 at 12:02 AM, Brian Dickson < brian.peter.dickson@gmail.com> wrote: > On Mon, Jan 31, 2011 at 3:23 PM, Phillip Hallam-Baker > wrote: > > > > On Mon, Jan 31, 2011 at 1:22 PM, Brian Dickson > > wrote: > >> The simplest bootstrap method would be to have a series of BSK > >> (bootstrap keys), created on a periodic basis (every N years), and > >> used as follows: > > > > If a compromise has occurred then the first thing to ask would be why. > > There are only three places where a compromise can logically occur - in > the > > cryptographic algorithm, in the cryptographic hardware manufacturer or in > > ICANN, > > If its the algorithm then the whole series of BSKs is compromised. > > I think it is helpful to use as explicit a form of language as > necessary, to clearly communicate ideas. > > So, when I ask you to clarify this into particulars, it is with the > intent of understanding what you meant. > > "If a compromise has occurred" - a compromise of what, exactly, are > you talking about? > > It could be that there has been a theoretical weakness in the > algorithm, which makes it slightly more feasible to break, but that > the root zone key's private parts have not been exposed. > > In which case, this is "theoretically weak". > This is of course possible, and something easily cured at the sub-root level. It is not possible to cure it at the root level unless you move to a different key strength or more likely given the way RSA strength goes with key size, a whole new algorithm. On the other hand, it could be that the root zone key has had its > private parts found, in which case the term "compromised" has the very > real, concrete meaning in that someone has directly compromised its > security. > This could not happen without the cryptographic hardware being faulty or physically compromised or the design of the system being at fault. Competently designed HSMs do not allow their keys to be exported to just any HSM. There is a cryptographic protocol that governs transfer of keys from one to another. It should take multiple failures before it was even possible to attempt such an attack. > In both cases, the impact on another key, which is neither dependent, > nor whose security depends on, the root zone key, is non-existent, > other than that it implies that the other key is equally > "theoretically weak". > The whole purpose of high security root key management is to ensure that compromise is not possible without a major systemic failure. Since both keys are managed under the same practices, a systemic fault that affects one will affect the other. If we compare the security of the ICANN root to the security of the British crown jewels, the ICANN root is quite definitely more secure. In the first place there are rather more controls that can be placed on information than on a valuable object which must inevitably be in sole custody of a very limited number of people from time to time. Secondly, the incentive to default is far greater as the crown jewels would be infinitely easier to fence. So given that we are talking about extraordinarily low probabilities in the first place, the concerns that dominate management of cryptographic keys at the retail level are almost eliminated when managing a high security root key. -- Website: http://hallambaker.com/ --0016e645b8c4e27720049b323d57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 1, 2011 at 12:02 AM, Brian D= ickson <brian.peter.dickson@gmail.com> wrote:
On Mon, Jan 31, 2011 at 3:23 PM, Phillip Hallam-Baker <= ;hallam@gmail.com> wrote:
>
> On Mon, Jan 31, 2011 at 1:22 PM, Brian Dickson
> <brian.peter.dicks= on@gmail.com> wrote:
>> The simplest bootstrap method would be to = have a series of BSK
>> (bootstrap keys), created on a periodic basis (every N years), and=
>> used as follows:
>
> If a compromise has occurred then the first thing to ask would be why.=
> There are only three places where a compromise can logically occur - i= n the
> cryptographic algorithm, in the cryptographic hardware manufacturer or= in
> ICANN,
> If its the algorithm then the whole series of BSKs is compromised.

I think it is helpful to use as explicit a form of language as
necessary, to clearly communicate ideas.

So, when I ask you to clarify this into particulars, it is with the
intent of understanding what you meant.

"If a compromise has occurred" - a compromise of what, exactly, a= re
you talking about?

It could be that there has been a theoretical weakness in the
algorithm, which makes it slightly more feasible to break, but that
the root zone key's private parts have not been exposed.

In which case, this is "theoretically weak".

This is of course possible, and something easily cured at t= he sub-root level.

It is not possible to cure it a= t the root level unless you move to a different key strength or more likely= given the way RSA strength goes with key size, a whole new algorithm.
=A0

On the other hand, it could be that the root zone key has had its
private parts found, in which case the term "compromised" has the= very
real, concrete meaning in that someone has directly compromised its
security.

This could not happen without= the cryptographic hardware being faulty or physically compromised or the d= esign of the system being at fault.

Competently de= signed HSMs do not allow their keys to be exported to just any HSM. There i= s a cryptographic protocol that governs transfer of keys from one to anothe= r.

It should take multiple failures before it was even pos= sible to attempt such an attack.

=A0
In both cases, the impact on another key, which is neither dependent,
nor whose security depends on, the root zone key, is non-existent,
other than that it implies that the other key is equally
"theoretically weak".

The who= le purpose of high security root key management is to ensure that compromis= e is not possible without a major systemic failure.

Since both keys are managed under the same practices, a systemic fault= that affects one will affect the other.


If we compare the security of the ICANN root to the security of the B= ritish crown jewels, the ICANN root is quite definitely more secure. In the= first place there are rather more controls that can be placed on informati= on than on a valuable object which must inevitably be in sole custody of a = very limited number of people from time to time. Secondly, the incentive to= default is far greater as the crown jewels would be infinitely easier to f= ence.

So given that we are talking about extraordinarily low = probabilities in the first place, the concerns that dominate management of = cryptographic keys at the retail level are almost eliminated when managing = a high security root key.

--
Website: ht= tp://hallambaker.com/

--0016e645b8c4e27720049b323d57-- From paul@xelerance.com Mon Jan 31 23:27:05 2011 Return-Path: X-Original-To: dnsext@core3.amsl.com Delivered-To: dnsext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC13B3A6A79; Mon, 31 Jan 2011 23:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlOarnU8Rp7a; Mon, 31 Jan 2011 23:27:04 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id E4C693A68BD; Mon, 31 Jan 2011 23:27:03 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 6096AC4FE; Tue, 1 Feb 2011 02:30:18 -0500 (EST) Date: Tue, 1 Feb 2011 02:30:17 -0500 (EST) From: Paul Wouters To: Brian Dickson In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "dnsop@ietf.org WG" , Knight Dave , dnsext List Subject: Re: [dnsext] Time vs bootstrap (was Re: draft-jabley-dnsop-validator-bootstrap-00) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 07:27:05 -0000 On Tue, 1 Feb 2011, Brian Dickson wrote: > However, once you have a trust anchor (root key) that you have a lot > of confidence in, you can then do some cute DNSSEC tricks to get a > rough idea of time, and then a better idea of time. > > First, look at the contents of the RRSIGs for the root. If you believe > the RRSIGs, you also necessarily believe that the current time must be > within the start/end time of those RRSIGs. But if the rootkey was compromised, so would the RRSIGs? At least for the view of the device - if the attacker cannot fool the client that the old compromised root key is the real one, or preset a fake successor in some history zone, then the attacker lost anyway. > Next, consider what needs to happen for TLDs that update very frequently. > When they update, their SOA SN needs to change. > And, if they are signed zones, the SOA record's RRSIG needs to be > generated when this happens. > Using the start date/time of such an RRSIG on the SOA for such a zone, > should give a pretty good value for the current time, to at least an > accuracy of a couple of minutes. That actually is a nice trick. Though I don't think it gets you acuracy on the minute, but hours surely. org. got me witin an hour, gov. within 3 hours. > This may be good enough for DNSSEC purposes. At least to then do ntp and and see that it matches our rough expectation. Though in all, if the attacker is your controlling upstream, you are lost. Paul