From kathryn.reynolds@cira.ca Wed Jan 6 10:45:50 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534C128C14F for ; Wed, 6 Jan 2010 10:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, 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 W2dGze+UOXNE for ; Wed, 6 Jan 2010 10:45:49 -0800 (PST) Received: from office-mx.cira.ca (office-smtp.cira.ca [192.228.22.119]) by core3.amsl.com (Postfix) with ESMTP id 2F1A128C14D for ; Wed, 6 Jan 2010 10:45:48 -0800 (PST) Received: from office-mx.cira.ca (localhost.localdomain [127.0.0.1]) by office-mx.cira.ca (Postfix) with SMTP id 0C22A5A0006 for ; Wed, 6 Jan 2010 13:45:43 -0500 (EST) Received: from mbx01.cira.ca (office-mail.cira.ca [192.228.22.115]) by office-mx.cira.ca (Postfix) with ESMTP id E14165A0006 for ; Wed, 6 Jan 2010 13:45:42 -0500 (EST) Received: from MBX01.cira1.cira.ca ([10.2.16.30]) by exch-hub.cira1.cira.ca ([10.2.16.28]) with mapi; Wed, 6 Jan 2010 13:46:21 -0500 From: Kathryn Reynolds To: "dnsop@ietf.org" Date: Wed, 6 Jan 2010 13:46:18 -0500 Thread-Topic: DNS Redircetion Internet Draft Thread-Index: AcqPAIhrKuNriv07TPmLpYw6VhTAoQ== Message-ID: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: multipart/alternative; boundary="_000_CF3C66A5DB184445AE42748BFA64AAA101087FAA0F2CMBX01cira1c_" MIME-Version: 1.0 X-VAMS: NONE X-Mailman-Approved-At: Wed, 06 Jan 2010 11:12:28 -0800 Subject: [DNSOP] DNS Redircetion Internet Draft X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:45:50 -0000 --_000_CF3C66A5DB184445AE42748BFA64AAA101087FAA0F2CMBX01cira1c_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good afternoon, We intend on making a submission, however, we have not completed our submis= sion. Would it be possible to extend the period for receiving comments? I= f so can you let me know what deadline you would provide? Many thanks, Kathryn Reynolds, LL.B. Legal and Policy Counsel Canadian Internet Registration Authority 350 Sparks Street Ottawa, ON K1R 7S8 ph. 613-237-5335 ext. 285 fax: 613-237-0534 www.cira.ca --_000_CF3C66A5DB184445AE42748BFA64AAA101087FAA0F2CMBX01cira1c_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good afternoon,

 

We intend on making a submission, however, we have = not completed our submission.  Would it be possible to extend the period f= or receiving comments?  If so can you let me know what deadline you would= provide?

 

Many thanks,

 

 

Kathryn Reynolds, LL.B.

Legal and Policy Counsel

Canadian Internet Registration Authority

350 Sparks Street Ottawa, ON  K1R 7S8<= /o:p>

ph. 613-237-5335 ext. 285

fax: 613-237-0534

www.cira.ca

 

--_000_CF3C66A5DB184445AE42748BFA64AAA101087FAA0F2CMBX01cira1c_-- From peter@denic.de Wed Jan 6 15:48:59 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C091F3A683F for ; Wed, 6 Jan 2010 15:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, J_CHICKENPOX_54=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 uRkW2f2zHswt for ; Wed, 6 Jan 2010 15:48:58 -0800 (PST) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 404B13A672F for ; Wed, 6 Jan 2010 15:48:57 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1NSfcU-00055m-VT; Thu, 07 Jan 2010 00:48:55 +0100 Received: from localhost by x27.adm.denic.de with local id 1NSfcU-00019o-RV; Thu, 07 Jan 2010 00:48:54 +0100 Date: Thu, 7 Jan 2010 00:48:54 +0100 From: Peter Koch To: IETF DNSOP WG Message-ID: <20100106234854.GB427@x27.adm.denic.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [DNSOP] IETF 76 DNSOP WG Minutes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 23:49:00 -0000 --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear WG, please find below the minutes of our Hiroshima meeting. Many thanks to John for timely delivery and also to Wolfgang for jabber scribing. -Peter --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="minutes76.txt" ----------------------------------------------------------------------------- dnsop WG minutes for IETF 76, Hiroshima, JP ----------------------------------------------------------------------------- WG: DNS Operations (dnsop) Meeting: IETF 76, Hiroshima Location: ANA Crowne Plaza Hiroshima, "Orchid West" Date: Wednesday, 11 November 2009 Time: 13:00 - 15:00 (UTC+9) Chairs: Rob Austein Peter Koch Minutes: John Schnizlein Jabber: xmpp:dnsop@jabber.ietf.org J-Scribe: Wolfgang Nagele J-Script: http://www.ietf.org/jabber/logs/dnsop/2009-11-11.txt Audio: ftp://videolab.uoregon.edu/pub/videolab/video/ietf76/ietf76-ch8-wed-afnoon.mp3 [~59MB] {meeting starts at 00:13:45} WG URL: http://tools.ietf.org/wg/dnsop/ Material: https://datatracker.ietf.org/meeting/76/materials.html#wg-dnsop ----------------------------------------------------------------------------- 1) Administrivia No new IETF attendees, about 5 new to DNSOP WG - Note Well - Agenda : no changes 2) Status Update [13:12] Rob Austein stepping down as co-chair when a replacement is found. 3) Active Drafts [13:14] 3.1) DNSSEC Key Timing Considerations [Johan Ihren] Request adoption as WG document RFC 5011 coverage has been integrated 2 kinds of ZSK rollover: prepublication and double signature (during algorithm change) 3 kinds of KSK roll: double KSK, double RRset (add and remove KSK+DS together), double DS questions: should all rollover mechanisms be described in detail? should we expand the algorithm rollover section? Wes Hardaker: cannot choose, but document ramifications of each Ed Lewis: used this in a key management plan - sent email to list of problems found. Draft authors should check with those already operating DNSSEC zones. Jelte Jansen: should replace rather than expand algorithm section which is wrong Olaf Kaufman: overlap with 4641bis - keep tradeoff in that tutorial document Mark Andrews: should describe introduction and removal of algorithms Rob Austein: yes, you should cover all of these Adopt as WG document? How to resolve interaction between Olaf's 4642bis? Johan: intend to avoid circular dependencies Fredico Neves: why not include in 4641bis? A: they target different audiences Wes: the content is needed Hum for WG doing some document on this content - unanimous Whether to merge with olaf's bis draft or not punted to list. 3.2) Initializing a DNS Resolver with Priming Queries [13:33] [Peter Koch] How many read? 10-ish Open questions: Q1 retry strategy? Q2 parallel vs sequential priming? Q3 may the sbelt be used before priming? Q4 when to reprime? Q5 completeness of response? response to non-EDNS based root (priming) queries? Bob Halley: answer no on Q3 No other comments, exhorted wg to comment on open issues. Peter (as chair): we have an issue tracker which we hope to use for these questions 4) Current & New Topics 4.1) DNSSEC Trust Anchor History Service [13:42] skipped, no presentation 4.2) DNSSEC Signing Policy & Practice Statement Framework [13:44] [Fredrik Ljunggren] DPS states practices and provisions employed or states requirements or policy target audience: registries, or sponsoring organizationor regulatory authorities outlines topics to be considered when implementing DNSSEC. in the DNSSEC for root discussion - compare IANA and Verisign How many read the draft? 5-ish WG document? Peter: has been used for the root and by several TLDs Rob: after reading notes from Stockholm, the status seems similar now. Shane Kerr: have heard lots of support Rob: take question to the mailing list. Matt Larson: we should adopt it. Ed Lewis: have not read it - have written a CPS it is a pain. Do you want to do this? Volunteers to read and comment within 2 weeks: Andrew Sullivan, Wes Hardaker, Sam Weiler, Jaap Akkerhuis, Suzanne Woolf, Matt Larson, Chris Liljenstolpe, <3 more people in the back> Roy Arends: have read it, plan to use at Nominet Olaf: will Nominet bring its experience back and contribute to the document? Yes, if WG adopts. Peter: this question is for the framework only, not that any TLD DPS be published. Jim Galvin: support it. Adopted by "way more than" 5 raising hands in support. 4.3) Reverse DNS in IPv6 for Internet Service Providers [14:00] [Lee Howard] How can residential ISPs populate reverse DNS for IPv6 Changes (since Stockholm): only for residential (not commercial), clarified why wildcard won't match, how to have DHCP update DNS, concern about synchronizing rules for on-the-fly with multiple servers. Informational rather than BCP Removed recommendation not to populate reverse DNS Added concern of mischievous hostnames in delegated DNS How many read? 5-10 Jason Livinggood: think "residential" is too limiting - include Small office Ted Lemon: several recommendations based on current state of home gateways, should be intended state or take them out. Roque Gagliano: this is important - we get questions on this. Rob: comment from Alain Durand: want that "operators are not required to populate" No consensus, needs further discussion 5) Other (non WG) Internet-Drafts [14:11] 5.1) Top Level Domain Name Specification [Olafur Gudmundsson acting as proxy for Lars Johan Liman] asked for feedback on formal (BNF-like) string rules on the screen Markos Sanz: too little to understand John Klensin: come to the plenary to learn more - this does about the right thing. Peter Koch: not convinced this is the right way to go. Don't see justification for IETF to make these rules. This looks more like policy than technical requirement. Rob: ICANN wants something - how can we help. What alternative? Peter: not normative - say that they must be alphabetic. Klensin: to identify the boundary case, if this WG declines to make policy statements, then remove any constraint and allow anything. wnagele: for the mic: we can do this as a "quick fix", and then start the real work to fix 1123, to relax rules further. Olafur: want input even if this is not adopted as a WG document. No consensus, the involved parties need to talk some more. 5.2) IDN TLD Variants Implementation Guideline [14:22] [Jiankang Yao] 5-10 people had read read the draft. Doug Otis: similar to latin names - deal with it the same way as phishing names Stephane: there are several topics - not something we can solve Ed Lewis: before the meeting a few of us worked on recasting this as a simpler technical problem: make 2 zones look the same. The policy issues of whether there should be variants is out of scope. There does appear to be a technical topic of how to make two zones have identical content. Exact framing of question and whether the WG wants to adopt it, is taken to list. 5.3) DNS Proxy Bypass by Recursive DNS Discovery and LOCAL.ARPA [14:44] [Ray Bellis] To solve the problem that many home gateways send DHCP for DNS as the gateway, send query for "LOCAL.ARPA" that gives correct NS address. Issues: DNSSEC breakage What if ISP does not support (or signs) LOCAL.ARPA? 10 people have read, five think should adopt. Take adoption question to the WG list. 5.4) Self-termination Mechanism for Anycast DNS Service skipped 6) I/O with other WGs [14:54] TSVWG [Joe Touch] Update procedures for updating port registration and unify registries Idea is to put all the protocol things (SRV names, Services, Ports) in one table. Adding procedures to change, transfer, withdraw - current is write-only. Stewart Cheshire: SRV always has the underscore - clarifies SRV name Olafur has an alternate proposal. Will take to the list and get feedback to Joe. The following I-Ds were not discussed, serve as reference and pointer here only. BEHAVE OTHER 7) A.O.B. [15:03] Ondrej Sury: DNSSEC plugin for Firefox http://labs.nic.cz for alpha version: Linux, MacOS, Windows Wes Hardaker: this is the third of these - very nice One final announcement: The room for "DNSSEC signed root" - Cattleya West ----------------------------------------------------------------------------- --jq0ap7NbKX2Kqbes-- From peter@denic.de Thu Jan 7 15:14:17 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737A03A67D1 for ; Thu, 7 Jan 2010 15:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 WLWN39sHgDJF for ; Thu, 7 Jan 2010 15:14:16 -0800 (PST) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 03EE23A6405 for ; Thu, 7 Jan 2010 15:14:15 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1NT1YS-0000sa-Vh; Fri, 08 Jan 2010 00:14:13 +0100 Received: from localhost by x27.adm.denic.de with local id 1NT1YP-0002mH-S2; Fri, 08 Jan 2010 00:14:09 +0100 Date: Fri, 8 Jan 2010 00:14:09 +0100 From: Peter Koch To: IETF DNSOP WG Message-ID: <20100107231409.GA10412@x27.adm.denic.de> References: <20100106234854.GB427@x27.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100106234854.GB427@x27.adm.denic.de> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [DNSOP] IETF 76 DNSOP WG Minutes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 23:14:17 -0000 Dear WG, > please find below the minutes of our Hiroshima meeting. Many thanks to John > for timely delivery and also to Wolfgang for jabber scribing. the minutes are now also available in the IETF 76 proccedings: -Peter From sara.monteiro@fccn.pt Wed Jan 13 09:16:52 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926653A69F4 for ; Wed, 13 Jan 2010 09:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 P92iQCEPP9pf for ; Wed, 13 Jan 2010 09:16:51 -0800 (PST) Received: from app01.fccn.pt (app01.fccn.pt [193.137.198.36]) by core3.amsl.com (Postfix) with ESMTP id 76EAE3A682B for ; Wed, 13 Jan 2010 09:16:51 -0800 (PST) Received: from mx.anubis.local (ste [10.1.2.2]) by outbound.anubis.local (Postfix) with ESMTP id 0BE373164D for ; Wed, 13 Jan 2010 17:16:47 +0000 (WET) Received: from [193.136.44.234] (unknown [193.136.44.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sara.monteiro@fccn.pt) by mx.anubis.local (Postfix) with ESMTP id 04AB73163D for ; Wed, 13 Jan 2010 17:16:47 +0000 (WET) Message-ID: <4B4DFFFE.4060209@fccn.pt> Date: Wed, 13 Jan 2010 17:16:46 +0000 From: Sara Monteiro User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: dnsop@ietf.org References: <000601ca9394$998e8ea0$ccababe0$@veiga@fccn.pt> <4B4DF0DC.4000807@fccn.pt> In-Reply-To: <4B4DF0DC.4000807@fccn.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [DNSOP] DNSSEC signed version of .PT X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 17:16:52 -0000 FYI - Apologies if you have already seen this on other lists. Sara Monteiro Pedro Veiga wrote, On 12-01-2010 14:36: > Dear colleagues, > > I'm glad to inform that we have signed the ccTLD .PT in the beginning of > 2010 and the DNSSEC signed version of .pt is in production since 4th of > January. > > For the outside world the .pt infrastructures didn't change, we still > have the same primary name server and a half a dozen of secondaries > (with dnssec-awareness), but we did add an hidden primary where the > signing it's made using an HSM to generate and store the keys. > > We are still working to improve the DNSSEC service in the administrative > side, and we hope to make it available to or Registrars/Registrants in > the next month. > > We are scheduling DNSSEC Technical Workshops to your Registrars and NREN > - National Research and Education Network since they are more proactive > and have the human resources and means to do it. We also have single > registrants with the enough DNS knowledge developing DNSSEC as well, > with the help of the documentation that we made available and also by > direct contact via email and phone. > > Further information, as .pt trust anchor it's available at: > > http://www.dnssec.pt/ > > (also available by mailing list. Send an email to info@dnssec.pt to > subscribe) > > Best Regards, > > Pedro Veiga > > From ogud@ogud.com Wed Jan 13 10:19:38 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736873A6A38 for ; Wed, 13 Jan 2010 10:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 gaNhEeAsolad for ; Wed, 13 Jan 2010 10:19:37 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 4BA793A6860 for ; Wed, 13 Jan 2010 10:19:37 -0800 (PST) Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0DINxYv068180 for ; Wed, 13 Jan 2010 13:23:59 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <201001131823.o0DINxYv068180@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Jan 2010 13:19:30 -0500 To: dnsop@ietf.org From: Olafur Gudmundsson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Subject: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 18:19:38 -0000 Draft http://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-02 says "2.1. Parameters of a Priming Query A priming query SHOULD use a QNAME of "." and a QTYPE of NS. The priming query MUST be sent over UDP (section 6.1.3.2 of [RFC1123]). The UDP source port SHOULD be randomly selected [RFC5452]. The RD bit MUST NOT be set. The resolver SHOULD also use EDNS0 [RFC2671] and announce and handle a reassembly size of at least 1024 octets [RFC3226]. [[Do we need a fallback strategy for EDNS unfriendly environments?]] " Going forward I think this is a bad recommendation. I would like to propose that the document take the plunge of recommending that modern DNSSEC capable resolvers perform the priming query over TCP. The benefit is that a single query can retrieve the signed root NS set and all the signed glue records. The alternative is that a resolver that really cares about DNSSEC will have to issue up to 27 UDP queries in order to get all the records that are related to the NS set. Background: 26 signed glue records will require about 5K answer if each RRSet is signed by a single 1024 bit RSA key. This will never fit into an ENDS0 answer as number of implementations have 4096 byte hard limit on answer size. As of today all the root servers instances that my host reached answered a TCP query. Proposed replacement text: A priming query MUST use a QNAME of "." and a QTYPE of NS, QCLASS of IN, with RD bit set to 0, the source port of the query should be randomly selected [RFC5452]. A DNSSEC aware resolver SHOULD sent the priming query over TCP. If TCP is refused a different server SHOULD be tried, after 3 tries the resolver SHOULD fall back on UDP. A DNSSEC ignorant but EDNS0 capable, resolver SHOULD issue the priming query over UDP, ENDS0 option MUST be included with buffer size of 1220 or larger. If the UDP query times out TCP SHOULD be tried. An EDNS0 ignorant resolver MUST issue the priming query over UDP. By making this change section 2.4 can be dropped, the one on not asking for signed answers. In section 2.2 the draft allows "pre-fetching" of the priming answer when 75% of TTL has passed. I think this should be higher more like 85%..95% or a fixed minimum time like 6 hours. IANA consideration section mentions TTL recommendations for the root zone, but does not make any, I think the document should document what the current values are and the group should pass a comment if it thinks the values are reasonable or can be improved. If the values are going to change based on signature life times when the root is signed then that should also be reflected in the document. Olafur From jim@rfc1035.com Wed Jan 13 11:19:47 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE873A6A3B for ; Wed, 13 Jan 2010 11:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-1.350, 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 JOORdHezTn80 for ; Wed, 13 Jan 2010 11:19:46 -0800 (PST) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by core3.amsl.com (Postfix) with ESMTP id 49FD93A6A38 for ; Wed, 13 Jan 2010 11:19:46 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 40B2E154283B; Wed, 13 Jan 2010 19:19:41 +0000 (GMT) Message-Id: <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> From: Jim Reid To: Olafur Gudmundsson In-Reply-To: <201001131823.o0DINxYv068180@stora.ogud.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 13 Jan 2010 19:19:40 +0000 References: <201001131823.o0DINxYv068180@stora.ogud.com> X-Mailer: Apple Mail (2.936) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 19:19:47 -0000 On 13 Jan 2010, at 18:19, Olafur Gudmundsson wrote: > I would like to propose that the document take the plunge of > recommending that > modern DNSSEC capable resolvers perform the priming query over TCP. I'm not sure it's a good idea to encourage more TCP traffic to the root servers or make that the default. It doesn't seem right to oblige servers with decent underlying transport that can handle big EDNS0 payloads to ignore that and use TCP for their priming queries. How about the following text instead? Priming queries from DNSSEC-aware resolvers A DNSSEC-aware priming query will generate a response of at least 5K. DNSSEC-aware resolvers making a priming query with EDNS0 SHOULD use a minimum buffer size of foo*. If such a priming query fails -- say because of fragmentation issues in the underlying network -- a DNSSEC- aware resolver SHOULD use TCP. If TCP is refused or times out a different server SHOULD be tried. After TCP failures from 3 root servers, the resolver SHOULD fall back on UDP and use an EDNS0 buffer no larger than bar*. A resolver resorting to UDP/EDNS with a buffer size of bar should use that combination for subsequent queries needed to fully validate the response to their priming query. Priming queries from DNSSEC-ignorant resolvers A resolver that is DNSSEC ignorant but EDNS0 capable SHOULD issue the priming query over UDP using ENDS0 and MUST provide a buffer size of 1220 or larger. If the UDP query with EDNS0 times out or fails, TCP SHOULD be tried. Priming queries from DNSSEC-ignorant resolvers An EDNS0 ignorant resolver MUST issue the priming query over UDP. * The values for foo and bar are open for discussion. Though there should be some text to explain whatever values were decided. As a straw man, how about 8K for foo and 1220 for bar? As a number plucked from the air, 8K should be "big enough" to cope with larger or extra signatures, when there's say a rollover of 2048 bit RSA keys under way. [I've not done the arithmetic to check if a signed root response with 2 such keys will fit in 8K. So shoot me...] For bar, the number is even murkier. It needs to be much less than foo (obviously), so maybe the payload should be set to that for an unsigned UDP response? From alex@alex.org.uk Wed Jan 13 12:01:21 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E813B3A69F1 for ; Wed, 13 Jan 2010 12:01:21 -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 EffyzPPB55gP for ; Wed, 13 Jan 2010 12:01:21 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 1E9BB3A6A44 for ; Wed, 13 Jan 2010 12:01:04 -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 F318BC562EF; Wed, 13 Jan 2010 20:01:00 +0000 (GMT) Date: Wed, 13 Jan 2010 20:01:00 +0000 From: Alex Bligh To: Olafur Gudmundsson , dnsop@ietf.org Message-ID: <4748449C0E5079B5A4376DF3@Ximines.local> In-Reply-To: <201001131823.o0DINxYv068180@stora.ogud.com> References: <201001131823.o0DINxYv068180@stora.ogud.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Alex Bligh Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 20:01:22 -0000 --On 13 January 2010 13:19:30 -0500 Olafur Gudmundsson wrote: > Going forward I think this is a bad recommendation. I would like to > propose that the document take the plunge of recommending that > modern DNSSEC capable resolvers perform the priming query over TCP. ... > By making this change section 2.4 can be dropped, the one > on not asking for signed answers. Not sure I agree. I think there is a good case to be made that IF the DO bit is set, THEN the response SHOULD be made over TCP, but you are asking that even non DNSSEC capable resolvers which would query with DO clear make queries over TCP; in these instances the response packet would be much smaller. -- Alex Bligh From alex@alex.org.uk Wed Jan 13 12:01:37 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8A53A6A5A for ; Wed, 13 Jan 2010 12:01:37 -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 AjJDWCD0ghX4 for ; Wed, 13 Jan 2010 12:01:37 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id C2E273A6A45 for ; Wed, 13 Jan 2010 12:01:25 -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 E8800C562F4; Wed, 13 Jan 2010 20:01:21 +0000 (GMT) Date: Wed, 13 Jan 2010 20:01:21 +0000 From: Alex Bligh To: Jim Reid , Olafur Gudmundsson Message-ID: In-Reply-To: <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.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: dnsop@ietf.org, Alex Bligh Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 20:01:37 -0000 --On 13 January 2010 19:19:40 +0000 Jim Reid wrote: > Priming queries from DNSSEC-ignorant resolvers > > An EDNS0 ignorant resolver MUST issue the priming query over UDP. I presume you mean DNSSEC ignorant. -- Alex Bligh From jim@rfc1035.com Wed Jan 13 12:34:55 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCBA3A67FC for ; Wed, 13 Jan 2010 12:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=-0.900, 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 skEHrnlOrwjC for ; Wed, 13 Jan 2010 12:34:54 -0800 (PST) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by core3.amsl.com (Postfix) with ESMTP id 551153A68A6 for ; Wed, 13 Jan 2010 12:34:54 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id A588D154283D; Wed, 13 Jan 2010 20:34:49 +0000 (GMT) Message-Id: <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> From: Jim Reid To: Alex Bligh In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 13 Jan 2010 20:34:49 +0000 References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> X-Mailer: Apple Mail (2.936) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 20:34:55 -0000 On 13 Jan 2010, at 20:01, Alex Bligh wrote: >> An EDNS0 ignorant resolver MUST issue the priming query over UDP. > > I presume you mean DNSSEC ignorant. That's implicit. The language was in Olafur's original text BTW... If a resolver doesn't speak EDNS0, it can't set the DO bit. Which means the authoritative server isn't supposed to send back DNSSEC- related RRs. Unless the resolver explicitly queries for those RRtypes. Which seems unlikely, particularly in the context of a priming query. It would be very odd for a DNS implementation to be DNSSEC-aware and not support EDNS0. Then again, the DNS is full of all sorts of weirdness and bizarre implementations. From alex@alex.org.uk Wed Jan 13 12:49:52 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B553A6804 for ; Wed, 13 Jan 2010 12:49:52 -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 XeRAeQFpUmyp for ; Wed, 13 Jan 2010 12:49:52 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id D0BDA3A67FC for ; Wed, 13 Jan 2010 12:49:51 -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 1C683C562F7; Wed, 13 Jan 2010 20:49:47 +0000 (GMT) Date: Wed, 13 Jan 2010 20:49:47 +0000 From: Alex Bligh To: Jim Reid Message-ID: In-Reply-To: <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.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: dnsop@ietf.org, Alex Bligh Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 20:49:52 -0000 --On 13 January 2010 20:34:49 +0000 Jim Reid wrote: >>> An EDNS0 ignorant resolver MUST issue the priming query over UDP. >> >> I presume you mean DNSSEC ignorant. > > That's implicit. The language was in Olafur's original text BTW... > > If a resolver doesn't speak EDNS0, it can't set the DO bit. Which means > the authoritative server isn't supposed to send back DNSSEC-related RRs. > Unless the resolver explicitly queries for those RRtypes. Which seems > unlikely, particularly in the context of a priming query. It would be > very odd for a DNS implementation to be DNSSEC-aware and not support > EDNS0. Then again, the DNS is full of all sorts of weirdness and bizarre > implementations. I understand DNSSEC support implies EDNS0 support. What I meant was that if the rationale for using TCP is merely that a large packet won't fit into a normal EDNS0 window, and that otherwise TCP is a bad thing as it creates server load, then we should apply the injunction to use UDP (or more accurately not use TCP) to any scenario where we know that large packet isn't going to arrive. Current operational practice would result in DO clear packets fitting within 4096 bytes, so no need for TCP when DO is clear. I thought it might be an error as the section title in your proposed text doesn't match the section text, but that's actually because two section titles are the same which I think is the problem. Thinking about it, a total prohibition (at MUST level) of using TCP is probably a bit harsh given we don't even know they have UDP connectivity. Perhaps "MUST issue the priming query *first* over UDP", or use a SHOULD. -- Alex Bligh From A.Hoenes@TR-Sys.de Wed Jan 13 12:58:57 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA3C13A683C for ; Wed, 13 Jan 2010 12:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.575 X-Spam-Level: X-Spam-Status: No, score=0.575 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 XaeEznCquJpF for ; Wed, 13 Jan 2010 12:58:57 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 98CBC3A6783 for ; Wed, 13 Jan 2010 12:58:55 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA178196314; Wed, 13 Jan 2010 21:58:34 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA11959; Wed, 13 Jan 2010 21:58:33 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201001132058.VAA11959@TR-Sys.de> To: ogud@ogud.com, dnsop@ietf.org Date: Wed, 13 Jan 2010 21:58:32 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 20:58:57 -0000 I apologize for cross-posting due to topical overlap. Please confine follow-up messages to the appropriate list. In the message to DNSOP regarding draft-ietf-dnsop-resolver-priming-02 archived at , Olafur Gudmundsson scratched at a topic of interest to namedroppers as well; he wrote: > ... > > Background: > 26 signed glue records will require about 5K answer if each RRSet is > signed by a single 1024 bit RSA key. > This will never fit into an ENDS0 answer as number of implementations > have 4096 byte hard limit on answer size. Did you read the News these days? An international team lead by the BSI (the "German NSA") and others has solved the RSA-768 challenge, and experts reportedly expect, due to significant progresses, that RSA-1024 will be solved in a rather short time, likely by the end of this year or so! This means that we should immediately plan operationally for widespread use of 2048-bit RSA keys in the "near" future. > As of today all the root servers instances that my host reached > answered a TCP query. > > Proposed replacement text: > >|2.1. Parameters of a Priming Query >| >| A priming query MUST use a QNAME of "." and a QTYPE of NS, QCLASS >| of IN, with RD bit set to 0, the source port of the query should >| be randomly selected [RFC5452]. >| >| A DNSSEC aware resolver SHOULD sent the priming query over TCP. >| If TCP is refused a different server SHOULD be tried, after 3 tries >| the resolver SHOULD fall back on UDP. >| >| A DNSSEC ignorant but EDNS0 capable, resolver SHOULD issue the >| priming query over UDP, ENDS0 option MUST be included with buffer >| size of 1220 or larger. If the UDP query times out TCP SHOULD be >| tried. >| >| An EDNS0 ignorant resolver MUST issue the priming query over UDP. > > ... I therefore support the proposal suggested by Olafur: Recommend that SHOULD issue priming queries immediately over TCP, and not waste time and bandwidth with an initial query over UDP (that will be truncated with certainty). Even UDP with EDNS0 and 4k message size limit (which most likely will need fragmentation and have trouble with firewalls) will not provide a workable solution for a reasonable life time (of RFCs and deployed equipment) and should only be tried as a fallback. Those not liking DNS over TCP might wish to convince the IEEE to quickly double the Ethernet frame size in the interim (in deployed networks as well, of course!) and the IETF to bump the IPv4 512-byte UDP margin. :-) Additionally: ++++++++++++ Work on the use of Elliptic Curve Signatures with DNSSEC urgently needs to be resumed *now* (in DNSEXT). EC keys and signatures will roughly be shorter than RSA keys and signatures by a *factor* of 4..8, for comparable levels of security. Kind regards, Alfred. P.S: Olafur: s/ENDS0/EDNS0/g ! :-) ^^ ^^ [ BTW, one of my favorite personal typos, as well! ] -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From jim@rfc1035.com Wed Jan 13 13:16:55 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A253A683C for ; Wed, 13 Jan 2010 13:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599, J_CHICKENPOX_35=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 shJMJLrXcYNj for ; Wed, 13 Jan 2010 13:16:54 -0800 (PST) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by core3.amsl.com (Postfix) with ESMTP id 8D17F3A67FA for ; Wed, 13 Jan 2010 13:16:54 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 104F2154283B; Wed, 13 Jan 2010 21:16:50 +0000 (GMT) Message-Id: From: Jim Reid To: Alex Bligh In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 13 Jan 2010 21:16:49 +0000 References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> X-Mailer: Apple Mail (2.936) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 21:16:55 -0000 On 13 Jan 2010, at 20:49, Alex Bligh wrote: > Current operational practice would result in DO clear packets > fitting within 4096 bytes, so no need for TCP when DO is clear. I don't think that's always the case Alex. See the lengthy discussion in this list about datagram fragmentation and broken middleware boxes that don't grok EDNS0. [Or do EDNS0 with a 512 byte buffer size. Sigh.] Mind you, some of those boxes will also barf on TCP DNS traffic. > I thought it might be an error as the section title in your > proposed text doesn't match the section text, but that's > actually because two section titles are the same which > I think is the problem. Indeed: a stupid cut&paste error. Sorry. > Thinking about it, a total prohibition (at MUST level) of using TCP > is probably a bit harsh given we don't even know they have UDP > connectivity. Perhaps "MUST issue the priming query *first* > over UDP", or use a SHOULD. SHOULD is more appropriate than a MUST IMO. If the resolver has a priori knowledge that UDP/EDNS0 will fail for some reason, forcing them to do that and then revert to TCP or whatever would be a Bad Thing. The preferred approach might probably be along these lines: [1] EDNS0 + DO with a buffer of 5-8K (ish) [2] TCP + DO when [1] fails [3] EDNS0 + DO + 1.5K (ish) buffer if [2] fails [4] EDNS0 (no DO) with a 1.5K (ish) buffer [5] Vanilla UDP (no EDNS0) if [4] fails I think it would be helpful if the guidance on priming queries was split into 3 categories: resolvers that speak DNSSEC, those that are not DNSSEC-aware but speak EDNS0 and resolvers that are ignorant of both protocols. They'd start at [1], [4] and [5] respectively in the scenario above. The optimal priming behaviour for each may well be different, particularly wrt EDNS0 buffer minima and maxima. It would be good to give an explanation for those buffer sizes too in case we've all forgotten about that when revisiting the issue 5-10 years from now. Perhaps the recommended resolver behaviour should apply to all queries and not just the priming query? From ogud@ogud.com Wed Jan 13 13:21:56 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CB9F3A6867 for ; Wed, 13 Jan 2010 13:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7r93G87EnFsm for ; Wed, 13 Jan 2010 13:21:52 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D52A33A6899 for ; Wed, 13 Jan 2010 13:21:49 -0800 (PST) Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0DLQDPX070042; Wed, 13 Jan 2010 16:26:14 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <201001132126.o0DLQDPX070042@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Jan 2010 16:05:49 -0500 To: Alex Bligh , dnsop@ietf.org From: Olafur Gudmundsson In-Reply-To: <4748449C0E5079B5A4376DF3@Ximines.local> References: <201001131823.o0DINxYv068180@stora.ogud.com> <4748449C0E5079B5A4376DF3@Ximines.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 21:21:56 -0000 At 15:01 13/01/2010, Alex Bligh wrote: >--On 13 January 2010 13:19:30 -0500 Olafur Gudmundsson wrote: > >>Going forward I think this is a bad recommendation. I would like to >>propose that the document take the plunge of recommending that >>modern DNSSEC capable resolvers perform the priming query over TCP. >... >>By making this change section 2.4 can be dropped, the one >>on not asking for signed answers. > >Not sure I agree. > >I think there is a good case to be made that IF the DO bit is set, >THEN the response SHOULD be made over TCP, but you are asking >that even non DNSSEC capable resolvers which would query with >DO clear make queries over TCP; in these instances the response >packet would be much smaller. DNSSEC compliance requires ENDS0 see RFC4035 section 4.1 and 3. Why not ask for signatures ? Paranoid Validating Resolver will need them to make sure the glue is not forged in particular if the answer over the wire different from what the validator was bootstrapped with. With DNSSEC validation you can ignore what section answer came from if you can create a trust chain to the data. Olafur From alex@alex.org.uk Wed Jan 13 13:35:55 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0373A6842 for ; Wed, 13 Jan 2010 13:35:55 -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 XWGykv22yZjz for ; Wed, 13 Jan 2010 13:35:54 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id C7EA43A6840 for ; Wed, 13 Jan 2010 13:35:53 -0800 (PST) Received: from [10.40.215.19] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 50322C562AB; Wed, 13 Jan 2010 21:35:50 +0000 (GMT) Date: Wed, 13 Jan 2010 21:35:48 +0000 From: Alex Bligh To: Jim Reid Message-ID: <074C291445D8E2F871990FD2@nimrod.local> In-Reply-To: References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.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: dnsop@ietf.org, Alex Bligh Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 21:35:55 -0000 --On 13 January 2010 21:16:49 +0000 Jim Reid wrote: > On 13 Jan 2010, at 20:49, Alex Bligh wrote: > >> Current operational practice would result in DO clear packets >> fitting within 4096 bytes, so no need for TCP when DO is clear. > > I don't think that's always the case Alex. See the lengthy discussion in > this list about datagram fragmentation and broken middleware boxes that > don't grok EDNS0. [Or do EDNS0 with a 512 byte buffer size. Sigh.] Mind > you, some of those boxes will also barf on TCP DNS traffic. Indeed - my slack language. I meant that UDP should at least be given a go as we don't know a priori that it will fail. We pretty much do know that for a DO set query. > The preferred approach might probably be along these lines: > [1] EDNS0 + DO with a buffer of 5-8K (ish) > [2] TCP + DO when [1] fails > [3] EDNS0 + DO + 1.5K (ish) buffer if [2] fails > [4] EDNS0 (no DO) with a 1.5K (ish) buffer > [5] Vanilla UDP (no EDNS0) if [4] fails > > I think it would be helpful if the guidance on priming queries was split > into 3 categories: resolvers that speak DNSSEC, those that are not > DNSSEC-aware but speak EDNS0 and resolvers that are ignorant of both > protocols. They'd start at [1], [4] and [5] respectively in the scenario > above. The optimal priming behaviour for each may well be different, > particularly wrt EDNS0 buffer minima and maxima. It would be good to give > an explanation for those buffer sizes too in case we've all forgotten > about that when revisiting the issue 5-10 years from now. You've eliminated TCP fallback for non-DNSSEC supporting clients. On e.g. small MTU dialup, (4) will not succeed in certain circumstances (i.e. where fragments are not transmitted correctly). I think here you are relying on [5] to work, but it seems to me reasonable for a well behaved (but not DNSSEC supporting) client to make a TCP query if UDP doesn't get through for whatever reason. > Perhaps the recommended resolver behaviour should apply to all queries > and not just the priming query? This is somewhat swimming against the tide of (e.g.) draft-ietf-dnsext-dns-tcp-requirements and draft-bellis-dns-recursive-discovery (unadopted, disclosure: am coauthor), which each take the view that there's enough middlebox and fragmentation breakage of UDP that TCP should be available as a reliable fallback. Sure, clients should as a general rule try getting UDP to work, but I think preventing them falling back to UDP unless they are prepared to take the overhead of adding DO set is not right. It might have the perverse effect of encouraging people to set DO unnecessarily. -- Alex Bligh From Ed.Lewis@neustar.biz Wed Jan 13 13:36:25 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855F33A683C for ; Wed, 13 Jan 2010 13:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=-2.929, BAYES_20=-0.74] 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 S7f4+ghdpnVV for ; Wed, 13 Jan 2010 13:36:24 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 77C793A679C for ; Wed, 13 Jan 2010 13:36:24 -0800 (PST) Received: from [10.31.201.49] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0DLem9E070187; Wed, 13 Jan 2010 16:40:49 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <201001131823.o0DINxYv068180@stora.ogud.com> References: <201001131823.o0DINxYv068180@stora.ogud.com> Date: Wed, 13 Jan 2010 16:33:50 -0500 To: dnsop@ietf.org From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Cc: ed.lewis@neustar.biz Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 21:36:25 -0000 At 13:19 -0500 1/13/10, Olafur Gudmundsson wrote: >The benefit is that a single query can retrieve the signed root NS set >and all the signed glue records. I am not certain that the cost of doing TCP for this is worth the benefit of getting a signed priming response. I agree with section 2.4 - no DO bit. What does a DNSSEC-protected priming query gain you? Accepting any old priming query and having a root SEP configured, if the query is right all things work. If the query is wrong/forged you won't get anywhere any how. (Without going into the weeds here - what if one IP address were forged, what if it were 6, 16, or all of them?) (13 name servers => 13 A records + 7 AAAA records last check) Besides the warm and fuzzy feeling, what do you gain? (Keep in mind all of the TCP traffic it would take to get warm and fuzzy.) At 16:05 -0500 1/13/10, Olafur Gudmundsson wrote: >Why not ask for signatures ? Same reason it is no longer fashionable to include keys in signed responses - signatures are a big load. Yes, you'll know sooner if a server's IP address is a problem, but you'd figure it out before it mattered anyway (if you ever use that server). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From alex@alex.org.uk Wed Jan 13 13:36:52 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000973A68DA for ; Wed, 13 Jan 2010 13:36:51 -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 vGrbIxWhWeiv for ; Wed, 13 Jan 2010 13:36:51 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 3B6313A6842 for ; Wed, 13 Jan 2010 13:36:51 -0800 (PST) Received: from [10.40.215.19] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 8A7B6C562AB; Wed, 13 Jan 2010 21:36:47 +0000 (GMT) Date: Wed, 13 Jan 2010 21:36:46 +0000 From: Alex Bligh To: Alex Bligh , Jim Reid Message-ID: <5248F30769BA8EAB049B1568@nimrod.local> In-Reply-To: <074C291445D8E2F871990FD2@nimrod.local> References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <074C291445D8E2F871990FD2@nimrod.local> 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: dnsop@ietf.org, Alex Bligh Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Alex Bligh List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 21:36:52 -0000 --On 13 January 2010 21:35:48 +0000 Alex Bligh wrote: > Sure, clients should as a general rule try getting UDP to work, but > I think preventing them falling back to UDP unless they are prepared ^^^ - TCP > to take the overhead of adding DO set is not right. It might have > the perverse effect of encouraging people to set DO unnecessarily. -- Alex Bligh From jim@rfc1035.com Wed Jan 13 13:53:22 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948C03A680C for ; Wed, 13 Jan 2010 13:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[AWL=-0.480, 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 nqP0OK5rNMrr for ; Wed, 13 Jan 2010 13:53:22 -0800 (PST) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by core3.amsl.com (Postfix) with ESMTP id C5D8D3A6804 for ; Wed, 13 Jan 2010 13:53:21 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 5AA9A154283B; Wed, 13 Jan 2010 21:53:17 +0000 (GMT) Message-Id: <3760968A-4067-41F7-AED6-1FC9268E0077@rfc1035.com> From: Jim Reid To: Alex Bligh In-Reply-To: <074C291445D8E2F871990FD2@nimrod.local> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 13 Jan 2010 21:53:16 +0000 References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <074C291445D8E2F871990FD2@nimrod.local> X-Mailer: Apple Mail (2.936) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 21:53:22 -0000 On 13 Jan 2010, at 21:35, Alex Bligh wrote: > You've eliminated TCP fallback for non-DNSSEC supporting clients. So add that to the list: [6] TCP (no EDNS0) if [5] fails. From ogud@ogud.com Wed Jan 13 13:57:51 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C99D3A680C for ; Wed, 13 Jan 2010 13:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.081, 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 QnWf4vn+s5cF for ; Wed, 13 Jan 2010 13:57:50 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 144233A679C for ; Wed, 13 Jan 2010 13:57:49 -0800 (PST) Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0DM2GAH070364; Wed, 13 Jan 2010 17:02:16 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <201001132202.o0DM2GAH070364@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Jan 2010 16:57:43 -0500 To: Edward Lewis , dnsop@ietf.org From: Olafur Gudmundsson In-Reply-To: References: <201001131823.o0DINxYv068180@stora.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Cc: ed.lewis@neustar.biz Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 21:57:51 -0000 At 16:33 13/01/2010, Edward Lewis wrote: >At 13:19 -0500 1/13/10, Olafur Gudmundsson wrote: > >>The benefit is that a single query can retrieve the signed root NS set >>and all the signed glue records. > >I am not certain that the cost of doing TCP for this is worth the >benefit of getting a signed priming response. I agree with section >2.4 - no DO bit. > >What does a DNSSEC-protected priming query gain you? > >Accepting any old priming query and having a root SEP configured, if >the query is right all things work. If the query is wrong/forged >you won't get anywhere any how. (Without going into the weeds here >- what if one IP address were forged, what if it were 6, 16, or all of them?) > >(13 name servers => 13 A records + 7 AAAA records last check) > >Besides the warm and fuzzy feeling, what do you gain? (Keep in mind >all of the TCP traffic it would take to get warm and fuzzy.) Well having TCP used for all priming queries would make me feel better as TCP traffic is harder to forge. But seriously DNSSEC signed and validated data should protect the the resolver from going to the forged addresses. Yes someone can forge the answer and DoS the resolver into believing that nothing works. The situation is "." and root-servers.net. zones are hosted on the root servers, thus the same servers will get all follow-up questions about signed address sets as the priming query. Resolvers like to ask the "close" servers for information thus it is almost certain that over time the resolver will send a question to all root servers. Based on this I think one TCP connection is better than 14-27 UDP ones. (Resolver that only supports one transport should never ask for the address records it will not use). We can even take this one step further and ask both priming questions over the same TCP connection that is NS and DNSKEY. Ed in my mind this is straight forward engineering question, which approach is better as in cheaper/faster/safer. >At 16:05 -0500 1/13/10, Olafur Gudmundsson wrote: > >>Why not ask for signatures ? > >Same reason it is no longer fashionable to include keys in signed >responses - signatures are a big load. Yes, you'll know sooner if a >server's IP address is a problem, but you'd figure it out before it >mattered anyway (if you ever use that server). >-- This is totally different. Adding DNSKEY to "random" answers was an "optimization" in trading off answer size vs delay in first verification for a zone. The choice made by early RFC's and implementations was the wrong one for the Internet we have today, where UDP fragments have high chance of not getting through. Olafur From jaap@bartok.nlnetlabs.nl Wed Jan 13 14:02:18 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D473A6890 for ; Wed, 13 Jan 2010 14:02:18 -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 847CfsDqxnj1 for ; Wed, 13 Jan 2010 14:02:18 -0800 (PST) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by core3.amsl.com (Postfix) with ESMTP id D6D4B3A683C for ; Wed, 13 Jan 2010 14:02:17 -0800 (PST) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0DM2ASq022539; Wed, 13 Jan 2010 23:02:10 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <201001132202.o0DM2ASq022539@bartok.nlnetlabs.nl> To: Edward Lewis In-reply-to: References: <201001131823.o0DINxYv068180@stora.ogud.com> Comments: In-reply-to Edward Lewis message dated "Wed, 13 Jan 2010 16:33:50 -0500." Date: Wed, 13 Jan 2010 23:02:10 +0100 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (bartok.nlnetlabs.nl [127.0.0.1]); Wed, 13 Jan 2010 23:02:10 +0100 (CET) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 22:02:18 -0000 What does a DNSSEC-protected priming query gain you? I was about to ask the same question. Accepting any old priming query and having a root SEP configured, if the query is right all things work. If the query is wrong/forged you won't get anywhere any how. (Without going into the weeds here - what if one IP address were forged, what if it were 6, 16, or all of them?) (13 name servers => 13 A records + 7 AAAA records last check) Besides the warm and fuzzy feeling, what do you gain? (Keep in mind all of the TCP traffic it would take to get warm and fuzzy.) I think that this is also discussed in Koch's priming draft. jaap From ogud@ogud.com Wed Jan 13 14:41:33 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 625F93A6804 for ; Wed, 13 Jan 2010 14:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, J_CHICKENPOX_43=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 4+b96Mg1RY0V for ; Wed, 13 Jan 2010 14:41:32 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 67FF73A67B0 for ; Wed, 13 Jan 2010 14:41:32 -0800 (PST) Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0DMfOO3070819; Wed, 13 Jan 2010 17:41:24 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <201001132241.o0DMfOO3070819@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Jan 2010 17:41:14 -0500 To: Jim Reid , Alex Bligh From: Olafur Gudmundsson In-Reply-To: References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Cc: dnsop@ietf.org Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 22:41:33 -0000 At 16:16 13/01/2010, Jim Reid wrote: >On 13 Jan 2010, at 20:49, Alex Bligh wrote: > >>Current operational practice would result in DO clear packets >>fitting within 4096 bytes, so no need for TCP when DO is clear. > >I don't think that's always the case Alex. See the lengthy discussion >in this list about datagram fragmentation and broken middleware boxes >that don't grok EDNS0. [Or do EDNS0 with a 512 byte buffer size. >Sigh.] Mind you, some of those boxes will also barf on TCP DNS traffic. EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations will not send more even if client ask for it. Firewalls will enforce this. >>Thinking about it, a total prohibition (at MUST level) of using TCP >>is probably a bit harsh given we don't even know they have UDP >>connectivity. Perhaps "MUST issue the priming query *first* >>over UDP", or use a SHOULD. > >SHOULD is more appropriate than a MUST IMO. If the resolver has a >priori knowledge that UDP/EDNS0 will fail for some reason, forcing >them to do that and then revert to TCP or whatever would be a Bad Thing. We are talking about the priming query, assume no prior knowledge only hints that the resolver is configured with i.e. the SBELT. >The preferred approach might probably be along these lines: > [1] EDNS0 + DO with a buffer of 5-8K (ish) > [2] TCP + DO when [1] fails > [3] EDNS0 + DO + 1.5K (ish) buffer if [2] fails > [4] EDNS0 (no DO) with a 1.5K (ish) buffer > [5] Vanilla UDP (no EDNS0) if [4] fails 1 is not an option >I think it would be helpful if the guidance on priming queries was >split into 3 categories: resolvers that speak DNSSEC, those that are >not DNSSEC-aware but speak EDNS0 and resolvers that are ignorant of >both protocols. They'd start at [1], [4] and [5] respectively in the >scenario above. The optimal priming behaviour for each may well be >different, particularly wrt EDNS0 buffer minima and maxima. It would >be good to give an explanation for those buffer sizes too in case >we've all forgotten about that when revisiting the issue 5-10 years >from now. > >Perhaps the recommended resolver behaviour should apply to all queries >and not just the priming query? No the priming query is different from all other queries. Yes there should be guidance on fall back for ENDS0 and that should be discussed in the ENDS0bis document context. Olafur From jaap@bartok.nlnetlabs.nl Wed Jan 13 15:10:41 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE973A67AC for ; Wed, 13 Jan 2010 15:10:41 -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 e-4Ix8z7kc1A for ; Wed, 13 Jan 2010 15:10:40 -0800 (PST) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by core3.amsl.com (Postfix) with ESMTP id 199103A67A5 for ; Wed, 13 Jan 2010 15:10:39 -0800 (PST) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0DNAWS7070771; Thu, 14 Jan 2010 00:10:32 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <201001132310.o0DNAWS7070771@bartok.nlnetlabs.nl> To: Olafur Gudmundsson In-reply-to: <201001132202.o0DM2GAH070364@stora.ogud.com> References: <201001131823.o0DINxYv068180@stora.ogud.com> <201001132202.o0DM2GAH070364@stora.ogud.com> Comments: In-reply-to Olafur Gudmundsson message dated "Wed, 13 Jan 2010 16:57:43 -0500." Date: Thu, 14 Jan 2010 00:10:32 +0100 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (bartok.nlnetlabs.nl [127.0.0.1]); Thu, 14 Jan 2010 00:10:33 +0100 (CET) Cc: dnsop@ietf.org, Edward Lewis Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 23:10:41 -0000 Well having TCP used for all priming queries would make me feel better as TCP traffic is harder to forge. So let's forget about dnssec an do everything over TCP? But seriously DNSSEC signed and validated data should protect the the resolver from going to the forged addresses. So you wasn't serious? Yes someone can forge the answer and DoS the resolver into believing that nothing works. The situation is "." and root-servers.net. zones are hosted on the root servers, thus the same servers will get all follow-up questions about signed address sets as the priming query. Resolvers like to ask the "close" servers for information thus it is almost certain that over time the resolver will send a question to all root servers. Based on this I think one TCP connection is better than 14-27 UDP ones. (Resolver that only supports one transport should never ask for the address records it will not use). We can even take this one step further and ask both priming questions over the same TCP connection that is NS and DNSKEY. Ed in my mind this is straight forward engineering question, which approach is better as in cheaper/faster/safer. But then I expect some decent answers and not some handwaving and flip-flopping between being serious and not. jaap From nweaver@ICSI.Berkeley.EDU Wed Jan 13 15:16:58 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FBCD3A68E6 for ; Wed, 13 Jan 2010 15:16:58 -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 m4ISfZ2+jw2l for ; Wed, 13 Jan 2010 15:16:57 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 3C0483A688B for ; Wed, 13 Jan 2010 15:16:57 -0800 (PST) Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o0DNGpvU025745; Wed, 13 Jan 2010 15:16:52 -0800 (PST) References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <201001132241.o0DMfOO3070819@stora.ogud.com> In-Reply-To: <201001132241.o0DMfOO3070819@stora.ogud.com> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <087CF96D-19D4-4772-9CEC-8E33C233C2F5@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 13 Jan 2010 15:16:51 -0800 To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1077) Cc: Nicholas Weaver , dnsop@ietf.org, Alex Bligh Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 23:16:58 -0000 On Jan 13, 2010, at 2:41 PM, Olafur Gudmundsson wrote: > At 16:16 13/01/2010, Jim Reid wrote: >> On 13 Jan 2010, at 20:49, Alex Bligh wrote: >>=20 >>> Current operational practice would result in DO clear packets >>> fitting within 4096 bytes, so no need for TCP when DO is clear. >>=20 >> I don't think that's always the case Alex. See the lengthy discussion >> in this list about datagram fragmentation and broken middleware boxes >> that don't grok EDNS0. [Or do EDNS0 with a 512 byte buffer size. >> Sigh.] Mind you, some of those boxes will also barf on TCP DNS = traffic. >=20 > EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations > will not send more even if client ask for it. Firewalls will > enforce this. We should have some additional numbers for this with the new run (we = just released an updated version of Netalyzr, = http://netalyzr.icsi.berkeley.edu ) Among the new tests is a detailed = check for actual DNS MTU rather than advertised DNS MTU. Basically, you can't RELY on UDP packets over 1500B being received by = DNS resolvers when requested, but it works a large amount of the time. So basically, I'd have the model of "Try at EDNS4000, fallback to = EDNS1280, fallback to TCP", and cache whether the resolver needs to do = this for all authorities (because its side is fragment-broken) or just = particular remote authorities. From Ray.Bellis@nominet.org.uk Thu Jan 14 00:39:04 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AACDC3A68F5 for ; Thu, 14 Jan 2010 00:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 u3JNTa4xjEKj for ; Thu, 14 Jan 2010 00:39:03 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 74FE43A6834 for ; Thu, 14 Jan 2010 00:39:02 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=D4RCpMIRPbVT44JAFkSfAol5X5SQEkQPyS7ukeQYYDEwTF55PHJTjBIT m6xJ0lge7c2s5DYjTpvho08HakaEXHEw8oVW+KznlFfSuzxrd2yl7qH83 D/feadKe/6qIwCa; 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=1263458341; x=1294994341; 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.Bellis@nominet.org.uk|Subject:=20Re:=20[DNSO P]=20Priming=20query=20transport=20selection|Date:=20Thu, =2014=20Jan=202010=2008:38:58=20+0000|Message-ID:=20|To:=20Olafur=20Gudmundsson=20 |Cc:=20dnsop@ietf.org|MIME-Version:=201.0|In-Reply-To:=20 <201001132241.o0DMfOO3070819@stora.ogud.com>|References: =20<201001131823.o0DINxYv068180@stora.ogud.com>=09<555CFB 98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com>=0D=0A=09=09<631E7931-47D4-4AAF -B2C6-62DA6DA5A4CA@rfc1035.com>=0D=0A=09=09=20<201001132241.o0DMfOO3070819@stora. ogud.com>; bh=tVMYpSKW9WVFFVgit/80WhLEw2Vt9DosHSKQ4Fp0DSA=; b=wS8+imXNv1xjpYcmrAsgdxVrqUeFycFt8CufrEuC8wXzbZpRHP8QU9P3 D6pqdAl+Neya50jS9Pq4+enHfjd/xenkPKwGm5mOytJuv0ph6WBjveB+C j1HdkSZ/hOB5YRe; X-IronPort-AV: E=Sophos;i="4.49,274,1262563200"; d="scan'208";a="15540338" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 14 Jan 2010 08:38:59 +0000 In-Reply-To: <201001132241.o0DMfOO3070819@stora.ogud.com> References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <201001132241.o0DMfOO3070819@stora.ogud.com> To: Olafur Gudmundsson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 14 Jan 2010 08:38:58 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 14/01/2010 08:38:59 AM, Serialize complete at 14/01/2010 08:38:59 AM Content-Type: multipart/alternative; boundary="=_alternative 002F8337802576AB_=" Cc: dnsop@ietf.org Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 08:39:04 -0000 This is a multipart message in MIME format. --=_alternative 002F8337802576AB_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations > will not send more even if client ask for it. Firewalls will > enforce this. RFC 2671 enforces no such limit - the strict limit is 65535, and =A74.5.5=20 has a hint that 4K might be a reasonable amount of state to maintain for=20 fragment reassembly. I seem to recall that BIND, however, will not permit the EDNS0 buffer size = to be configured above 4096. I'm not in a position to double check that=20 right now, though. Ray --=_alternative 002F8337802576AB_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable  
> EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations
> will not send more even if client ask for it. Firewalls will
> enforce this.
RFC 2671 enforces no such limit - the strict limit is 65535, and =A74.5.5 has a hint that 4K might be a reasonable amount of state to maintain for fragment reassembly.

I seem to recall that BIND, however, will not permit the EDNS0 buffer size to be configured above 4096.  I'm not in a posit= ion to double check that right now, though.

Ray
--=_alternative 002F8337802576AB_=-- From jim@rfc1035.com Thu Jan 14 02:28:45 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F2C3A6774 for ; Thu, 14 Jan 2010 02:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 6f6NHQGrR3qC for ; Thu, 14 Jan 2010 02:28:44 -0800 (PST) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by core3.amsl.com (Postfix) with ESMTP id 293B53A67A3 for ; Thu, 14 Jan 2010 02:28:44 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 9F859154283B; Thu, 14 Jan 2010 10:28:39 +0000 (GMT) Message-Id: <78D11C45-ED0A-4DCE-8052-2B18E2823972@rfc1035.com> From: Jim Reid To: =?ISO-8859-1?Q?Alfred_H=CEnes?= In-Reply-To: <201001132058.VAA11959@TR-Sys.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 14 Jan 2010 10:28:39 +0000 References: <201001132058.VAA11959@TR-Sys.de> X-Mailer: Apple Mail (2.936) Cc: namedroppers@ops.ietf.org, IETF DNSOP WG Subject: [DNSOP] RSA cracking X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 10:28:45 -0000 On 13 Jan 2010, at 20:58, Alfred H=CEnes wrote: > An international team lead by the BSI (the "German NSA") and others > has solved the RSA-768 challenge, and experts reportedly expect, due > to significant progresses, that RSA-1024 will be solved in a rather > short time, likely by the end of this year or so! Hmmm. The paper by Klienjung et al (http://eprint.iacr.org/=20 2010/006.pdf) said it took ~2000 Opteron-years and ~2.5 years of =20 elapsed time to crack RSA768. So if you change keys every month or =20 two, there's not much to worry about.... BTW the authors of that paper =20= said they don't expect 1024-bit RSA to be factored for another 5-10 =20 years with comparable resources to their RSA768 efforts unless =20 factoring algorithms improve a lot. > This means that we should immediately plan operationally for > widespread use of 2048-bit RSA keys in the "near" future. True. Some of us deployed 2048-bit RSA keys in 2007. Perhaps your =20 friends at BSI might like to crack the KSK or ZSK for rfc1035.se? :-) From patrik@frobbit.se Thu Jan 14 07:58:10 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE853A68A8 for ; Thu, 14 Jan 2010 07:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] 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 5gUV0uVc4Oek for ; Thu, 14 Jan 2010 07:58:09 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 2A2053A6813 for ; Thu, 14 Jan 2010 07:58:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 33E6A930B824; Thu, 14 Jan 2010 16:58:04 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpZJwV1AR5kk; Thu, 14 Jan 2010 16:58:04 +0100 (CET) Received: from [10.0.1.3] (unknown [196.219.203.82]) by srv01.frobbit.se (Postfix) with ESMTP id 0EF7D930B820; Thu, 14 Jan 2010 16:58:02 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Thu, 14 Jan 2010 17:58:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <201001132241.o0DMfOO3070819@stora.ogud.com> To: Ray.Bellis@nominet.org.uk X-Mailer: Apple Mail (2.1077) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 15:58:10 -0000 On 14 jan 2010, at 10.38, Ray.Bellis@nominet.org.uk wrote: >> EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations >> will not send more even if client ask for it. Firewalls will >> enforce this. >=20 > RFC 2671 enforces no such limit - the strict limit is 65535, and = =A74.5.5=20 > has a hint that 4K might be a reasonable amount of state to maintain = for=20 > fragment reassembly. >=20 > I seem to recall that BIND, however, will not permit the EDNS0 buffer = size=20 > to be configured above 4096. I'm not in a position to double check = that=20 > right now, though. Please do not start talking about enforcing some fixed limit that we = will laugh about 10 years from now... And if you talk about a limit, = pick something very large (like 65535 that seems to be already chosen). It is enough problems with the 512 limit of today. I do not want to have = the same problems when we pass 4096. Implementations should be free to choose an implementation limit smaller = if they want to (and signal that in the EDNS0 size), but please do not = say that "max value on EDNS0 size will forever be 4096" or something = similar. Be careful with the wording... Patrik From bmanning@karoshi.com Thu Jan 14 08:36:59 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D2E3A696B for ; Thu, 14 Jan 2010 08:36:59 -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 QoUt6oguzCVf for ; Thu, 14 Jan 2010 08:36:59 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id D29383A67A3 for ; Thu, 14 Jan 2010 08:36:58 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o0EGaNEn012851; Thu, 14 Jan 2010 16:36:23 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o0EGaDtR012849; Thu, 14 Jan 2010 16:36:13 GMT Date: Thu, 14 Jan 2010 16:36:13 +0000 From: bmanning@vacation.karoshi.com To: Jim Reid Message-ID: <20100114163613.GC12453@vacation.karoshi.com.> References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <074C291445D8E2F871990FD2@nimrod.local> <3760968A-4067-41F7-AED6-1FC9268E0077@rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3760968A-4067-41F7-AED6-1FC9268E0077@rfc1035.com> User-Agent: Mutt/1.4.1i Cc: dnsop@ietf.org, Alex Bligh Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 16:36:59 -0000 On Wed, Jan 13, 2010 at 09:53:16PM +0000, Jim Reid wrote: > On 13 Jan 2010, at 21:35, Alex Bligh wrote: > > >You've eliminated TCP fallback for non-DNSSEC supporting clients. > > So add that to the list: > [6] TCP (no EDNS0) if [5] fails. > dnssec is just the first extention to reliably tickle the size/frag issues with large UDP responses. Whatever you blokes come up w/ please don't make it feature specific. --bill From nweaver@ICSI.Berkeley.EDU Thu Jan 14 08:40:22 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087153A6819 for ; Thu, 14 Jan 2010 08:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 2sRSaZ62Ieok for ; Thu, 14 Jan 2010 08:40:21 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 3EBD73A67A3 for ; Thu, 14 Jan 2010 08:40:21 -0800 (PST) Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o0EGeAGs004086; Thu, 14 Jan 2010 08:40:10 -0800 (PST) References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <201001132241.o0DMfOO3070819@stora.ogud.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <74CD1A36-E78E-4C29-A8C8-62B8A071C8C5@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Thu, 14 Jan 2010 08:40:10 -0800 To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1077) Cc: Ray.Bellis@nominet.org.uk, dnsop@ietf.org, Nicholas Weaver Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 16:40:22 -0000 On Jan 14, 2010, at 7:58 AM, Patrik F=E4ltstr=F6m wrote: >=20 > Please do not start talking about enforcing some fixed limit that we = will laugh about 10 years from now... And if you talk about a limit, = pick something very large (like 65535 that seems to be already chosen). >=20 > It is enough problems with the 512 limit of today. I do not want to = have the same problems when we pass 4096. >=20 > Implementations should be free to choose an implementation limit = smaller if they want to (and signal that in the EDNS0 size), but please = do not say that "max value on EDNS0 size will forever be 4096" or = something similar. >=20 > Be careful with the wording... Except that EDNS0 MTU is closely coupled with the UDP protocol and its = unreliable nature: this message MTU is irrelevant for TCP or another = reliable protocol. It is highly unlikely that the network's MTU will expand beyond 1500B: = There is too much Ethernet, and >1500B MTUs don't really benefit things = anyway, because the overhead reductions of going to a higher MTU are = near zero (Amdahl's law). =20 Which means the number of fragments which ALL need to be received = correctly goes up linearly with the size of the message. Even WITH a larger MTU, bit-errors become more common. So, even at a = minimum, you'd expect many more failures, dropped packets, etc, with a = 40,000B datagram than a 4000B datagram. And DNS over UDP is already = unreliable enough, at least when you consider it all the way to the end = host with a reasonable timeout on lookups. Thus given the nature of the UDP protocol, it is highly unlikely that = you'd ever want to do ~10K+ byte UDP datagrams. From jabley@hopcount.ca Thu Jan 14 08:46:26 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EBFF3A688A for ; Thu, 14 Jan 2010 08:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 2+zV+rCAPYB4 for ; Thu, 14 Jan 2010 08:46:24 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id B70B23A63D3 for ; Thu, 14 Jan 2010 08:46:24 -0800 (PST) Received: from [199.212.90.17] (helo=dh17.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NVSpu-0000TX-Pw; Thu, 14 Jan 2010 16:46:19 +0000 From: Joe Abley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 14 Jan 2010 11:46:17 -0500 Message-Id: <58E421E4-C7E2-486C-B12A-DCA7F0B2ADC2@hopcount.ca> To: "dnsop@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-SA-Exim-Connect-IP: 199.212.90.17 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: rootsign@icann.org Subject: [DNSOP] Root Zone DNSSEC Deployment Technical Status Update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 16:46:26 -0000 This is the second of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. Apologies if you receive multiple copies of this message. RESOURCES Details of the project, including documentation published to date, can be found at http://www.root-dnssec.org/. We'd like to hear from you. If you have feedback for us, please send it to rootsign@icann.org. DOCUMENTATION The following draft documents were recently published: - DNSSEC Deployment for the Root Zone - DNSSEC Trust Anchor Publication for the Root Zone The following documents are expected to be released as drafts within the next few weeks: - DNSSEC Test Plan for the Root Zone - KSK Holder DNSSEC Facility Requirements DEPLOYMENT STATUS A second KSR exchange between ICANN and VeriSign took place on 2009-12-28. Signing, validation, measurement and monitoring infrastructure continues to be tested. The incremental deployment of DNSSEC in the Root Zone is being carried out first by serving a Deliberately-Unvalidatable Root Zone (DURZ), and subsequently by a conventionally-signed root zone. Discussion of the approach can be found in the document "DNSSEC Deployment for the Root Zone", as well as in the technical presentations delivered at RIPE, NANOG, IETF and ICANN meetings. Internal publication of the DURZ to root server operators began on 7 January 2010, to allow root server operators to do internal testing and to refine internal monitoring or other operational systems. Note that all root servers will continue to serve the unsigned root zone during this internal testing of the DURZ. Full packet capture exercises are planned by root server operators on 2010-01-13 and 2010-01-19, with data being uploaded to OARC's Day in the Life (DITL) infrastructure, in preparation for the full packet captures that will take place during L's DURZ transition. PLANNED DEPLOYMENT SCHEDULE The recently-published deployment plan contains target maintenance windows for each root server's transition to serve the DURZ. The date for the first such transition, on the L root server, has been deferred slightly to accommodate more extensive data capture and measurement testing by all root servers, and also to allow an NSD upgrade to be tested and deployed on L. ICANN plans to serve the DURZ on L-Root using NSD 3.2.4, which is better able to serve large DNS responses. See for more details. Week of 2010-01-25: L starts to serve DURZ Week of 2010-02-08: A starts to serve DURZ Week of 2010-03-01: M, I start to serve DURZ Week of 2010-03-22: D, K, E start to serve DURZ Week of 2010-04-12: B, H, C, G, F start to serve DURZ Week of 2010-05-03: J starts to serve DURZ 2010-07-01: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforseen factors.) From patrik@frobbit.se Thu Jan 14 09:14:19 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5AC3A68F5 for ; Thu, 14 Jan 2010 09:14:19 -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=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 xgUFCUI+7Lpi for ; Thu, 14 Jan 2010 09:14:19 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id C59453A67D6 for ; Thu, 14 Jan 2010 09:14:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 36DDC930F0DC for ; Thu, 14 Jan 2010 18:14:14 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWemN0IFO2bT for ; Thu, 14 Jan 2010 18:14:13 +0100 (CET) Received: from [10.0.1.3] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 473A7930F0D3 for ; Thu, 14 Jan 2010 18:14:13 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1077) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Thu, 14 Jan 2010 19:14:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <201001132241.o0DMfOO3070819@stora.ogud.com> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1077) Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 17:14:20 -0000 On 14 jan 2010, at 17.58, Patrik F=E4ltstr=F6m wrote: > On 14 jan 2010, at 10.38, Ray.Bellis@nominet.org.uk wrote: >=20 >>> EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations >>> will not send more even if client ask for it. Firewalls will >>> enforce this. >>=20 >> RFC 2671 enforces no such limit - the strict limit is 65535, and = =A74.5.5=20 >> has a hint that 4K might be a reasonable amount of state to maintain = for=20 >> fragment reassembly. >>=20 >> I seem to recall that BIND, however, will not permit the EDNS0 buffer = size=20 >> to be configured above 4096. I'm not in a position to double check = that=20 >> right now, though. >=20 > Please do not start talking about enforcing some fixed limit that we = will laugh about 10 years from now... And if you talk about a limit, = pick something very large (like 65535 that seems to be already chosen). Let me clarify (and send excuses to Ray) that my comment was not = directed against what he said, but supporting him, and instead argue = against what some others have suggested -- a fixed low number. Patrik -- with left foot in mouth From sebastian@nzrs.net.nz Thu Jan 14 12:30:42 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4D53A69C9 for ; Thu, 14 Jan 2010 12:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 S09T3NDVYrxN for ; Thu, 14 Jan 2010 12:30:41 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id A76C33A68AE for ; Thu, 14 Jan 2010 12:30:41 -0800 (PST) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 08EFD6CA0D2 for ; Fri, 15 Jan 2010 09:30:37 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz 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 k189bGHnuP0Q for ; Fri, 15 Jan 2010 09:30:33 +1300 (NZDT) Received: from [192.168.22.189] (unknown [202.46.183.35]) (Authenticated sender: sebastian) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 0218B6CA0CF for ; Fri, 15 Jan 2010 09:30:33 +1300 (NZDT) Message-ID: <4B4F7EE8.2030104@nzrs.net.nz> Date: Fri, 15 Jan 2010 09:30:32 +1300 From: Sebastian Castro User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: dnsop@ietf.org References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <201001132241.o0DMfOO3070819@stora.ogud.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 20:30:42 -0000 Ray.Bellis@nominet.org.uk wrote: > >> EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations >> will not send more even if client ask for it. Firewalls will >> enforce this. > > RFC 2671 enforces no such limit - the strict limit is 65535, and §4.5.5 > has a hint that 4K might be a reasonable amount of state to maintain for > fragment reassembly. The text in RFC 2671, presented as a hint, could deal to similar issues with the TCP transport for DNS (working to change SHOULD for MUST). > > I seem to recall that BIND, however, will not permit the EDNS0 buffer > size to be configured above 4096. I'm not in a position to double check > that right now, though. > >From BIND ARM 9.7.0 ---------------------- edns-udp-size Sets the advertised EDNS UDP buffer size in bytes to control the size of packets received. Valid values are 1024 to 4096 (values outside this range will be silently adjusted) ---------------------- > Ray > > > ------------------------------------------------------------------------ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From Ray.Bellis@nominet.org.uk Fri Jan 15 00:14:31 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A768E3A68AA for ; Fri, 15 Jan 2010 00:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6Ob3HuUknRKj for ; Fri, 15 Jan 2010 00:14:30 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 5722E3A686E for ; Fri, 15 Jan 2010 00:14:29 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=jtNAow/EFgwnXMVuxBbwDceeQYfz4YGcdMHE61XJ9K+XPzDhUDQDsNV1 FS0pyKBECBXUNd51Z7eqSjTMC2o95Ze2I/fV5TPGAO15LCJOZ02JnE2+R +iNbz9QqB0S6Nzh; 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=1263543268; x=1295079268; 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.Bellis@nominet.org.uk|Subject:=20Re:=20[DNSO P]=20Priming=20query=20transport=20selection|Date:=20Fri, =2015=20Jan=202010=2008:14:25=20+0000|Message-ID:=20|To:=20Sebastian=20Castro=20|Cc:=20dnsop@ietf.org|MIME-Version:=201.0 |In-Reply-To:=20<4B4F7EE8.2030104@nzrs.net.nz> |References:=20<201001131823.o0DINxYv068180@stora.ogud.co m>=09<555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> =0D=0A=09=09<631E 7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com>=0D=0A=09=09=0D=0A=09<201001132241.o 0DMfOO3070819@stora.ogud.com>=09=20<4B4F 7EE8.2030104@nzrs.net.nz>; bh=kljmm2Od0FEF17nbscNcwEaRPS7egGEZ2q5GJ8yUZzI=; b=Mo8PZ3aPE/3etpzUCRJJiJy+GlsxKKd8LB7HCDXYjUPTDlq05M/Vdlzw eNdPV3n9RmAhwl1bTp/AcZcF16aYSswab2cPn7Z7227GEPYgWeid9DFqv 7SvOMLer/VfZ5Gr; X-IronPort-AV: E=Sophos;i="4.49,281,1262563200"; d="scan'208";a="15557160" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 15 Jan 2010 08:14:26 +0000 In-Reply-To: <4B4F7EE8.2030104@nzrs.net.nz> References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <201001132241.o0DMfOO3070819@stora.ogud.com> <4B4F7EE8.2030104@nzrs.net.nz> To: Sebastian Castro MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 15 Jan 2010 08:14:25 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 15/01/2010 08:14:25 AM, Serialize complete at 15/01/2010 08:14:25 AM Content-Type: multipart/alternative; boundary="=_alternative 002D4400802576AC_=" Cc: dnsop@ietf.org Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 08:14:31 -0000 This is a multipart message in MIME format. --=_alternative 002D4400802576AC_= Content-Type: text/plain; charset="US-ASCII" > The text in RFC 2671, presented as a hint, could deal to similar issues > with the TCP transport for DNS (working to change SHOULD for MUST). Can you elaborate on what you mean? I presume you're aware of my draft-ietf-dnsext-dns-tcp-requirements ? > From BIND ARM 9.7.0 > > ---------------------- > edns-udp-size > Sets the advertised EDNS UDP buffer size in bytes to control the size > of packets received. > Valid values are 1024 to 4096 (values outside this range will be > silently adjusted) > ---------------------- Yes, that's the one. I was sat on a train with a flakey 3G connection when I sent the last message so couldn't check it, but that confirms my recollection. I've already submitted to ISC that the choice of value should be left entirely to the sysadmin, and not restricted to an arbitrary lower value by their software. kind regards, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 002D4400802576AC_= Content-Type: text/html; charset="US-ASCII"
> The text in RFC 2671, presented as a hint, could deal to similar issues
> with the TCP transport for DNS (working to change SHOULD for MUST).

Can you elaborate on what you mean?

I presume you're aware of my draft-ietf-dnsext-dns-tcp-requirements ?

> From BIND ARM 9.7.0
>
> ----------------------
> edns-udp-size
>    Sets the advertised EDNS UDP buffer size in bytes to control the size
> of packets received.
>    Valid values are 1024 to 4096 (values outside this range will be
> silently adjusted)
> ----------------------

Yes, that's the one.  I was sat on a train with a flakey 3G connection when I sent the last message so couldn't check it, but that confirms my recollection.

I've already submitted to ISC that the choice of value should be left entirely to the sysadmin, and not restricted to an arbitrary lower value by their software.

kind regards,

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211



 --=_alternative 002D4400802576AC_=-- From simon.leinen@switch.ch Fri Jan 15 05:13:39 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1C93A68FF for ; Fri, 15 Jan 2010 05:13: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 mVE1YL81zxVw for ; Fri, 15 Jan 2010 05:13:38 -0800 (PST) Received: from diotima.switch.ch (diotima.switch.ch [IPv6:2001:620:0:4:203:baff:fe4c:d751]) by core3.amsl.com (Postfix) with ESMTP id 557E23A6AAC for ; Fri, 15 Jan 2010 05:13:35 -0800 (PST) Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.14.3+Sun/8.14.3) with ESMTP id o0FDDSkY007904; Fri, 15 Jan 2010 14:13:28 +0100 (CET) Received: (from leinen@localhost) by diotima.switch.ch (8.14.3+Sun/8.14.3/Submit) id o0FDDQkU007903; Fri, 15 Jan 2010 14:13:26 +0100 (CET) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f From: Simon Leinen To: Olafur Gudmundsson In-Reply-To: <201001131823.o0DINxYv068180@stora.ogud.com> (Olafur Gudmundsson's message of "Wed, 13 Jan 2010 13:19:30 -0500") References: <201001131823.o0DINxYv068180@stora.ogud.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (usg-unix-v) X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Fri, 15 Jan 2010 14:13:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dnsop@ietf.org Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 13:13:39 -0000 Olafur Gudmundsson writes: > Proposed replacement text: > A priming query MUST use a QNAME of "." and a QTYPE of NS, QCLASS of IN, > with RD bit set to 0, the source port of the query should be randomly > selected [RFC5452]. > A DNSSEC aware resolver SHOULD sent the priming query over TCP. > If TCP is refused a different server SHOULD be tried, after 3 tries > the resolver SHOULD fall back on UDP. > A DNSSEC ignorant but EDNS0 capable, resolver SHOULD issue the > priming query over UDP, ENDS0 option MUST be included with buffer > size of 1220 or larger. If the UDP query times out TCP SHOULD be tried. > An EDNS0 ignorant resolver MUST issue the priming query over UDP. > By making this change section 2.4 can be dropped, the one > on not asking for signed answers. After reading the entire discussion, I support Olafur's suggestion in this form. It's simple enough, and it falls back gracefully if TCP somehow fails to work. As for whether we should "encourage more TCP usage of DNS": I really believe that this is a non-issue. Priming queries from sane implementations that follow the specs are NOT what we should be worried about. Sure, TCP requires more resources than UDP, especially as implemented in today's nameservers. That's why it is important to have a fallback to UDP for priming: Otherwise it would be too easy for an attacker to stop resolving nameservers in their tracks during startup. As to Ed's point that how priming works is not that relevant, especially with DNSSEC at the root: That's probably true. But I also sympathize with Olafur's desire for a warm fuzzy feeling about priming. Plus, it would provide a nice opportunity to log issues with TCP queries early on, with a high chance for server operators to actually notice. -- Simon. From fweimer@bfk.de Fri Jan 15 05:20:40 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223763A6952 for ; Fri, 15 Jan 2010 05:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y46MAxGTMdjs for ; Fri, 15 Jan 2010 05:20:35 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id C99E03A68FF for ; Fri, 15 Jan 2010 05:20:34 -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 1NVm6F-00036Y-L4; Fri, 15 Jan 2010 13:20:27 +0000 Received: by bfk.de with local id 1NVm6H-0000lg-42; Fri, 15 Jan 2010 13:20:29 +0000 To: Jim Reid References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> From: Florian Weimer Date: Fri, 15 Jan 2010 13:20:29 +0000 In-Reply-To: (Jim Reid's message of "Wed\, 13 Jan 2010 21\:16\:49 +0000") Message-ID: <82ockvfqsi.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, Alex Bligh Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 13:20:40 -0000 * Jim Reid: > The preferred approach might probably be along these lines: > [1] EDNS0 + DO with a buffer of 5-8K (ish) > [2] TCP + DO when [1] fails > [3] EDNS0 + DO + 1.5K (ish) buffer if [2] fails > [4] EDNS0 (no DO) with a 1.5K (ish) buffer > [5] Vanilla UDP (no EDNS0) if [4] fails DO is rather pointless because the priming response cannot be validated anyway (even if ROOT-SERVERS.NET were secure, which is currently not planned). --=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 jim@rfc1035.com Fri Jan 15 06:05:10 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D98C3A6936 for ; Fri, 15 Jan 2010 06:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.112 X-Spam-Level: X-Spam-Status: No, score=-3.112 tagged_above=-999 required=5 tests=[AWL=-0.513, 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 uPQ6RRX9YrWG for ; Fri, 15 Jan 2010 06:05:09 -0800 (PST) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by core3.amsl.com (Postfix) with ESMTP id DF2D13A635F for ; Fri, 15 Jan 2010 06:05:08 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 45AAC154283B; Fri, 15 Jan 2010 14:05:03 +0000 (GMT) Message-Id: <8B0DBD24-B956-4689-92B9-A388D0618059@rfc1035.com> From: Jim Reid To: Florian Weimer In-Reply-To: <82ockvfqsi.fsf@mid.bfk.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 15 Jan 2010 14:05:02 +0000 References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <82ockvfqsi.fsf@mid.bfk.de> X-Mailer: Apple Mail (2.936) Cc: dnsop@ietf.org, Alex Bligh Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 14:05:10 -0000 On 15 Jan 2010, at 13:20, Florian Weimer wrote: > DO is rather pointless because the priming response cannot be > validated anyway (even if ROOT-SERVERS.NET were secure, which is > currently not planned). It's not pointless. Validating the priming response requires two operations. The first of these is checking the signature over the root zone's NS RRset. Which won't be returned unless the DO bit is set. [Let's avoid the rat-hole of a DNSSEC-aware resolver iteratively querying for DNSKEYs, RRSIGs and so on.] The second operation involves validating the address records in root-servers.net. Which will also be most efficiently done by setting the DO bit on those queries. From fweimer@bfk.de Fri Jan 15 06:24:06 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A51C3A6AAB for ; Fri, 15 Jan 2010 06:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKHl7k+LuCTK for ; Fri, 15 Jan 2010 06:24:05 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 6B8CB3A6AA4 for ; Fri, 15 Jan 2010 06:24:03 -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 1NVn5h-0002Xp-UW; Fri, 15 Jan 2010 14:23:57 +0000 Received: by bfk.de with local id 1NVn5j-0003et-D7; Fri, 15 Jan 2010 14:23:59 +0000 To: Jim Reid References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <82ockvfqsi.fsf@mid.bfk.de> <8B0DBD24-B956-4689-92B9-A388D0618059@rfc1035.com> From: Florian Weimer Date: Fri, 15 Jan 2010 14:23:59 +0000 In-Reply-To: <8B0DBD24-B956-4689-92B9-A388D0618059@rfc1035.com> (Jim Reid's message of "Fri\, 15 Jan 2010 14\:05\:02 +0000") Message-ID: <82hbqnfnuo.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, Alex Bligh Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 14:24:06 -0000 * Jim Reid: > On 15 Jan 2010, at 13:20, Florian Weimer wrote: > >> DO is rather pointless because the priming response cannot be >> validated anyway (even if ROOT-SERVERS.NET were secure, which is >> currently not planned). > > It's not pointless. Validating the priming response requires two > operations. The first of these is checking the signature over the root > zone's NS RRset. Which won't be returned unless the DO bit is set. > [Let's avoid the rat-hole of a DNSSEC-aware resolver iteratively > querying for DNSKEYs, RRSIGs and so on.] I'm not sure this narrow perspective is helpful. Given the amount of work required to validate the priming response (which resolvers aren't required to do until they see a client query for ./IN/NS, similar to what happens with all the other NS RRsets), it really doesn't matter if you send a DO=3D0 query first, to get the addresses (in the additional section), and then a DO=3D1 query, to get the signature on the NS RRset (in the answer section). --=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 michelle.cotton@icann.org Fri Jan 15 08:12:33 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B9B3A6B0C; Fri, 15 Jan 2010 08:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WBr6-vyEJAM6; Fri, 15 Jan 2010 08:12:33 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 18A403A6B08; Fri, 15 Jan 2010 08:12:33 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Fri, 15 Jan 2010 08:12:30 -0800 From: Michelle Cotton To: "apps-discuss@ietf.org" , "dnsop@ietf.org" , "tsvwg@ietf.org" Date: Fri, 15 Jan 2010 08:16:01 -0800 Thread-Topic: New version of document for review Thread-Index: AcqV/gdJ7RnGH+msSkqdlFrKEw4FTQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C775D4C11F7D2michellecottonicannorg_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 15 Jan 2010 08:16:08 -0800 Subject: [DNSOP] New version of document for review X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 16:12:33 -0000 --_000_C775D4C11F7D2michellecottonicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Attn: TSVWG Working Group, DNSOPS Working Group and APPS AREA Working Group There is a new version of the Internet Assigned Numbers Authority (IANA) Pr= ocedures for the Management of the Transport Protocol Port Number and Service Name Registry document: draft-ietf-tsvwg-iana-ports-04.txt Please review and send comments. Your feedback is much appreciated. Thank you, Michelle Cotton (on behalf of the ports teams) --_000_C775D4C11F7D2michellecottonicannorg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New version of document for review Attn: TSVWG Working Group, DNSOPS Working Group and APPS AREA Working= Group

There is a new version of the Internet Assigned Numb= ers Authority (IANA) Procedures for the Management
of the Transport Protocol Port Number and Service Name Registry document:
draft-ietf-tsvwg-iana-ports-04.txt

Please review and send comments.  Your feedback is much appreciated.
Thank you,

Michelle Cotton
(on behalf of the ports teams)

 --_000_C775D4C11F7D2michellecottonicannorg_-- From george.barwood@blueyonder.co.uk Fri Jan 15 08:42:12 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B8A3A6B1A for ; Fri, 15 Jan 2010 08:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.454 X-Spam-Level: ** X-Spam-Status: No, score=2.454 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 QH1jtYDt-Xk0 for ; Fri, 15 Jan 2010 08:42:11 -0800 (PST) Received: from smtp-out2.blueyonder.co.uk (smtp-out2.blueyonder.co.uk [195.188.213.5]) by core3.amsl.com (Postfix) with ESMTP id 5E00B3A6B16 for ; Fri, 15 Jan 2010 08:42:11 -0800 (PST) Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1NVpFN-00084E-Dc; Fri, 15 Jan 2010 16:42:05 +0000 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1NVpFM-0007pU-Su; Fri, 15 Jan 2010 16:42:04 +0000 Message-ID: From: "George Barwood" To: , "Olafur Gudmundsson" References: <201001131823.o0DINxYv068180@stora.ogud.com> Date: Fri, 15 Jan 2010 16:42:00 -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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 16:42:12 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk9sYWZ1ciBHdWRtdW5kc3Nv biIgPG9ndWRAb2d1ZC5jb20+DQpUbzogPGRuc29wQGlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5 LCBKYW51YXJ5IDEzLCAyMDEwIDY6MTkgUE0NClN1YmplY3Q6IFtETlNPUF0gUHJpbWluZyBxdWVy eSB0cmFuc3BvcnQgc2VsZWN0aW9uDQoNCg0KPiAyNiBzaWduZWQgZ2x1ZSByZWNvcmRzIHdpbGwg cmVxdWlyZSBhYm91dCA1SyBhbnN3ZXIgaWYgZWFjaCBSUlNldCBpcw0KPiBzaWduZWQgYnkgYSBz aW5nbGUgMTAyNCBiaXQgUlNBIGtleS4NCj4gVGhpcyB3aWxsIG5ldmVyIGZpdCBpbnRvIGFuIEVO RFMwIGFuc3dlciBhcyBudW1iZXIgb2YgaW1wbGVtZW50YXRpb25zDQo+IGhhdmUgNDA5NiBieXRl IGhhcmQgbGltaXQgb24gYW5zd2VyIHNpemUuDQo+IEFzIG9mIHRvZGF5IGFsbCB0aGUgcm9vdCBz ZXJ2ZXJzIGluc3RhbmNlcyB0aGF0IG15IGhvc3QgcmVhY2hlZCBhbnN3ZXJlZCBhIFRDUA0KPiBx dWVyeS4NCg0KV2h5IHdvdWxkIGdsdWUgcmVjb3JkcyBiZSBzaWduZWQ/IFRoYXQncyBub3Qgbm9y bWFsIGluIEROU1NFQywgQUZBSUsuDQpRdWVyeWluZyB0aGUgSUFOQSB0ZXN0YmVkDQoNCmRpZyBu cyAuIEBucy5pYW5hLm9yZy4gK2Ruc3NlYw0KDQpzaWducyBvbmx5IHRoZSBOUyBSUnNldCwgd2hp Y2ggc2VlbXMgcmVhc29uYWJsZS4NCklzIHRoZSB0ZXN0YmVkIG5vdCByZXByZXNlbnRhdGl2ZSBp biBzb21lIHdheT8NCg0KWyBXb3JyaWVkIEknbSBzYXlpbmcgc29tZXRoaW5nIHN0dXBpZCAtIGhh dmVuJ3QgdGhvdWdodCBhYm91dCBETlNTRUMgcmVjZW50bHkgXQ0KR2VvcmdlDQo= From george.barwood@blueyonder.co.uk Sat Jan 16 03:18:09 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635BD3A6921 for ; Sat, 16 Jan 2010 03:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.824 X-Spam-Level: ** X-Spam-Status: No, score=2.824 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, 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 zuwmc7jt+32V for ; Sat, 16 Jan 2010 03:18:08 -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 53F6A3A6774 for ; Sat, 16 Jan 2010 03:18:08 -0800 (PST) Received: from [172.23.170.143] (helo=anti-virus02-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1NW6fJ-0005C0-V6; Sat, 16 Jan 2010 11:18:02 +0000 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1NW6fJ-0004lM-Cy; Sat, 16 Jan 2010 11:18:01 +0000 Message-ID: From: "George Barwood" To: , "Olafur Gudmundsson" References: <201001131823.o0DINxYv068180@stora.ogud.com> Date: Sat, 16 Jan 2010 11:17:56 -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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 11:18:09 -0000 PiBXaHkgd291bGQgZ2x1ZSByZWNvcmRzIGJlIHNpZ25lZD8gVGhhdCdzIG5vdCBub3JtYWwgaW4g RE5TU0VDLCBBRkFJSy4NCg0KVG8gY29ycmVjdCBteSBzdGF0ZW1lbnQsIHRoZSBmb2xsb3dpbmcg cXVlcnkgc2hvd3MgdGhhdCBnbHVlIHJlY29yZHMgbWF5IGJlIHNpZ25lZA0KDQpkaWcgc29hIHNl IEBhLm5zLnNlICsgZG5zc2VjDQoNCndpY2ggaGFzIGEgcmVzcG9uc2Ugc2l6ZSBvZiAgMjk0NCBi eXRlcy4gSG93ZXZlciwgbW9zdCBvZiB0aGlzIGlzIEFkZGl0aW9uYWwgU2VjdGlvbiBSUlNJR1Ms IGFuZA0KDQpkaWcgc29hIHNlIEBhLm5zLnNlICsgZG5zc2VjICtidWZzaXplPTcwMA0KDQpzaG93 cyB0aGF0IHRoZSAidml0YWwiIGRhdGEgaXMgbXVjaCBzbWFsbGVyLCBhbmQgdHJ1bmNhdGlvbiB3 aWxsIG5vdCBvY3VyIGZvciANCmFuIEVEU04wIGJ1ZmZlciBzaXplIG9mIHNheSAxNDAwIGJ5dGVz LiBUaGUgc2FtZSB3aWxsIGFwcGx5IGZvciB0aGUgcHJpbWluZyBxdWVyeS4NCg0KVGhlIHF1ZXN0 aW9uIHRoZW4gaXMgImlzIHRoZSBhZGRpdGlvbmFsIFJSU0lHIGRhdGEgdXNlZnVsIiA/DQoNCk15 IGFuc3dlciBpcyAicHJvYmFibHkgbm90Ii4NCg0KRE5TIGRhdGEgY2FuIGJlIGJyb2FkbHkgY2xh c3NpZmllZCBhcyANCg0KIlVzZXIgZGF0YSIgKCBlLmcuIEEgcmVjb3JkIGZvciB3d3cuZ29vZ2xl LmNvbSApDQoiTmFtZSBzZXJ2ZXIgZGF0YSIgKCBlLmcuIE5TIHJlY29yZHMsIGFuZCB0aGUgYXNz b2NpYXRlZCBBIGFuZCBBQUFBIHJlY29yZHMgKQ0KIlNpZ25hdHVyZSBkYXRhIiAoIGUuZy4gUlJT SUcsIERTIGFuZCBETlNLRVkgcmVjb3JkcyApDQoNCkluIG9yZGVyIHRvIG9idGFpbiB2YWxpZGF0 ZWQgVXNlciBkYXRhLCBhIGNsaWVudCBuZWVkcyANCg0KKDEpIFRoZSByZWNvcmQgaXRzZWxmICgg d3d3Lmdvb2dsZS5jb20gQSAxLjIuMy40ICkNCigyKSBBbiBSUlNJRyByZWNvcmQgIHd3dy5nb29n bGUuY29tIFJSU0lHIC4uLi4uICkNCigzKSBUaGUgYXBwcm9wcmlhdGUgY2hhaW4gb2Ygc2lnbmVk IEROU0tFWSAvIERTIHJlY29yZHMuDQoNCkl0J3Mgbm90IG5lY2Vzc2FyeSBmb3IgdGhlICJuYW1l IHNlcnZlciBkYXRhIiB0byBiZSBzaWduZWQgYXQgYWxsLCB0aGF0IGRhdGENCmlzIG1lcmVseSB1 c2VkIHRvIGxvY2F0ZSBzZXJ2ZXJzIHdoZXJlIHRoZSBlc3NlbnRpYWwgc2VjdXJlIGRhdGEgaXMg bG9jYXRlZC4NCg0KSXQgbWlnaHQgYmUgYXJndWVkIHRoYXQgaGF2aW5nIHNpZ25hdHVyZXMgZm9y IHRoZSAiTmFtZSBzZXJ2ZXIgZGF0YSIgaW5jcmVhc2VzDQpzb21lIHdhcm0gZnV6enkgZmVlbGlu ZywgYW5kIHByZXZlbnRzIHNvbWUgRGVuaWFsIG9mIFNlcnZpY2UgYXR0YWNrcy4NCkJ1dCBETlNT RUMgaXMgbm90IGRlc2lnbmVkIHRvIHByZXZlbnQgIkRlbmlhbCBvZiBTZXJ2aWNlIiBhdHRhY2tz Lg0KU29tZSAiRGVuaWFsIG9mIFNlcnZpY2UiIGF0dGFja3MgbWF5IGJlIHByZXZlbnRlZCBieSB1 c2luZyBzdHJvbmdlcg0KdHJhbnNwb3J0LCBidXQgZ2VuZXJhbGx5IEkgZG9uJ3QgdGhpbmsgdGhl c2UgYXR0YWNrcyBhcmUgdG9vIG11Y2ggb2YgYSBjb25jZXJuLg0KDQpUaGVyZSBpcyBhIHBhcnRp Y3VsYXIgdHlwZSBvZiBEZW5pYWwgb2YgU2VydmljZSBhdHRhY2sgdGhhdCBtaWdodCBiZSBwcmV2 ZW50ZWQNCmJ5IHNpZ25pbmcgIk5hbWUgc2VydmVyIGRhdGEiLiBGb3IgZXhhbXBsZSwgc3VwcG9z ZSBhIHBhcnRpY3VsYXIgcm9vdCBzZXJ2ZXINCmhhcyBiZWVuIGNvbXByb21pc2VkLCBhbmQgaXMg aXNzdWluZyBiYWQgZGF0YS4gSWYgdGhlIGNsaWVudCBjaGVja3MgdGhlIHNpZ25hdHVyZQ0Kb2Yg dGhlICJuYW1lIHNlcnZlciBkYXRhIiwgaXQgY2FuIGRldGVjdCB0aGUgYmFkIGRhdGEsIGFuZCB0 cnkgYW5vdGhlciByb290IHNlcnZlci4NCg0KU28sIGFzIEkgc2VlIGl0LCB0aGUgcXVlc3Rpb24g aXMgd2hldGhlciBpdCdzIHdvcnRoIHByZXZlbnRpbmcgYSBjZXJ0YWluIGNsYXNzDQpvZiBEZW5p YWwgb2YgU2VydmljZSBhdHRhY2tzICggYW5kIGFsc28gYWNjaWRlbnRzIHdoZXJlIGEgbmFtZSBz ZXJ2ZXIgaXMNCm1pcy1iZWhhdmluZyApLg0KDQpJIHRoaW5rIHRoaXMgaXMgdXAgdG8gcmVjdXJz aXZlIHJlc29sdmVyLiBTb21lIHJlc29sdmVycyBtYXkgY2hvb3NlIHRvIHZhbGlkYXRlDQoiTmFt ZSBzZXJ2ZXIgZGF0YSIsIGF0IGEgc21hbGwgY29zdCBpbiBwZXJmb3JtYW5jZSwgb3RoZXJzIG1h eSBjaG9vc2Ugbm90IHRvDQooIG9yIGFkb3B0IGh5YnJpZCBzdHJhdGVnaWVzIDogYXNzdW1lIG5h bWUgc2VydmVyIGRhdGEgaXMgb2sgdW50aWwgYSBmYWlsdXJlIG9jY3VycywNCmFuZCB0aGVuIGJh Y2sgdXAgYW5kIHN0YXJ0IGNoZWNraW5nLCBvciBjaGVjayBhcyBhIGJhY2tncm91bmQgYWN0aXZp dHkgKS4NCg0KVGhlcmVmb3JlIEkgd291bGQgYXJndWUgdGhhdCB0aGUgcHJpbWluZyBxdWVyeSB0 cmFuc3BvcnQgbmVlZCBub3QgYmUgc3BlY2lmaWVkDQppbiB0aGUgc3RhbmRhcmQuDQoNCkdlb3Jn ZQ0K From jim@rfc1035.com Sat Jan 16 05:25:32 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79CC3A68FB for ; Sat, 16 Jan 2010 05:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.055 X-Spam-Level: X-Spam-Status: No, score=-3.055 tagged_above=-999 required=5 tests=[AWL=-0.456, 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 Mzh3z+FG0Nye for ; Sat, 16 Jan 2010 05:25:31 -0800 (PST) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by core3.amsl.com (Postfix) with ESMTP id 8FE853A68AD for ; Sat, 16 Jan 2010 05:25:31 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id CD760154283B; Sat, 16 Jan 2010 13:25:25 +0000 (GMT) From: Jim Reid To: "George Barwood" In-Reply-To: X-Priority: 3 References: <201001131823.o0DINxYv068180@stora.ogud.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 16 Jan 2010 13:25:25 +0000 X-Mailer: Apple Mail (2.936) Cc: IETF DNSOP WG Subject: [DNSOP] signing glue and additional data X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 13:25:32 -0000 On 16 Jan 2010, at 11:17, George Barwood wrote: > To correct my statement, the following query shows that glue records > may be signed > > dig soa se @a.ns.se + dnssec No it doesn't. The name servers for .se are authoritative for the address records for *.ns.se. And ns.se isn't delegated either. The A and AAAA records for *.ns.se in this response are not glue. They would be glue if they were in a referral response from a server for .se's parent. > The question then is "is the additional RRSIG data useful" ? > > My answer is "probably not". So authoritative servers shouldn't volunteer helpful/relevant data in the Additional Section of a response, should they? If the server's got additional data that might benefit the client -- like an A or AAAA record for a hostname in the RDATA of an answer -- it makes sense for the server to include it provided there's room for that data in the response. That also applies to any RRSIG(s) over that additional data, assuming of course the client had set the DO bit. From george.barwood@blueyonder.co.uk Sat Jan 16 06:55:05 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C7413A69F6 for ; Sat, 16 Jan 2010 06:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.639 X-Spam-Level: ** X-Spam-Status: No, score=2.639 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_20=-0.74, 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 oH5y7QzNjwEw for ; Sat, 16 Jan 2010 06:55:04 -0800 (PST) Received: from smtp-out2.blueyonder.co.uk (smtp-out2.blueyonder.co.uk [195.188.213.5]) by core3.amsl.com (Postfix) with ESMTP id 8FAFD3A69F2 for ; Sat, 16 Jan 2010 06:55:04 -0800 (PST) Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1NWA3G-0005Jl-0l; Sat, 16 Jan 2010 14:54:58 +0000 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1NWA3E-00073q-Vz; Sat, 16 Jan 2010 14:54:57 +0000 Message-ID: <5F83DF543FF0440E8D295E5C5B11C9D6@localhost> From: "George Barwood" To: "Jim Reid" References: <201001131823.o0DINxYv068180@stora.ogud.com> Date: Sat, 16 Jan 2010 14:54:52 -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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: IETF DNSOP WG Subject: Re: [DNSOP] signing glue and additional data X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 14:55:05 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkppbSBSZWlkIiA8amltQHJm YzEwMzUuY29tPg0KVG86ICJHZW9yZ2UgQmFyd29vZCIgPGdlb3JnZS5iYXJ3b29kQGJsdWV5b25k ZXIuY28udWs+DQpDYzogIklFVEYgRE5TT1AgV0ciIDxkbnNvcEBpZXRmLm9yZz4NClNlbnQ6IFNh dHVyZGF5LCBKYW51YXJ5IDE2LCAyMDEwIDE6MjUgUE0NClN1YmplY3Q6IHNpZ25pbmcgZ2x1ZSBh bmQgYWRkaXRpb25hbCBkYXRhDQoNCg0KPiBPbiAxNiBKYW4gMjAxMCwgYXQgMTE6MTcsIEdlb3Jn ZSBCYXJ3b29kIHdyb3RlOg0KPiANCj4+IFRvIGNvcnJlY3QgbXkgc3RhdGVtZW50LCB0aGUgZm9s bG93aW5nIHF1ZXJ5IHNob3dzIHRoYXQgZ2x1ZSByZWNvcmRzICANCj4+IG1heSBiZSBzaWduZWQN Cj4+DQo+PiBkaWcgc29hIHNlIEBhLm5zLnNlICsgZG5zc2VjDQo+IA0KPiBObyBpdCBkb2Vzbid0 LiBUaGUgbmFtZSBzZXJ2ZXJzIGZvciAuc2UgYXJlIGF1dGhvcml0YXRpdmUgZm9yIHRoZSAgDQo+ IGFkZHJlc3MgcmVjb3JkcyBmb3IgKi5ucy5zZS4gQW5kIG5zLnNlIGlzbid0IGRlbGVnYXRlZCBl aXRoZXIuIFRoZSBBICANCj4gYW5kIEFBQUEgcmVjb3JkcyBmb3IgKi5ucy5zZSBpbiB0aGlzIHJl c3BvbnNlIGFyZSBub3QgZ2x1ZS4gVGhleSB3b3VsZCAgDQo+IGJlIGdsdWUgaWYgdGhleSB3ZXJl IGluIGEgcmVmZXJyYWwgcmVzcG9uc2UgZnJvbSBhIHNlcnZlciBmb3IgLnNlJ3MgIA0KPiBwYXJl bnQuDQoNCk9rLCB5b3UgY2FuIGFyZ3VlIG92ZXIgdGhlIGRlZmluaXRpb24gb2Ygd2hhdCBhIGds dWUgcmVjb3JkIGlzLg0KRnJvbSB0aGUgY2xpZW50J3MgcG9pbnQgb2YgdmlldywgdGhlIEEgcmVj b3JkIGlzIG5vdCBhdXRob3JpdGF0aXZlDQooIGFsdGhvdWdoIGEgdmFsaWQgUlJzaWcgY291bGQg cHJvdmUgdGhlIEEgcmVjb3JkIGlzIGF1dGhvcml0YXRpdmU/ICkuDQpJIHdhcyB1c2luZyAiZ2x1 ZSIgaGVyZSBpbiB0aGUgd2Vha2VyIHNlbnNlIDogIkFuIEEgcmVjb3JkIGZvciBhbiBpbi16b25l DQpOUyByZWNvcmQgaW5jbHVkZWQgaW4gdGhlIGFkZGl0aW9uYWwgc2VjdGlvbiIuDQoNCj4+IFRo ZSBxdWVzdGlvbiB0aGVuIGlzICJpcyB0aGUgYWRkaXRpb25hbCBSUlNJRyBkYXRhIHVzZWZ1bCIg Pw0KPj4NCj4+IE15IGFuc3dlciBpcyAicHJvYmFibHkgbm90Ii4NCj4gDQo+IFNvIGF1dGhvcml0 YXRpdmUgc2VydmVycyBzaG91bGRuJ3Qgdm9sdW50ZWVyIGhlbHBmdWwvcmVsZXZhbnQgZGF0YSBp biAgDQo+IHRoZSBBZGRpdGlvbmFsIFNlY3Rpb24gb2YgYSByZXNwb25zZSwgc2hvdWxkIHRoZXk/ IElmIHRoZSBzZXJ2ZXIncyBnb3QgIA0KPiBhZGRpdGlvbmFsIGRhdGEgdGhhdCBtaWdodCBiZW5l Zml0IHRoZSBjbGllbnQgLS0gbGlrZSBhbiBBIG9yIEFBQUEgIA0KPiByZWNvcmQgZm9yIGEgaG9z dG5hbWUgaW4gdGhlIFJEQVRBIG9mIGFuIGFuc3dlciAtLSBpdCBtYWtlcyBzZW5zZSBmb3IgIA0K PiB0aGUgc2VydmVyIHRvIGluY2x1ZGUgaXQgcHJvdmlkZWQgdGhlcmUncyByb29tIGZvciB0aGF0 IGRhdGEgaW4gdGhlICANCj4gcmVzcG9uc2UuIFRoYXQgYWxzbyBhcHBsaWVzIHRvIGFueSBSUlNJ RyhzKSBvdmVyIHRoYXQgYWRkaXRpb25hbCBkYXRhLCAgDQo+IGFzc3VtaW5nIG9mIGNvdXJzZSB0 aGUgY2xpZW50IGhhZCBzZXQgdGhlIERPIGJpdC4NCg0KSXQncyBub3QgY2xlYXIuIFlvdSBjYW4g YXJndWUgdGhhdCBpdCdzIGJlc3QgdG8gaW5jbHVkZSBhcyBtdWNoIGFkZGl0aW9uYWwgZGF0YQ0K YXMgcG9zc2libGUsIHRvIG1pbmltaXplIHRoZSBudW1iZXIgb2YgdHJhbnNhY3Rpb25zLiBPbiB0 aGUgb3RoZXIgaGFuZCBpZiB0aGlzIGlzIGF0IHRoZQ0KZXhwZW5zZSBvZiBhIGxvdCBvZiB3YXN0 ZWQgYmFuZHdpZHRoLCBvciBtaWdodCBjYXVzZSBmYWlsdXJlcyBvciB2dWxuZXJhYmlsaXRpZXMg Zm9yIEVETlMwDQpwYWNrZXRzID4gTVRVLCBtYXliZSBpdCdzIG5vdCBhIGdvb2QgcG9saWN5LiBJ dCBkb2VzIGRlcGVuZCBvbiB3aGV0aGVyDQp0aGUgcmVzb2x2ZXIgaXMgYm90aGVyaW5nIHRvIHZh bGlkYXRlICJOYW1lIHNlcnZlciBkYXRhIiBpbW1lZGlhdGVseS4NCg0KVGhpcyBwYXJ0bHkgZ29l cyBiYWNrIHRvIHRoZSBxdWVzdGlvbiBJIHJhaXNlZCBhdA0KDQpodHRwOi8vb3BzLmlldGYub3Jn L2xpc3RzL25hbWVkcm9wcGVycy9uYW1lZHJvcHBlcnMuMjAwOS9tc2cwMjY0Ny5odG1sDQoNCndo ZXJlIEkgYXJndWVkIHRoYXQgc2VydmVycyBzaG91bGQgYnkgZGVmYXVsdCBsaW1pdCBFRE5TMCBy ZXNwb25zZXMgdG8gfjE1MDAgYnl0ZXMsDQp0byBtaXRpZ2F0ZSBhbXBsaWZpY2F0aW9uIGF0dGFj a3MgYW5kIGF2b2lkIFVEUCBmcmFnbWVudGF0aW9uIHByb2JsZW1zLg0KDQpSZWdhcmRzLA0KR2Vv cmdlDQo= From sebastian@nzrs.net.nz Sun Jan 17 13:05:21 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E7C3A69AE for ; Sun, 17 Jan 2010 13:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 512pcU3OVREL for ; Sun, 17 Jan 2010 13:05:21 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id CEFEB3A681B for ; Sun, 17 Jan 2010 13:05:20 -0800 (PST) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id CABF02DBC63 for ; Mon, 18 Jan 2010 10:05:16 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz 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 GEBy9iYNRTH6 for ; Mon, 18 Jan 2010 10:05:14 +1300 (NZDT) Received: from [192.168.22.189] (unknown [202.46.183.35]) (Authenticated sender: sebastian) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 6C68C2DBC60 for ; Mon, 18 Jan 2010 10:05:14 +1300 (NZDT) Message-ID: <4B537B8A.8070104@nzrs.net.nz> Date: Mon, 18 Jan 2010 10:05:14 +1300 From: Sebastian Castro User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: dnsop@ietf.org References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <201001132241.o0DMfOO3070819@stora.ogud.com> <4B4F7EE8.2030104@nzrs.net.nz> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Priming query transport selection X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 21:05:21 -0000 Ray.Bellis@nominet.org.uk wrote: > >> The text in RFC 2671, presented as a hint, could deal to similar issues >> with the TCP transport for DNS (working to change SHOULD for MUST). > > Can you elaborate on what you mean? > > I presume you're aware of my draft-ietf-dnsext-dns-tcp-requirements ? Yes, I'm aware of your draft and I meant to support Patrik Falstrom comment: we have to be very careful with the wording if we don't want to be working in future years to update/correct the limit for UDP buffer size in EDNS. > >> From BIND ARM 9.7.0 >> >> ---------------------- >> edns-udp-size >> Sets the advertised EDNS UDP buffer size in bytes to control the size >> of packets received. >> Valid values are 1024 to 4096 (values outside this range will be >> silently adjusted) >> ---------------------- > > Yes, that's the one. I was sat on a train with a flakey 3G connection > when I sent the last message so couldn't check it, but that confirms my > recollection. > > I've already submitted to ISC that the choice of value should be left > entirely to the sysadmin, and not restricted to an arbitrary lower value > by their software. > > kind regards, > > Ray > > -- > Ray Bellis, MA(Oxon) MIET > Senior Researcher in Advanced Projects, Nominet > e: ray@nominet.org.uk, t: +44 1865 332211 > Cheers Sebastian Castro NZRS > > From ajs@shinkuro.com Mon Jan 18 06:46:11 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303E93A68C1 for ; Mon, 18 Jan 2010 06:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.143 X-Spam-Level: X-Spam-Status: No, score=-3.143 tagged_above=-999 required=5 tests=[AWL=-0.544, 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 GJe55k3NK+GZ for ; Mon, 18 Jan 2010 06:46:10 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 728973A6812 for ; Mon, 18 Jan 2010 06:46:10 -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 09B4B2FE8CA1 for ; Mon, 18 Jan 2010 14:46:04 +0000 (UTC) Date: Mon, 18 Jan 2010 09:46:00 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20100118144559.GA68023@shinkuro.com> References: <201001131823.o0DINxYv068180@stora.ogud.com> <5F83DF543FF0440E8D295E5C5B11C9D6@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5F83DF543FF0440E8D295E5C5B11C9D6@localhost> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [DNSOP] on what glue is (was: signing glue and additional data) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 14:46:11 -0000 On Sat, Jan 16, 2010 at 02:54:52PM -0000, George Barwood wrote: > Ok, you can argue over the definition of what a glue record is. Indeed, there was an I-D floating about that offered to do exactly that. It's expired, though: http://tools.ietf.org/html/draft-koch-dns-glue-clarifications-03 Perhaps someone should take that up? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From roy@dnss.ec Mon Jan 18 08:01:21 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467153A68E9 for ; Mon, 18 Jan 2010 08:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 nSS7LKuflrLC for ; Mon, 18 Jan 2010 08:01:20 -0800 (PST) Received: from mail.schlyter.se (trinitario.schlyter.se [195.47.254.10]) by core3.amsl.com (Postfix) with ESMTP id 0FD103A6886 for ; Mon, 18 Jan 2010 08:01:20 -0800 (PST) Received: from [192.168.1.2] (unknown [201.238.167.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roy) by mail.schlyter.se (Postfix) with ESMTPSA id A0D3F2D590; Mon, 18 Jan 2010 17:01:12 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Roy Arends In-Reply-To: <20100118144559.GA68023@shinkuro.com> Date: Mon, 18 Jan 2010 11:01:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201001131823.o0DINxYv068180@stora.ogud.com> <5F83DF543FF0440E8D295E5C5B11C9D6@localhost> <20100118144559.GA68023@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1077) Cc: dnsop@ietf.org Subject: Re: [DNSOP] on what glue is (was: signing glue and additional data) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 16:01:21 -0000 On Jan 18, 2010, at 9:46 AM, Andrew Sullivan wrote: > On Sat, Jan 16, 2010 at 02:54:52PM -0000, George Barwood wrote: >> Ok, you can argue over the definition of what a glue record is. >=20 > Indeed, there was an I-D floating about that offered to do exactly > that. It's expired, though: >=20 > http://tools.ietf.org/html/draft-koch-dns-glue-clarifications-03 >=20 > Perhaps someone should take that up? I've wrote an article about this about 4 years ago, here's the yeast of = it: GLUE RECORDS The concept of glue records (address records such as A and AAAA) exists = _solely_ in zones and are related to delegations. The term is not used = to refer to address records that appear in DNS requests and responses. = Glue records are useful to a resolver so it can locate the delegated = nameserver. I'll try to explain the terminology involved and the process = of determining which records are called glue. Glue addresses are related = to delegation point NS records.=20 We need three properties of a delegation point NS record to determine if = an associated address is glue: APEX: the name of the zone that contains the delegation point NS = record. NSOWNER: the ownername (left hand side) of the delegation NS record. NSDNAME: the NSDNAME (right hand side) of the delegation NS record. All these properties are fully qualified domain names. We can describes 4 classes of NSDNAME: 1) offtree: NSDNAME is not a subdomain of, nor equal to the APEX. 2) authoritative: NSDNAME is a subdomain of APEX, and, NSDNAME is not = equal to nor a subdomain of any NSOWNER. 3) in-bailiwick: NSDNAME is a subdomain of APEX, and, NSDNAME is equal = to or a subdomain of NSOWNER. 4) sibling: NSDNAME is a subdomain of APEX, and, NSDNAME is equal to = or a subdomain of some other NSOWNER. An NSDNAME is the hostname of the nameserver. Nameservers=E2=80=99 = addresses are stored in A or AAAA records. If NSDNAME is of class 1 or = 2, the corresponding addresses are NOT glue.=20 In class 1, the addresses are not even in the zonefile.=20 In class 2, the addresses are in the zone, and are authoritative data. = Note that for the root zone, class 1 simply does not exist, since the = entire dns tree are subdomains of root. If NSDNAME is in class 3 or 4, the corresponding addresses are glue = addresses. GLUE TYPES In class 3 (=E2=80=99in-bailiwick=E2=80=99) it is required to have that = address in the zone. As an example, assume the following NS record: alpha.tld. NS ns1.alpha.tld. The alpha.tld zone resides on nameserver ns1.alpha.tld. A resolver = can=E2=80=99t reach alpha.tld without the address of ns1.alpha.tld. To = resolve ns1.alpha.tld, it needs to reach alpha.tld. To route around this = chicken and egg problem, the tld zone needs to have an address for = ns1.alpha.tld. So, class 3 =E2=80=98in-bailiwick=E2=80=99 requires glue. = We call this glue =E2=80=98in-bailiwick glue=E2=80=99. In class 4 (=E2=80=99sibling=E2=80=99), it is not required to have that = address in the zone, unless there are circular dependencies. As an = example of a circular dependency, assume the following NS records: foo.tld. NS ns1.bar.tld. bar.tld. NS ns1.foo.tld. The =E2=80=98foo=E2=80=99 and =E2=80=98bar=E2=80=99 delegation have a = circular dependency. Foo resides on a server under bar, bar resides on a = server under foo. A resolver can=E2=80=99t reach foo without the address = for ns1.bar which is in the bar zone, and it can=E2=80=99t reach bar = without the address of ns1.foo which is in the foo zone. Hence the = =E2=80=98tld=E2=80=99 zone needs, in this specific case, address records = for both ns1.foo and ns1.bar. Note that circular depenency graphs can be = complex, and paths in the graph can be long. A resolver will more than = likely have measures against looping and long path lengths. Orphan Glue Phenomenon An interesting phenomenon occurs when a delegation NS record set is = removed from the zone while the glue records that reside under it, are = not removed. These glue records are now class 2 (authoritative) records. = We call these addresses 'orphan glue' records, though they are not glue = anymore (they've been adopted)=20 DNSSEC and Glue Glue addresses are not signed. They are supposed to be signed in the = zone that is authoritative for the address record. They also do not = appear in NSEC or NSEC3 chains. However, when glue addresses become = orphan (see 'orphan glue phenomenon') they are now authoritative data, = and subsequently need to be signed.=20 Wide and narrow glue policy.=20 These policies determine what types of glue (class 3 or class 4) are = allowed in a zone. Wide glue policy allows both class 3 (in-bailiwick glue) and class 4 = (sibling glue) to be registered in the zone. Narrow glue policy allows = class 3 only. A combination of the two policies =E2=80=98case-by-case = policy=E2=80=99 exists where sibling glue is only registered to avoid = circular dependencies. The dependency problem exists not only with missing glue. It can be that = foo.tld resides on a nameserver =E2=80=98ns1.cow.moo=E2=80=99 and = =E2=80=98cow.moo=E2=80=99 resides on a nameserver =E2=80=98ns1.foo.tld=E2=80= =99. Both the moo and tld registries are not allowed (by dns-protocol) = to serve off-tree addresses. So, while gluelessness can be avoided for = class 4, it can not be avoided for class 1. Kind regards, Roy Arends Sr Researcher Nominet UK From olaf@NLnetLabs.nl Thu Jan 21 03:42:06 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92953A6A0A for ; Thu, 21 Jan 2010 03:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 VX33RA-P7U01 for ; Thu, 21 Jan 2010 03:42:05 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id C87183A6984 for ; Thu, 21 Jan 2010 03:42:04 -0800 (PST) Received: from [IPv6:2001:7b8:206:1:226:bbff:fe0e:7cc7] ([IPv6:2001:7b8:206:1:226:bbff:fe0e:7cc7]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0LBftWi084759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 21 Jan 2010 12:41:56 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) From: Olaf Kolkman Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-12-151590753; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 21 Jan 2010 12:41:50 +0100 In-Reply-To: <200904282021.n3SKL3sg051528@givry.fdupont.fr> To: dnsop WG References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> Message-Id: <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl> X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 21 Jan 2010 12:41:56 +0100 (CET) Subject: Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 11:42:06 -0000 --Apple-Mail-12-151590753 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In trying to get a reasonable version 2 out of the door before Anaheim I = am trying to identify and where possibly close open issues. As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ = has the open issues listed and a per issue highlight of their history. This thread, about the use of HSMs, is captured in = http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/HSMs the = content of that page is replicated below. I believe I captured the gist of the discussion in a modified version of = paragraph 3.6 (see below). The first two paragraphs are not modified, = the text starting with "The ideal situation" has been. I welcome editorial comments off-list. If the chair believes the current text captures consensus I will move = this issue to the closed issues list. --Olaf $Id: cryptography_flawed 14 2009-02-09 18:54:12Z olaf $ 20100121 The use of HSMs Shane Kerr/Ed Lewis Added: 21 jan 2010 http://www.ietf.org/mail-archive/web/dnsop/current/msg07190.html and http://www.ietf.org/mail-archive/web/dnsop/current/msg07193.html =20 The recommendation to use a HSM is far to strong. Arguments of fate = sharing and operational overhead are being made on the list. Discussion: From: Shane Kerr Subject: Re: [DNSOP] I-D = Action:draft-ietf-dnsop-rfc4641bis-01.txt Date: April 21, 2009 1:03:58 PM GMT+02:00 Cc: dnsop WG I believe the key of the thread is captured in the following quotes: Stephane Bortzmeyer wrote: >=20 > But the risk for the key is not only people modifying it, it is simply > people *reading* it (a concern which also exists for the database but > is much less important).=20 >=20 > I have no practical experience with HSMs but, in my mind, the > interesting thing is that they guarantee noone will read the key > without an authorization (that's quite unlike the database where you > certainly prefer a few unauthorized looks to a complete loss). This is the key point IMHO. AIUI, the attack vector that HSM are designed to protect is that someone makes a copy of your key signing material without you knowing about it. Once they do that, they can spoof replies until such time as you roll your key. If an unauthorized person modifies the contents of the database backing your zone, you may or may not know about it, but an observant customer will at least notice that the data has changed. So the two are not totally equivalent. Having said that, I agree that HSM hysteria is a bit overblown, and that the actual DNSSEC signing is very, very unlikely to be the weakest link in DNS security in any organization. Resolution: Following the suggestion from: From: Peter Koch Subject: Re: [DNSOP] HSMs was Re: I-D = Action:draft-ietf-dnsop-rfc4641bis-01.txt Date: April 27, 2009 1:19:45 PM GMT+02:00 To: IETF DNSOP WG I rewrote the text to highlight the economic tradeoff, the relevant part = of section 3.6 is copied below. 3.6. Private Key Storage It is recommended that, where possible, zone private keys and the zone file master copy that is to be signed be kept and used in off- line, non-network-connected, physically secure machines only. Periodically, an application can be run to add authentication to a zone by adding RRSIG and NSEC RRs. Then the augmented file can be transferred. When relying on dynamic update to manage a signed zone [11], be aware that at least one private key of the zone will have to reside on the master server. This key is only as secure as the amount of exposure the server receives to unknown clients and the security of the host. Although not mandatory, one could administer the DNS in the following way. The master that processes the dynamic updates is unavailable from generic hosts on the Internet, it is not listed in the NS RRSet, although its name appears in the SOA RRs MNAME field. The nameservers in the NS RRSet are able to receive zone updates through NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This approach is known as the "hidden master" setup. The ideal situation is to have a one-way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. For maximum security, the master copy of the zone file should be off-net and should not be updated based on an unsecured network mediated communication. The ideal situation may not be achievable because of economic tradeoffs between risks and costs. For instance, keeping a zone file off-line is not practical and will increase the costs of operating a DNS zone. So in practice the machines on which zone files are maintained will be connected to a network. Operators are advised to take security measures to shield unauthorized access to the master copy in order to prevent modification of DNS data before its signed. Similarly the choice for storing a private key in a Cryptographic Hardware Security Module (HSM) will be influenced by tradeoff a tradeoff between various concerns: o The risks that an unauthorized person has unnoticed read-access to the private key o The remaining window of opportunity for the attacker. o The economic impact of the possible attacks (for a TLD that impact will in most cases be higher than for an individual users). o The costs of rolling the (compromised) keys: whereby the costs of roling a ZSK is lowest and the costs of rolling a KSK that is in wide use as a trust anchor is highest o The costs of buying and maintaining an HSM. For dynamically updated secured zones [11], both the master copy and the private key that is used to update signatures on updated RRs will need to be on-line. ________________________________________________________=20 Olaf M. Kolkman NLnet Labs Science Park 140,=20 http://www.nlnetlabs.nl/ 1098 XG Amsterdam --Apple-Mail-12-151590753 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwbqdTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA1MjUwODQ4MTJaFw0x MTA1MjUwODQ4MTJaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQCLpawAoUQAxivf6blyMswVokRmDl2JGEbtmEu8j0h1BVOlGh6hlI8WaeWy 3x2jJ9uun3VK6oYnHy45ez+dUDjBLjOZdAgwFg225lm1OPdmisghDDVwCIiEogHPqmJtvKYMFoPF 3iFUambJDoQF8DeVeg8ctDvsxsaVGjA8OrMpo0K4I11vnNbCLv7mWCjnaZWt/6Y6TD8ErHQl5dmI rpsHmEZx1/nsocdPkZGRA4QVf1omYHUNs79DtxpYdGKHoorpBNzlzIIjpceiqeOeykoDeYLTZX2G c7Mh4Gdj2MHFqZucxV1cHibb8XKv8ebaGltMV5SrciqRn8yFXmiyTvmId6myNXLiOx+VJiGbLSS3 TltM/kf7UejXeEHulEKufU6Ya6EfH7W2/spTayYCauyLljOjE2Ey5A4oIoJV9eY64OCDuLF2nmGR jOh3JB9nGkZIPhmTUwGZnMELLhzKz+eOZoulM4tXH6KEubed1shQEq1dkJ+tFtRS3Lm+vLCKWvVo 1iZScqPaQf9riPApAVrL+3Wat0p/jtCk5gLBF02uTiWvT2t4ZfSHMEBXR7CvVm58etRQuyZSMHyz UQC4wkDvCeVawNRCZjq6wWdvx5hmr2JeDSkkRtSZ/Fa1WXf26b3BZugI75p5JXafbWdOTRpNc8M5 YMk7tx29ZG3u0qODgDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMG6nUwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwMTIxMTE0MTUwWjAj BgkqhkiG9w0BCQQxFgQUDv5t+wlsRnOS5U6p8nD9ihHaLmgwgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBup1MIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBup1MA0GCSqGSIb3 DQEBAQUABIIBAEvFoDXdBVUtCeKdmkXbBxm/K09OCb0gMhSPxeBJShO0hzHXhSQqmD5SGMmWFAm2 Bo75ZYQ1Iv/HscrrFbhSlHwdiVyqzjMKnDj/cy864TO4PcYPldL4wDyN8AAWRiUyOGE9qgvDWCjN E7I8ICnC+3EGTiTea0+rmfPEIy6JGQvXUWvwL9drKec3QlIW41GReyLaNUV0bsKtA6zye6N/S2yi NcbDJfn+PmNCw2JLJI9PuRouImu3Nw1dCkYfbVdLxXvVunsrvmIzywpo25AcOKEFNccTHiRBsJG6 Aexbbte0Ndzmb8HrAwJtUWuuBoqeuLaSw/waS6BHsJALbMVEqQ0AAAAAAAA= --Apple-Mail-12-151590753-- From olaf@NLnetLabs.nl Thu Jan 21 05:28:44 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2CB93A6A57 for ; Thu, 21 Jan 2010 05:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmd-QFoN-RsE for ; Thu, 21 Jan 2010 05:28:43 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 7FDA83A6765 for ; Thu, 21 Jan 2010 05:28:42 -0800 (PST) Received: from dhcp-07.nlnetlabs.nl (dhcp-07.nlnetlabs.nl [213.154.224.73]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0LDSatq094363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 21 Jan 2010 14:28:36 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) From: Olaf Kolkman Content-Type: multipart/signed; boundary=Apple-Mail-14-157991379; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 21 Jan 2010 14:28:36 +0100 Message-Id: To: dnsop WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [213.154.224.1]); Thu, 21 Jan 2010 14:28:36 +0100 (CET) Subject: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 13:28:44 -0000 --Apple-Mail-14-157991379 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ = has the open issues listed and a per issue highlight of their history. This issue is captured in =20 = http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequenc= y current content of that page is replicated below. I welcome substantive discussion on-list while I'd be happy to receive = editorial comments off-list=20 If the chair believes the current text captures consensus I will move = this issue to the closed issues list. --Olaf $Id: ZSK-roll-frequency 31 2009-10-07 08:19:53Z olaf $ 2008090101 ZSK-roll-frequency EKR/ Paul Hoffman Added: 7 Oct 2009 =20 See: = http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.ht= ml Rfc4641 argues for frequent ZSK rollovers, the argument therein is based on operational arguments that are (implicitly) based on operator acces to private keys and/or the timeline in which changes in which the (zone) operator may need to be replaced. EKRs argument is based on cryptographic strength and argues another = view. The current considerations need to be made more explicit. Resolution: Added the following paragraph to section 3.3: The motivation for having the ZSK's effectivity period shorter than the KSK's effectivity period is rooted in the operational consideration that it is more likely that operators have more frequent read access to the ZSK than to the KSK. If ZSK's are maintained on cryptographic Hardware Security Modules (HSM) than the motivation to have different key effectivity periods is weakend. ________________________________________________________=20 Olaf M. Kolkman NLnet Labs Science Park 140,=20 http://www.nlnetlabs.nl/ 1098 XG Amsterdam --Apple-Mail-14-157991379 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwbqdTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA1MjUwODQ4MTJaFw0x MTA1MjUwODQ4MTJaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQCLpawAoUQAxivf6blyMswVokRmDl2JGEbtmEu8j0h1BVOlGh6hlI8WaeWy 3x2jJ9uun3VK6oYnHy45ez+dUDjBLjOZdAgwFg225lm1OPdmisghDDVwCIiEogHPqmJtvKYMFoPF 3iFUambJDoQF8DeVeg8ctDvsxsaVGjA8OrMpo0K4I11vnNbCLv7mWCjnaZWt/6Y6TD8ErHQl5dmI rpsHmEZx1/nsocdPkZGRA4QVf1omYHUNs79DtxpYdGKHoorpBNzlzIIjpceiqeOeykoDeYLTZX2G c7Mh4Gdj2MHFqZucxV1cHibb8XKv8ebaGltMV5SrciqRn8yFXmiyTvmId6myNXLiOx+VJiGbLSS3 TltM/kf7UejXeEHulEKufU6Ya6EfH7W2/spTayYCauyLljOjE2Ey5A4oIoJV9eY64OCDuLF2nmGR jOh3JB9nGkZIPhmTUwGZnMELLhzKz+eOZoulM4tXH6KEubed1shQEq1dkJ+tFtRS3Lm+vLCKWvVo 1iZScqPaQf9riPApAVrL+3Wat0p/jtCk5gLBF02uTiWvT2t4ZfSHMEBXR7CvVm58etRQuyZSMHyz UQC4wkDvCeVawNRCZjq6wWdvx5hmr2JeDSkkRtSZ/Fa1WXf26b3BZugI75p5JXafbWdOTRpNc8M5 YMk7tx29ZG3u0qODgDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMG6nUwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwMTIxMTMyODM2WjAj BgkqhkiG9w0BCQQxFgQUStYJy6rn8ZJQLT7UVkyCXm2VnoEwgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBup1MIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBup1MA0GCSqGSIb3 DQEBAQUABIIBADy60jrVyn4rGnSBi3y3igwZf7SsyAxNpTF0MSgUlERIQ58puIqji7g67X6omDT0 1g1Om/b0WWYDVsvG7HXJEc/sysNiYPsquGzixH2KC/MRE5sbhb5ZRqyx1ijfuuOTXPWOIBeePRd4 jyMYjgFLCD6GdMZrRYuZ558nEs8B0WMUn8TRBL66aRKD0cZ2ttzffjyTo0CAgXjHibiFrlivjFTw Snkqn3gCddGbGpmu5E0zhWbfieHIyv+Z0m0lFP9Yyy5RwPDTX38KvrVQxfzAjOIGJADqILrA7tiv KBKrpIR6NguQj0o4FRc71En+POF4huRBku1tRfur57jDiydSX/UAAAAAAAA= --Apple-Mail-14-157991379-- From ekr@rtfm.com Thu Jan 21 05:34:28 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 218133A6989 for ; Thu, 21 Jan 2010 05:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3K4H1wUqeJgJ for ; Thu, 21 Jan 2010 05:34:26 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id AF7243A69DC for ; Thu, 21 Jan 2010 05:34:26 -0800 (PST) Received: by yxe30 with SMTP id 30so2831844yxe.29 for ; Thu, 21 Jan 2010 05:34:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.201.9 with SMTP id y9mr1455528agf.33.1264080859378; Thu, 21 Jan 2010 05:34:19 -0800 (PST) In-Reply-To: References: Date: Thu, 21 Jan 2010 05:34:18 -0800 Message-ID: From: Eric Rescorla To: Olaf Kolkman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsop WG Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 13:34:28 -0000 I'm not really an active member of the WG, so I certainly wouldn't say that my position has much of an affect on consensus, but I'm unconvinced by the argument offered below. Sure, the ZSK is at greater risk because operators have access to it, but so what? If an operator actually steals the key (or, say, is fired), you change the key then. However, given that you allow the operator to sign stuff with the key as long as he's employed, I don't see how repeatedly changing it during that period offers much value at all. -Ekr On Thu, Jan 21, 2010 at 5:28 AM, Olaf Kolkman wrote: > > > As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ = has the open issues listed and a per issue highlight of their history. > > This issue is captured in > http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequen= cy > current content of that page is replicated below. > > I welcome substantive discussion on-list while I'd be happy to receive ed= itorial comments off-list > > If the chair believes the current text captures consensus I will move thi= s issue to the closed issues list. > > --Olaf > > > $Id: ZSK-roll-frequency 31 2009-10-07 08:19:53Z olaf $ > 2008090101 > =A0 ZSK-roll-frequency > =A0 EKR/ Paul Hoffman > =A0 Added: 7 Oct 2009 > > See: > http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.h= tml > > > Rfc4641 argues for frequent ZSK rollovers, the argument therein is > based on operational arguments that are (implicitly) based on operator > acces to private keys and/or the timeline in which changes in which > the (zone) operator may need to be replaced. > > EKRs argument is based on cryptographic strength and argues another view. > > The current considerations need to be made more explicit. > > Resolution: > > > Added the following paragraph to section 3.3: > > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0The motivation for having the ZSK's effectivity period > =A0 =A0 =A0 =A0 =A0shorter than the KSK's effectivity period is rooted in= the > =A0 =A0 =A0 =A0 =A0operational consideration that it is more likely that > =A0 =A0 =A0 =A0 =A0operators have more frequent read access to the ZSK th= an to > =A0 =A0 =A0 =A0 =A0the KSK. If ZSK's are maintained on cryptographic Hard= ware > =A0 =A0 =A0 =A0 =A0Security Modules (HSM) than the motivation to have dif= ferent > =A0 =A0 =A0 =A0 =A0key effectivity periods is weakend. > > =A0 =A0 =A0 =A0 > > ________________________________________________________ > > Olaf M. Kolkman =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NLnet Labs > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Science Park 140, > http://www.nlnetlabs.nl/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 1098 XG Amsterdam > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > From scott.rose@nist.gov Thu Jan 21 06:10:18 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFAF53A683C for ; Thu, 21 Jan 2010 06:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 TnWRocpChMqA for ; Thu, 21 Jan 2010 06:10:16 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id AE12B3A680D for ; Thu, 21 Jan 2010 06:10:16 -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 o0LE9qkQ022878; Thu, 21 Jan 2010 09:09:52 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Thu, 21 Jan 2010 09:09:37 -0500 From: "Rose, Scott W." To: Eric Rescorla , Olaf Kolkman Date: Thu, 21 Jan 2010 09:09:50 -0500 Thread-Topic: [DNSOP] rfc4641bis: ZSK-roll-frequency Thread-Index: AcqanogEpajJ8MAIQDyjZK+RlxYT7gABN0UY Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Cc: dnsop WG Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 14:10:18 -0000 Perhaps the wording is a bit incorrect in that it an insider attack (the admin accessing the key) is not the biggest threat. The ZSK is accessed more often and if it isn't on an HSM (or similar), there could be a risk that it could be exposed by someone other than the responsible DNS admin. O= f course the use of an HSM minimizes this risk. How about this as suggested text? =A0 =A0 =A0 =A0The motivation for having the ZSK's effectivity period =A0 =A0 =A0 =A0shorter than the KSK's effectivity period is rooted in the =A0 =A0 =A0 =A0operational consideration that the ZSK may be at more risk of exposure as the ZSK is often used more frequently (e.g. zone data updates, etc.). If ZSK's are maintained on cryptographic Hardware Security Modules (HSM) than the motivation to have different=A0key effectivity periods is weakend. Scott On 1/21/10 8:34 AM, "Eric Rescorla" wrote: > I'm not really an active member of the WG, so I certainly wouldn't say th= at > my position has much of an affect on consensus, but I'm unconvinced > by the argument offered below. >=20 > Sure, the ZSK is at greater risk because operators have access to it, but > so what? If an operator actually steals the key (or, say, is fired), you > change the key then. However, given that you allow the operator to sign > stuff with the key as long as he's employed, I don't see how repeatedly > changing it during that period offers much value at all. >=20 > -Ekr >=20 >=20 > On Thu, Jan 21, 2010 at 5:28 AM, Olaf Kolkman wrote: >>=20 >>=20 >> As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/= has >> the open issues listed and a per issue highlight of their history. >>=20 >> This issue is captured in >> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-freque= ncy >> current content of that page is replicated below. >>=20 >> I welcome substantive discussion on-list while I'd be happy to receive >> editorial comments off-list >>=20 >> If the chair believes the current text captures consensus I will move th= is >> issue to the closed issues list. >>=20 >> --Olaf >>=20 >>=20 >> $Id: ZSK-roll-frequency 31 2009-10-07 08:19:53Z olaf $ >> 2008090101 >> =A0 ZSK-roll-frequency >> =A0 EKR/ Paul Hoffman >> =A0 Added: 7 Oct 2009 >>=20 >> See: >> http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.= html >>=20 >>=20 >> Rfc4641 argues for frequent ZSK rollovers, the argument therein is >> based on operational arguments that are (implicitly) based on operator >> acces to private keys and/or the timeline in which changes in which >> the (zone) operator may need to be replaced. >>=20 >> EKRs argument is based on cryptographic strength and argues another view= . >>=20 >> The current considerations need to be made more explicit. >>=20 >> Resolution: >>=20 >>=20 >> Added the following paragraph to section 3.3: >>=20 >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0The motivation for having the ZSK's effectivity perio= d >> =A0 =A0 =A0 =A0 =A0shorter than the KSK's effectivity period is rooted i= n the >> =A0 =A0 =A0 =A0 =A0operational consideration that it is more likely that >> =A0 =A0 =A0 =A0 =A0operators have more frequent read access to the ZSK t= han to >> =A0 =A0 =A0 =A0 =A0the KSK. If ZSK's are maintained on cryptographic Har= dware >> =A0 =A0 =A0 =A0 =A0Security Modules (HSM) than the motivation to have di= fferent >> =A0 =A0 =A0 =A0 =A0key effectivity periods is weakend. >>=20 >> =A0 =A0 =A0 =A0 >>=20 >> ________________________________________________________ >>=20 >> Olaf M. Kolkman =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NLnet Lab= s >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Science Park 140, >> http://www.nlnetlabs.nl/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 1098 XG Amsterdam >>=20 >>=20 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >>=20 >>=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scottr@nist.gov ph: +1 301-975-8439 Google Voice: +1-571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From olaf@nlnetlabs.nl Thu Jan 21 07:06:14 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06233A68F4 for ; Thu, 21 Jan 2010 07:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LfdveCGsnLrx for ; Thu, 21 Jan 2010 07:06:13 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id B16883A69C3 for ; Thu, 21 Jan 2010 07:06:12 -0800 (PST) Received: from [IPv6:2001:7b8:206:1:226:bbff:fe0e:7cc7] ([IPv6:2001:7b8:206:1:226:bbff:fe0e:7cc7]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0LF66La054739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Jan 2010 16:06:06 +0100 (CET) (envelope-from olaf@nlnetlabs.nl) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Olaf Kolkman In-Reply-To: Date: Thu, 21 Jan 2010 16:06:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <733B1414-CADE-481B-9FF5-CF7E2DCE402B@nlnetlabs.nl> References: To: "Rose, Scott W." X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 21 Jan 2010 16:06:06 +0100 (CET) Cc: Eric Rescorla , dnsop WG Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 15:06:14 -0000 On Jan 21, 2010, at 3:09 PM, Rose, Scott W. wrote: > Perhaps the wording is a bit incorrect in that it an insider attack = (the > admin accessing the key) is not the biggest threat. The ZSK is = accessed > more often and if it isn't on an HSM (or similar), there could be a = risk > that it could be exposed by someone other than the responsible DNS = admin. Of > course the use of an HSM minimizes this risk. >=20 > How about this as suggested text? >=20 > > The motivation for having the ZSK's effectivity period > shorter than the KSK's effectivity period is rooted in the > operational consideration that the ZSK may be at more > risk of exposure as the ZSK is often used more frequently > (e.g. zone data updates, etc.). If ZSK's are maintained on > cryptographic Hardware Security Modules (HSM) than the > motivation to have different key effectivity periods is > weakend. > >=20 I understand EKR's remark (thanks) in addition to the improvement Scott = suggested there is the argument that if a rollover remains a special = event it is bound to go wrong, while if it is part of regular = operational procedure the operators do not have to go through the = learning curve. That argument works, but not in the case that EKR = brought up, if _the_ operator gets sacked the rollover done by the new = one is the first one that new operator does, she wouldn't have the = benefit of operational routine. --Olaf [nothing below, only context] > Scott > On 1/21/10 8:34 AM, "Eric Rescorla" wrote: >=20 >> I'm not really an active member of the WG, so I certainly wouldn't = say that >> my position has much of an affect on consensus, but I'm unconvinced >> by the argument offered below. >>=20 >> Sure, the ZSK is at greater risk because operators have access to it, = but >> so what? If an operator actually steals the key (or, say, is fired), = you >> change the key then. However, given that you allow the operator to = sign >> stuff with the key as long as he's employed, I don't see how = repeatedly >> changing it during that period offers much value at all. >>=20 >> -Ekr >>=20 >>=20 >> On Thu, Jan 21, 2010 at 5:28 AM, Olaf Kolkman = wrote: >>>=20 >>>=20 >>> As a reminder: = http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has >>> the open issues listed and a per issue highlight of their history. >>>=20 >>> This issue is captured in >>> = http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequenc= y >>> current content of that page is replicated below. >>>=20 >>> I welcome substantive discussion on-list while I'd be happy to = receive >>> editorial comments off-list >>>=20 >>> If the chair believes the current text captures consensus I will = move this >>> issue to the closed issues list. >>>=20 >>> --Olaf >>>=20 >>>=20 >>> $Id: ZSK-roll-frequency 31 2009-10-07 08:19:53Z olaf $ >>> 2008090101 >>> ZSK-roll-frequency >>> EKR/ Paul Hoffman >>> Added: 7 Oct 2009 >>>=20 >>> See: >>> = http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.ht= ml >>>=20 >>>=20 >>> Rfc4641 argues for frequent ZSK rollovers, the argument therein is >>> based on operational arguments that are (implicitly) based on = operator >>> acces to private keys and/or the timeline in which changes in which >>> the (zone) operator may need to be replaced. >>>=20 >>> EKRs argument is based on cryptographic strength and argues another = view. >>>=20 >>> The current considerations need to be made more explicit. >>>=20 >>> Resolution: >>>=20 >>>=20 >>> Added the following paragraph to section 3.3: >>>=20 >>> >>> The motivation for having the ZSK's effectivity period >>> shorter than the KSK's effectivity period is rooted in the >>> operational consideration that it is more likely that >>> operators have more frequent read access to the ZSK than to >>> the KSK. If ZSK's are maintained on cryptographic Hardware >>> Security Modules (HSM) than the motivation to have = different >>> key effectivity periods is weakend. >>>=20 >>> >>>=20 >>> ________________________________________________________ >>>=20 >>> Olaf M. Kolkman NLnet Labs >>> Science Park 140, >>> http://www.nlnetlabs.nl/ 1098 XG Amsterdam >>>=20 >>>=20 >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>>=20 >>>=20 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >>=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Scott Rose > NIST > scottr@nist.gov > ph: +1 301-975-8439 > Google Voice: +1-571-249-3671 >=20 > http://www.dnsops.gov/ > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 ________________________________________________________=20 Olaf M. Kolkman NLnet Labs Science Park 140,=20 http://www.nlnetlabs.nl/ 1098 XG Amsterdam From Ed.Lewis@neustar.biz Thu Jan 21 07:32:12 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8763A68FA for ; Thu, 21 Jan 2010 07:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=-0.627, 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 JYYz0L1erXAs for ; Thu, 21 Jan 2010 07:32:10 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 3C60F3A6407 for ; Thu, 21 Jan 2010 07:32:06 -0800 (PST) Received: from [10.31.200.228] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0LFVxMU008421; Thu, 21 Jan 2010 10:31:59 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 21 Jan 2010 10:14:41 -0500 To: "Rose, Scott W." From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: Eric Rescorla , dnsop WG Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 15:32:12 -0000 IMHO, the suggested wording is backwards. It's not that the ZSK effectivity period is shorter than the KSK's, the KSK effectivity period is longer than the ZSK's. The reason is operational, not cryptographic. Way back in time (circa '99-'02)...consensus of those participating in workshops was that it was wise to change the ZSK a lot but we found it to be a pain to have to wait to tell the workshop coordinator/registry operator to get them to update the key in the workshop zone. So we invented the idea of ZSK/KSK. We just wanted to have a KSK that lasted longer than a ZSK. We rationalized that a KSK would last longer because 1) it generated only a few signatures over the same time period compared to a ZSK, 2) because it was only needed when the key set changed, it was open to the air less frequently, and 3) since it was used only to validate the key set, it could be longer (thus taking longer to do the signature validation) but not needed in every validation (of records in a particular zone). Because it was longer lasting we didn't have to stop and get the attention of the parent so frequently. (Reason 3 is why so many TLDs now have the KSK twice as long as the ZSK.) I'm not saying that any of the above was smart wrt cryptography - crypto-experts never made any statements to us back then. The KSK being longer than the ZSK was for operational convenience. Also, what was not anticipated was the coming of automated provisioning, like that enabled by EPP, in reducing the latency of getting the parent to make a change. (Around 2000, we envisioned parent zone updates on the order of 1/day or n/week, not every 15 minutes.) At the time too - HSMs didn't exist in our world, and we still thought that all signing would be done on a machine with an air-gap to the Internet. So many assumptions have changed...but the idea of KSK/ZSK hasn't. If I were to fit this into the text below... # # The motivation for having the KSK's effectivity period # longer than the ZSK's effectivity period is rooted in the # operational consideration that a change in the KSK involves # interaction with an external entity, usually the parent zone # or possibly a trust anchor repository, and this interaction # is anticipated to have significant latency (including the # need to verify the other party has made the necessary change. # At 9:09 -0500 1/21/10, Rose, Scott W. wrote: >Perhaps the wording is a bit incorrect in that it an insider attack (the >admin accessing the key) is not the biggest threat. The ZSK is accessed >more often and if it isn't on an HSM (or similar), there could be a risk >that it could be exposed by someone other than the responsible DNS admin. Of >course the use of an HSM minimizes this risk. > >How about this as suggested text? > > > The motivation for having the ZSK's effectivity period > shorter than the KSK's effectivity period is rooted in the > operational consideration that the ZSK may be at more > risk of exposure as the ZSK is often used more frequently > (e.g. zone data updates, etc.). If ZSK's are maintained on > cryptographic Hardware Security Modules (HSM) than the > motivation to have different key effectivity periods is > weakend. > > >Scott >On 1/21/10 8:34 AM, "Eric Rescorla" wrote: > >> I'm not really an active member of the WG, so I certainly wouldn't say that >> my position has much of an affect on consensus, but I'm unconvinced >> by the argument offered below. >> >> Sure, the ZSK is at greater risk because operators have access to it, but >> so what? If an operator actually steals the key (or, say, is fired), you >> change the key then. However, given that you allow the operator to sign >> stuff with the key as long as he's employed, I don't see how repeatedly >> changing it during that period offers much value at all. >> >> -Ekr >> >> >> On Thu, Jan 21, 2010 at 5:28 AM, Olaf Kolkman wrote: >>> >>> >>> As a reminder: >>>http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has >>> the open issues listed and a per issue highlight of their history. >>> >>> This issue is captured in >>> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency >>> current content of that page is replicated below. >>> >>> I welcome substantive discussion on-list while I'd be happy to receive >>> editorial comments off-list >>> >>> If the chair believes the current text captures consensus I will move this >>> issue to the closed issues list. >>> >>> --Olaf >>> >>> >>> $Id: ZSK-roll-frequency 31 2009-10-07 08:19:53Z olaf $ >>> 2008090101 >>> ZSK-roll-frequency >>> EKR/ Paul Hoffman >>> Added: 7 Oct 2009 >>> >>> See: >>> >>>http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html >>> >>> >>> Rfc4641 argues for frequent ZSK rollovers, the argument therein is >>> based on operational arguments that are (implicitly) based on operator >>> acces to private keys and/or the timeline in which changes in which >>> the (zone) operator may need to be replaced. >>> >>> EKRs argument is based on cryptographic strength and argues another view. >>> >>> The current considerations need to be made more explicit. >>> >>> Resolution: >>> >>> >>> Added the following paragraph to section 3.3: >>> >>> >>> The motivation for having the ZSK's effectivity period >>> shorter than the KSK's effectivity period is rooted in the >>> operational consideration that it is more likely that >>> operators have more frequent read access to the ZSK than to >>> the KSK. If ZSK's are maintained on cryptographic Hardware >>> Security Modules (HSM) than the motivation to have different >>> key effectivity periods is weakend. >>> >>> >>> >>> ________________________________________________________ >>> >>> Olaf M. Kolkman NLnet Labs >>> Science Park 140, >>> http://www.nlnetlabs.nl/ 1098 XG Amsterdam >>> >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >>> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > >=================================== >Scott Rose >NIST >scottr@nist.gov >ph: +1 301-975-8439 >Google Voice: +1-571-249-3671 > >http://www.dnsops.gov/ >=================================== > > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From ajs@shinkuro.com Thu Jan 21 07:39:36 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D53B3A6807 for ; Thu, 21 Jan 2010 07:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.117 X-Spam-Level: X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=-0.518, 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 20DAFDP2GGPb for ; Thu, 21 Jan 2010 07:39:35 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id BF4B13A6407 for ; Thu, 21 Jan 2010 07:39:35 -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 EACFD2FE8CA1 for ; Thu, 21 Jan 2010 15:39:30 +0000 (UTC) Date: Thu, 21 Jan 2010 10:39:29 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20100121153929.GF81286@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: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 15:39:36 -0000 On Thu, Jan 21, 2010 at 10:14:41AM -0500, Edward Lewis wrote: > So many assumptions have changed...but the idea of KSK/ZSK hasn't. Maybe this is the problem? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ed.Lewis@neustar.biz Thu Jan 21 07:49:04 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70CB93A6934 for ; Thu, 21 Jan 2010 07:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.07 X-Spam-Level: X-Spam-Status: No, score=-3.07 tagged_above=-999 required=5 tests=[AWL=-0.471, 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 oTuIGbckdtDy for ; Thu, 21 Jan 2010 07:49:03 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id A5FA43A690D for ; Thu, 21 Jan 2010 07:49:01 -0800 (PST) Received: from [10.31.200.228] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0LFmu5P008615; Thu, 21 Jan 2010 10:48:56 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100121153929.GF81286@shinkuro.com> References: <20100121153929.GF81286@shinkuro.com> Date: Thu, 21 Jan 2010 10:48:52 -0500 To: Andrew Sullivan From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: dnsop@ietf.org Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 15:49:04 -0000 At 10:39 -0500 1/21/10, Andrew Sullivan wrote: >On Thu, Jan 21, 2010 at 10:14:41AM -0500, Edward Lewis wrote: >> So many assumptions have changed...but the idea of KSK/ZSK hasn't. > >Maybe this is the problem? Problem? Not everyone has an automated registration interface (making that a reason to have a KSK/ZSK still hold). And the key word above is "assumptions" - once we know for a fact that a ZSK of 1024 bits is good for a year no matter how much it is used and that it's okay to roll it, etc., then we might be able to drop the KSK idea. So long as it hasn't already been burned into operational (institutional) practices. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From ajs@shinkuro.com Thu Jan 21 08:02:33 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E263A690D for ; Thu, 21 Jan 2010 08:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=-0.501, 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 Z1MXS3JL4-6u for ; Thu, 21 Jan 2010 08:02:29 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 6A2163A68DB for ; Thu, 21 Jan 2010 08:02:29 -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 EBBB32FE8CA1 for ; Thu, 21 Jan 2010 16:02:24 +0000 (UTC) Date: Thu, 21 Jan 2010 11:02:23 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20100121160220.GH81286@shinkuro.com> References: <20100121153929.GF81286@shinkuro.com> 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: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 16:02:33 -0000 On Thu, Jan 21, 2010 at 10:48:52AM -0500, Edward Lewis wrote: > At 10:39 -0500 1/21/10, Andrew Sullivan wrote: >> >> Maybe this is the problem? > > Problem? It that it seems to be the occasion of a lot of disagreement with the document. That is, in many cases, perhaps the advice should simply be, "The ZSK/KSK split is useful in some circumstances, but for most applications one key is sufficient." Or some such. I'm not proposing this text, I'm asking. > Not everyone has an automated registration interface (making that a > reason to have a KSK/ZSK still hold). Sure, but this may well be the exception and not the rule. > And the key word above is "assumptions" - once we know for a fact that a > ZSK of 1024 bits is good for a year no matter how much it is used and Nobody can ever know that for a fact, because it would require proving impossible that such a key could be cracked. Predictions of future impossibility are hard to prove. This is a question of trade-off, not facts, and one of the questions is the degree to which two keys themselves introduce risks that aren't offset by the gains they might produce. I simply don't know the answer, but it seems to me that EKR is asking the right question. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ed.Lewis@neustar.biz Thu Jan 21 08:14:40 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F883A69F7 for ; Thu, 21 Jan 2010 08:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.023 X-Spam-Level: X-Spam-Status: No, score=-3.023 tagged_above=-999 required=5 tests=[AWL=-0.424, 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 7gdz9V4-rK9n for ; Thu, 21 Jan 2010 08:14:38 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 61DC03A6822 for ; Thu, 21 Jan 2010 08:14:36 -0800 (PST) Received: from [10.31.200.228] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0LGERTd008884; Thu, 21 Jan 2010 11:14:28 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100121160220.GH81286@shinkuro.com> References: <20100121153929.GF81286@shinkuro.com> <20100121160220.GH81286@shinkuro.com> Date: Thu, 21 Jan 2010 11:14:25 -0500 To: dnsop@ietf.org From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 16:14:40 -0000 At 11:02 -0500 1/21/10, Andrew Sullivan wrote: >> Not everyone has an automated registration interface (making that a >> reason to have a KSK/ZSK still hold). > >Sure, but this may well be the exception and not the rule. And I've heard the opposite. "automated-registry[0]"-run zones are in the minority. (I.e., second level domains, third-level domains, etc...) [0] Not just EPP-using-registries. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From scott.rose@nist.gov Thu Jan 21 08:20:18 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2BAE3A6A66 for ; Thu, 21 Jan 2010 08:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 lVuAtrkok1j4 for ; Thu, 21 Jan 2010 08:20:17 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 94B503A6A74 for ; Thu, 21 Jan 2010 08:20:17 -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 o0LGK5RJ017106 for ; Thu, 21 Jan 2010 11:20:05 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Thu, 21 Jan 2010 11:19:50 -0500 From: "Rose, Scott W." To: "dnsop@ietf.org" Date: Thu, 21 Jan 2010 11:20:04 -0500 Thread-Topic: [DNSOP] rfc4641bis: ZSK-roll-frequency Thread-Index: AcqasV8bYnEF5LPuQkar7AB0vekGdAABDeBp Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 16:20:18 -0000 On 1/21/10 10:48 AM, "Edward Lewis" wrote: > At 10:39 -0500 1/21/10, Andrew Sullivan wrote: >> On Thu, Jan 21, 2010 at 10:14:41AM -0500, Edward Lewis wrote: >>> So many assumptions have changed...but the idea of KSK/ZSK hasn't. >>=20 >> Maybe this is the problem? >=20 > Problem? >=20 > Not everyone has an automated registration interface (making that a > reason to have a KSK/ZSK still hold). >=20 And experience has shown that different assumptions of how best to automate things also cause problems. So one side may be reduced to doing things manually (and usually it's the registrant) when the registrant and registra= r used different implementations. On the larger issue - It may be easier to say "The KSK is larger/longer lived than the ZSK because..." than "The ZSK is smaller/shorter lived than the KSK because..." and give the reasons. Scott=20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scottr@nist.gov ph: +1 301-975-8439 Google Voice: +1-571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From ajs@shinkuro.com Thu Jan 21 08:24:15 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0165328C16A for ; Thu, 21 Jan 2010 08:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[AWL=-0.485, 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 5oUMruKe8JXo for ; Thu, 21 Jan 2010 08:24:14 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id BB4023A6822 for ; Thu, 21 Jan 2010 08:24:10 -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 579502FE8CDE for ; Thu, 21 Jan 2010 16:24:06 +0000 (UTC) Date: Thu, 21 Jan 2010 11:24:04 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20100121162404.GJ81286@shinkuro.com> References: <20100121153929.GF81286@shinkuro.com> <20100121160220.GH81286@shinkuro.com> 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: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 16:24:15 -0000 On Thu, Jan 21, 2010 at 11:14:25AM -0500, Edward Lewis wrote: > At 11:02 -0500 1/21/10, Andrew Sullivan wrote: >> Sure, but this may well be the exception and not the rule. > > And I've heard the opposite. "automated-registry[0]"-run zones are in > the minority. (I.e., second level domains, third-level domains, etc...) Sure. I think the problem here is that we don't know. I have no clue how many systems are updated exclusively by Dynamic Update vs. by someone opening the zonefile in vi. I don't think anyone else knows, either: the scope of DNS operations is far too widely dispersed for anyone to have done anything like a survey. Therefore, the best we can do is recomment the techniques appropriate to different circumstances. It seems to me that one such technique is, "If it's easier for you to transmit a new DS/DNSKEY than it is for you to roll a KSK, then you don't need a separate KSK. Just roll the one key and be done with it." A separate question, then, is whether the operational regularity that comes from exercising the above technique all the time outweighs the risks associated with frequent key rolls that result from getting the timing wrong. (My personal opinion is a cautious "yes", but I don't know how firmly I hold that view.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From fanf2@hermes.cam.ac.uk Thu Jan 21 08:28:22 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA913A68D9 for ; Thu, 21 Jan 2010 08:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 p+dgPs+8Htly for ; Thu, 21 Jan 2010 08:28:21 -0800 (PST) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by core3.amsl.com (Postfix) with ESMTP id BC2F83A681E for ; Thu, 21 Jan 2010 08:28:21 -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]:48379) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1NXztG-0006Op-O2 (Exim 4.70) (return-path ); Thu, 21 Jan 2010 16:28:14 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1NXztG-000650-EB (Exim 4.67) (return-path ); Thu, 21 Jan 2010 16:28:14 +0000 Date: Thu, 21 Jan 2010 16:28:14 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Olaf Kolkman In-Reply-To: <733B1414-CADE-481B-9FF5-CF7E2DCE402B@nlnetlabs.nl> Message-ID: References: <733B1414-CADE-481B-9FF5-CF7E2DCE402B@nlnetlabs.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Eric Rescorla , dnsop WG , "Rose, Scott W." Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 16:28:23 -0000 On Thu, 21 Jan 2010, Olaf Kolkman wrote: > > I understand EKR's remark (thanks) in addition to the improvement Scott > suggested there is the argument that if a rollover remains a special > event it is bound to go wrong, while if it is part of regular > operational procedure the operators do not have to go through the > learning curve. That argument works, but not in the case that EKR > brought up, if _the_ operator gets sacked the rollover done by the new > one is the first one that new operator does, she wouldn't have the > benefit of operational routine. Operational routines like this will be automated. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From ajs@shinkuro.com Thu Jan 21 08:40:09 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D389C3A6818 for ; Thu, 21 Jan 2010 08:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.069 X-Spam-Level: X-Spam-Status: No, score=-3.069 tagged_above=-999 required=5 tests=[AWL=-0.470, 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 9HBlJGSnmCMB for ; Thu, 21 Jan 2010 08:40:07 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 58A853A69DB for ; Thu, 21 Jan 2010 08:40:07 -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 81D742FE8CE7 for ; Thu, 21 Jan 2010 16:40:02 +0000 (UTC) Date: Thu, 21 Jan 2010 11:40:00 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20100121164000.GM81286@shinkuro.com> References: <733B1414-CADE-481B-9FF5-CF7E2DCE402B@nlnetlabs.nl> 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: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 16:40:09 -0000 On Thu, Jan 21, 2010 at 04:28:14PM +0000, Tony Finch wrote: > Operational routines like this will be automated. I wish I believed that was universally true. It isn't. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From paul.hoffman@vpnc.org Thu Jan 21 08:55:42 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03A93A68B3 for ; Thu, 21 Jan 2010 08:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.018 X-Spam-Level: X-Spam-Status: No, score=-6.018 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 MJTNfmTfStGy for ; Thu, 21 Jan 2010 08:55:42 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2736C3A6818 for ; Thu, 21 Jan 2010 08:55:41 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0LGtZkG056399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 09:55:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100121160220.GH81286@shinkuro.com> References: <20100121153929.GF81286@shinkuro.com> <20100121160220.GH81286@shinkuro.com> Date: Thu, 21 Jan 2010 08:55:33 -0800 To: Andrew Sullivan , dnsop@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 16:55:42 -0000 At 11:02 AM -0500 1/21/10, Andrew Sullivan wrote: >On Thu, Jan 21, 2010 at 10:48:52AM -0500, Edward Lewis wrote: > > And the key word above is "assumptions" - once we know for a fact that a >> ZSK of 1024 bits is good for a year no matter how much it is used and > >Nobody can ever know that for a fact, because it would require proving >impossible that such a key could be cracked. Predictions of future >impossibility are hard to prove. But we *can* assume that there are a lot of 1024-bit keys in use that are much more valuable than the most valuable DNSSEC 1024-bit key. Thus, as public analysis gets better, we are likely to hear about it. Even if the first attacks from private crackers, we will hear about them. --Paul Hoffman, Director --VPN Consortium From ajs@shinkuro.com Thu Jan 21 08:58:11 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB6223A6A3B for ; Thu, 21 Jan 2010 08:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[AWL=-0.457, 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 byU0urJOHHe2 for ; Thu, 21 Jan 2010 08:58:11 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 3F1CE3A6855 for ; Thu, 21 Jan 2010 08:58:11 -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 CC1522FE8CA1 for ; Thu, 21 Jan 2010 16:58:06 +0000 (UTC) Date: Thu, 21 Jan 2010 11:58:05 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20100121165804.GP81286@shinkuro.com> References: <20100121153929.GF81286@shinkuro.com> <20100121160220.GH81286@shinkuro.com> 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: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 16:58:12 -0000 On Thu, Jan 21, 2010 at 08:55:33AM -0800, Paul Hoffman wrote: > > But we *can* assume that there are a lot of 1024-bit keys in use > that are much more valuable than the most valuable DNSSEC 1024-bit > key. Thus, as public analysis gets better, we are likely to hear > about it. Even if the first attacks from private crackers, we will > hear about them. I fully agree. I just want to make sure we're not holding ourselves to an operational standard that is just impossible to reach. If we want "proof" and "facts" about whether something won't ever be compromised, it's not going to happen (so I'm very keen we not put anything resembling such language in any draft). That's all I was saying. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From richard.lamb@icann.org Thu Jan 21 09:22:50 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801193A6A8C for ; Thu, 21 Jan 2010 09:22:50 -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 mbN4ezEidD56 for ; Thu, 21 Jan 2010 09:22:49 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 000413A6A2F for ; Thu, 21 Jan 2010 09:22:48 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 21 Jan 2010 09:22:45 -0800 From: Richard Lamb To: Olaf Kolkman , dnsop WG Date: Thu, 21 Jan 2010 09:22:50 -0800 Thread-Topic: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt Thread-Index: Acqajs4s/TQbFF1PRdy3mjkl3EK3ywALI5Gw Message-ID: <05B243F724B2284986522B6ACD0504D7D2FF373137@EXVPMBX100-1.exc.icann.org> References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl> In-Reply-To: <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl> 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: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 17:22:50 -0000 > -----Original Message----- > From: dnsop-bounces@ietf.org [mailto:dnsop-bounces@ietf.org] On Behalf > Of Olaf Kolkman > Sent: Thursday, January 21, 2010 3:42 AM > To: dnsop WG > Subject: Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop- > rfc4641bis-01.txt >=20 >=20 > In trying to get a reasonable version 2 out of the door before Anaheim > I am trying to identify and where possibly close open issues. >=20 > As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open- > issues/ has the open issues listed and a per issue highlight of their > history. >=20 > This thread, about the use of HSMs, is captured in > http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/HSMs the > content of that page is replicated below. >=20 > I believe I captured the gist of the discussion in a modified version > of paragraph 3.6 (see below). The first two paragraphs are not > modified, the text starting with "The ideal situation" has been. >=20 > I welcome editorial comments off-list. >=20 > If the chair believes the current text captures consensus I will move > this issue to the closed issues list. >=20 > --Olaf >=20 >=20 >=20 >=20 > $Id: cryptography_flawed 14 2009-02-09 18:54:12Z olaf $ > 20100121 > The use of HSMs > Shane Kerr/Ed Lewis > Added: 21 jan 2010 > http://www.ietf.org/mail-archive/web/dnsop/current/msg07190.html > and > http://www.ietf.org/mail-archive/web/dnsop/current/msg07193.html >=20 > The recommendation to use a HSM is far to strong. Arguments of fate > sharing > and operational overhead are being made on the list. >=20 I agree, but I am a strong believer in market driven decisions so, yes, enc= ouraging people to make their own decisions is my preference too. However I will say that even using a $5 HSM (in the form of a smartcard) fo= rces certain good IT security practices. The guys that developed this indu= stry have really though through process. May be out of scope but: Trust in the KSK must still be earned through vari= ous mechanisms like publicly documented processes, 3rd party auditing, exte= rnal witnesses, key ceremonies. >=20 >=20 >=20 > Discussion: >=20 > From: Shane Kerr > Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-rfc4641bis- > 01.txt > Date: April 21, 2009 1:03:58 PM GMT+02:00 > Cc: dnsop WG >=20 >=20 > I believe the key of the thread is captured in the following quotes: >=20 >=20 > Stephane Bortzmeyer wrote: > > > > But the risk for the key is not only people modifying it, it is > simply > > people *reading* it (a concern which also exists for the database but > > is much less important). > > > > I have no practical experience with HSMs but, in my mind, the > > interesting thing is that they guarantee noone will read the key > > without an authorization (that's quite unlike the database where you > > certainly prefer a few unauthorized looks to a complete loss). >=20 Agreed. Read or in the case of an infrequently used KSK (low number of ZSK= rolls) - make use of the key. > This is the key point IMHO. >=20 > AIUI, the attack vector that HSM are designed to protect is that > someone makes a copy of your key signing material without you knowing > about it. > Once they do that, they can spoof replies until such time as you roll > your key. >=20 > If an unauthorized person modifies the contents of the database backing > your zone, you may or may not know about it, but an observant customer > will at least notice that the data has changed. >=20 > So the two are not totally equivalent. >=20 > Having said that, I agree that HSM hysteria is a bit overblown, and > that the actual DNSSEC signing is very, very unlikely to be the weakest > link in DNS security in any organization. >=20 Agree. >=20 Below looks good. Take my suggestion or leave it. It is only a minor point= and might be implemented on a secured o/s as well. >=20 >=20 > Resolution: >=20 > Following the suggestion from: > From: Peter Koch > Subject: Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop- > rfc4641bis-01.txt > Date: April 27, 2009 1:19:45 PM GMT+02:00 > To: IETF DNSOP WG >=20 > I rewrote the text to highlight the economic tradeoff, the relevant > part of section 3.6 is copied below. >=20 >=20 >=20 > 3.6. Private Key Storage >=20 > It is recommended that, where possible, zone private keys and the > zone file master copy that is to be signed be kept and used in off- > line, non-network-connected, physically secure machines only. > Periodically, an application can be run to add authentication to a > zone by adding RRSIG and NSEC RRs. Then the augmented file can be > transferred. >=20 > When relying on dynamic update to manage a signed zone [11], be > aware > that at least one private key of the zone will have to reside on the > master server. This key is only as secure as the amount of exposure > the server receives to unknown clients and the security of the host. > Although not mandatory, one could administer the DNS in the > following > way. The master that processes the dynamic updates is unavailable > from generic hosts on the Internet, it is not listed in the NS > RRSet, > although its name appears in the SOA RRs MNAME field. The > nameservers in the NS RRSet are able to receive zone updates through > NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This > approach is known as the "hidden master" setup. >=20 > The ideal situation is to have a one-way information flow to the > network to avoid the possibility of tampering from the network. > Keeping the zone master file on-line on the network and simply > cycling it through an off-line signer does not do this. The on-line > version could still be tampered with if the host it resides on is > compromised. For maximum security, the master copy of the zone file > should be off-net and should not be updated based on an unsecured > network mediated communication. >=20 > The ideal situation may not be achievable because of economic > tradeoffs between risks and costs. For instance, keeping a zone > file > off-line is not practical and will increase the costs of operating a > DNS zone. So in practice the machines on which zone files are > maintained will be connected to a network. Operators are advised to > take security measures to shield unauthorized access to the master > copy in order to prevent modification of DNS data before its signed. >=20 > Similarly the choice for storing a private key in a Cryptographic > Hardware Security Module (HSM) will be influenced by tradeoff a > tradeoff between various concerns: >=20 > o The risks that an unauthorized person has unnoticed read-access > to , or can sign with, > the private key >=20 > o The remaining window of opportunity for the attacker. >=20 > o The economic impact of the possible attacks (for a TLD that > impact > will in most cases be higher than for an individual users). >=20 > o The costs of rolling the (compromised) keys: whereby the costs of > roling a ZSK is lowest and the costs of rolling a KSK that is in > wide use as a trust anchor is highest >=20 > o The costs of buying and maintaining an HSM. >=20 > For dynamically updated secured zones [11], both the master copy and > the private key that is used to update signatures on updated RRs > will > need to be on-line. >=20 >=20 >=20 >=20 >=20 > ________________________________________________________ >=20 > Olaf M. Kolkman NLnet Labs > Science Park 140, > http://www.nlnetlabs.nl/ 1098 XG Amsterdam From paul@xelerance.com Thu Jan 21 09:52:55 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F9E3A6AB8 for ; Thu, 21 Jan 2010 09:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 DqPJBY0pBH9J for ; Thu, 21 Jan 2010 09:52:54 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id CF1383A6A21 for ; Thu, 21 Jan 2010 09:52:53 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id D22C4571B3; Thu, 21 Jan 2010 12:52:47 -0500 (EST) Date: Thu, 21 Jan 2010 12:52:47 -0500 (EST) From: Paul Wouters To: Olaf Kolkman In-Reply-To: <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl> Message-ID: References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop WG Subject: Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 17:52:55 -0000 On Thu, 21 Jan 2010, Olaf Kolkman wrote: > In trying to get a reasonable version 2 out of the door before Anaheim I am trying to identify and where possibly close open issues. > > As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has the open issues listed and a per issue highlight of their history. I still don't see any recommendations regarding NSEC vs NSEC3. I mailed you some comments about two IETF's ago I believe. Do you still have that email, or should I try to dig it out? > This thread, about the use of HSMs, is captured in http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/HSMs the content of that page is replicated below. That looks fine to me. Perhaps clarify that the "someone" who could make a copy of your key could be the zone operator, and that in some situations you might want to trust the zone administrator with the ZSK, allow him to use the HSM based KSK, but not give him access to read or copy the private key of the KSK. This would allow one to keep using the KSK even after a zone administrator has left the organisation. Paul From paul@xelerance.com Thu Jan 21 10:03:50 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60D73A684E for ; Thu, 21 Jan 2010 10:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.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 x616TvXUfolS for ; Thu, 21 Jan 2010 10:03:50 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1EA583A6837 for ; Thu, 21 Jan 2010 10:03:50 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id DDDED571B4; Thu, 21 Jan 2010 13:03:45 -0500 (EST) Date: Thu, 21 Jan 2010 13:03:45 -0500 (EST) From: Paul Wouters To: Edward Lewis 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: dnsop WG Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 18:03:51 -0000 On Thu, 21 Jan 2010, Edward Lewis wrote: > If I were to fit this into the text below... > > # > # The motivation for having the KSK's effectivity period > # longer than the ZSK's effectivity period is rooted in the > # operational consideration that a change in the KSK involves > # interaction with an external entity, usually the parent zone > # or possibly a trust anchor repository, and this interaction > # is anticipated to have significant latency (including the > # need to verify the other party has made the necessary change. > # Maybe make it more explicit that an intra-organisation key change can and probably should happen frequently, where-as an inter-organisational key change, because it involves other organisations, is more difficult and should be kept to a minimum? Again, think of a zone administrator who had access to a private ZSK leaving your organisation. It would be a good security policy to rollover the ZSK as part of the procedure of revoking this person's access to the organisation. And a good reason to have an HSM so you do not need to do the same with the KSK. Paul From Ed.Lewis@neustar.biz Thu Jan 21 10:45:54 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598FD3A6823 for ; Thu, 21 Jan 2010 10:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.984 X-Spam-Level: X-Spam-Status: No, score=-2.984 tagged_above=-999 required=5 tests=[AWL=-0.385, 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 63L2NiJZpJTk for ; Thu, 21 Jan 2010 10:45:53 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id CBA9C3A672F for ; Thu, 21 Jan 2010 10:45:52 -0800 (PST) Received: from [10.31.200.228] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0LIjlNb010476; Thu, 21 Jan 2010 13:45:47 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 21 Jan 2010 13:40:03 -0500 To: Paul Wouters From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: dnsop WG , Edward Lewis Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 18:45:54 -0000 At 13:03 -0500 1/21/10, Paul Wouters wrote: >Maybe make it more explicit that an intra-organisation key change can >and probably should happen frequently, where-as an inter-organisational >key change, because it involves other organisations, is more difficult >and should be kept to a minimum? Well, "the motivation" in the historical sense is what I had in mind when writing, as opposed to "the motivation" in the sense of the reason for something. >Again, think of a zone administrator who had access to a private ZSK >leaving your organisation. It would be a good security policy to rollover >the ZSK as part of the procedure of revoking this person's access to >the organisation. And a good reason to have an HSM so you do not need >to do the same with the KSK. I don't get the last sentence of what you wrote. The trouble is, there's no good general statement that can be made here. There are cases in which I would say an HSM is a good thing and there are cases where it is merely window dressing. In places where one might think it is essential are the very places where it might be most optional. If we don't have a HSM and someone who had access to the key leaves, it's not hard for us to (in the future) contact IANA and change our key. While the HSM might prevent any employee's leaving from being a threat, the defense against the threat is cheap (an email/phone call/whatever to IANA). I'm not trying to find excuses for avoiding an HSM. Just pointing out why I can't endorse them as functional necessities. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From ekr@rtfm.com Thu Jan 21 11:06:01 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4447E3A6844 for ; Thu, 21 Jan 2010 11:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD4PV9jB3Klg for ; Thu, 21 Jan 2010 11:06:00 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 435E93A67D3 for ; Thu, 21 Jan 2010 11:06:00 -0800 (PST) Received: by yxe30 with SMTP id 30so305724yxe.29 for ; Thu, 21 Jan 2010 11:05:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.21.25 with SMTP id y25mr1863379agi.19.1264100747278; Thu, 21 Jan 2010 11:05:47 -0800 (PST) In-Reply-To: References: Date: Thu, 21 Jan 2010 11:05:47 -0800 Message-ID: From: Eric Rescorla To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsop WG , Edward Lewis Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 19:06:01 -0000 I still don't understand why this implies the need for regular changes as opposed to changes triggered by personnel changes. -Ekr On Thu, Jan 21, 2010 at 10:03 AM, Paul Wouters wrote: > On Thu, 21 Jan 2010, Edward Lewis wrote: > >> If I were to fit this into the text below... >> >> # >> # =A0 =A0 =A0 =A0The motivation for having the KSK's effectivity period >> # =A0 =A0 =A0 =A0longer than the ZSK's effectivity period is rooted in t= he >> # =A0 =A0 =A0 =A0operational consideration that a change in the KSK invo= lves >> # =A0 =A0 =A0 =A0interaction with an external entity, usually the parent= zone >> # =A0 =A0 =A0 =A0or possibly a trust anchor repository, and this interac= tion >> # =A0 =A0 =A0 =A0is anticipated to have significant latency (including t= he >> # =A0 =A0 =A0 =A0need to verify the other party has made the necessary c= hange. >> # > > Maybe make it more explicit that an intra-organisation key change can > and probably should happen frequently, where-as an inter-organisational > key change, because it involves other organisations, is more difficult > and should be kept to a minimum? > > Again, think of a zone administrator who had access to a private ZSK > leaving your organisation. It would be a good security policy to rollover > the ZSK as part of the procedure of revoking this person's access to > the organisation. And a good reason to have an HSM so you do not need > to do the same with the KSK. > > Paul > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From Ed.Lewis@neustar.biz Thu Jan 21 11:22:05 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8857F3A6963 for ; Thu, 21 Jan 2010 11:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[AWL=-0.353, 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 kytJ6BMwHN1R for ; Thu, 21 Jan 2010 11:22:04 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 1A2773A67DF for ; Thu, 21 Jan 2010 11:22:03 -0800 (PST) Received: from [10.31.200.228] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0LJLwxc010775; Thu, 21 Jan 2010 14:21:59 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 21 Jan 2010 14:17:58 -0500 To: Eric Rescorla From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: dnsop WG , Edward Lewis Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 19:22:05 -0000 At 11:05 -0800 1/21/10, Eric Rescorla wrote: >I still don't understand why this implies the need for regular changes >as opposed to changes triggered by personnel changes. I'm a bit lost following this thread now. For the time being, let's ignore personnel changes and whether a key is in an HSM (environment), i.e., assume there's no organizational threat to a key. The question is, how long does a key last? Meaning - if I am using an RSA-SHA256 key of 1024 bits, at what point does it's security value reach essentially 0? Is the point X number of signatures? Is the point Y number of days? Is the point a function of X and Y? Is there even a point at all? Even now, more than 10 years after the first SE workshop, I have never heard an expert or authority on cryptography give neither a concrete answer nor direction on this. While I realize the answer isn't as simple as "after 43,253 signatures" or "after 1348 days", I haven't heard anything that could be used as guidance in an operational setting. The "need for regular changes" stems from assumptions made in the early days of DNSSEC development that have gone pretty much unchallenged until recently. The door is open to (re)visit this topic, if anyone wants to venture opinions. What I'd like to hear is: "Crypto-expert __________ says an RSA-SHA256 key of 1024 bits is good for _______ signatures/days." That's what I'd like for my birthday present this year. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From paul.hoffman@vpnc.org Thu Jan 21 11:39:12 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33FAE3A6AE3 for ; Thu, 21 Jan 2010 11:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 9QJZjA1tFmI9 for ; Thu, 21 Jan 2010 11:39:11 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4E91E3A6905 for ; Thu, 21 Jan 2010 11:39:11 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0LJd39i068396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 12:39:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 21 Jan 2010 11:38:43 -0800 To: Edward Lewis , Eric Rescorla From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: dnsop WG , Edward Lewis Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 19:39:12 -0000 At 2:17 PM -0500 1/21/10, Edward Lewis wrote: >At 11:05 -0800 1/21/10, Eric Rescorla wrote: >>I still don't understand why this implies the need for regular changes >>as opposed to changes triggered by personnel changes. > >I'm a bit lost following this thread now. > >For the time being, let's ignore personnel changes and whether a key is in an HSM (environment), i.e., assume there's no organizational threat to a key. > >The question is, how long does a key last? > >Meaning - if I am using an RSA-SHA256 key of 1024 bits, at what point does it's security value reach essentially 0? > >Is the point X number of signatures? No. There is no suspicion on the part of any cryptographer that I know of that the number of visible signatures is significant for a 1024-bit or above key. >Is the point Y number of days? Yes, if the number of days is in the thousands (currently) and the value of this key is high. Otherwise, no. >Is the point a function of X and Y? No, just Y. >Is there even a point at all? For most keys, no, at least for the next five years or so. That is, the *cost* of breaking a 1024-bit key, when that is feasible, is still much higher than the value of the broken key. Remember that a broken signing key is only valuable until the fact that it is broken is discovered and fixed. So, even if an attacker breaks your signing key, when he/she starts to use it for nefarious purposes and you discover that, you roll your key and the entire time of breaking the new key must be used again before they can mount another attack. >Even now, more than 10 years after the first SE workshop, I have never heard an expert or authority on cryptography give neither a concrete answer nor direction on this. I have tried, repeatedly, to do so, but I am not an expert, nor apparently enough of an authority for you. Ekr is both; let's see if he likes my response above. > While I realize the answer isn't as simple as "after 43,253 signatures" or "after 1348 days", I haven't heard anything that could be used as guidance in an operational setting. See above. >The "need for regular changes" stems from assumptions made in the early days of DNSSEC development that have gone pretty much unchallenged until recently. The door is open to (re)visit this topic, if anyone wants to venture opinions. See above. :-) >What I'd like to hear is: > >"Crypto-expert __________ says an RSA-SHA256 key of 1024 bits is good for _______ signatures/days." If you hear that, the the value for the first variable will be worthless. You have to factor in the value of the key to the attacker for the short period in which they can use it before their actions are discovered and the broken key is replaced. >That's what I'd like for my birthday present this year. You're better off wishing for a pony. --Paul Hoffman, Director --VPN Consortium From olaf@NLnetLabs.nl Thu Jan 21 11:50:06 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95923A6A9C for ; Thu, 21 Jan 2010 11:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 3i1U5DBPffnM for ; Thu, 21 Jan 2010 11:50:05 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 003133A6823 for ; Thu, 21 Jan 2010 11:50:04 -0800 (PST) Received: from aagje.fritz.box ([IPv6:2002:525f:8490:0:226:bbff:fe0e:7cc7]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0LJntF8071117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Jan 2010 20:49:56 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Olaf Kolkman In-Reply-To: Date: Thu, 21 Jan 2010 20:49:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F6FEABE-90AE-437A-9C07-0D27746901B5@NLnetLabs.nl> References: <733B1414-CADE-481B-9FF5-CF7E2DCE402B@nlnetlabs.nl> To: Tony Finch X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 21 Jan 2010 20:49:57 +0100 (CET) Cc: Eric Rescorla , dnsop WG , "Rose, Scott W." Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 19:50:07 -0000 On Jan 21, 2010, at 5:28 PM, Tony Finch wrote: > On Thu, 21 Jan 2010, Olaf Kolkman wrote: >>=20 >> I understand EKR's remark (thanks) in addition to the improvement = Scott >> suggested there is the argument that if a rollover remains a special >> event it is bound to go wrong, while if it is part of regular >> operational procedure the operators do not have to go through the >> learning curve. That argument works, but not in the case that EKR >> brought up, if _the_ operator gets sacked the rollover done by the = new >> one is the first one that new operator does, she wouldn't have the >> benefit of operational routine. >=20 > Operational routines like this will be automated. That is what I would hope. But documents like this do suggest the = defaults and EKRs arguments for 'ad-hoc' rolling or the other comments = for regular rolling do impact the market that provides the automation. -- Olaf (Full disclosure: NLnet Labs is part of a group that develops this sort = of software, opendnssec). ________________________________________________________=20 Olaf M. Kolkman NLnet Labs Science Park 140,=20 http://www.nlnetlabs.nl/ 1098 XG Amsterdam From Ed.Lewis@neustar.biz Thu Jan 21 11:52:14 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD583A680A for ; Thu, 21 Jan 2010 11:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=-0.326, 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 Qho5ESNgcn9i for ; Thu, 21 Jan 2010 11:52:14 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id A47F03A67AF for ; Thu, 21 Jan 2010 11:52:13 -0800 (PST) Received: from [10.31.200.228] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0LJq6Ki011101; Thu, 21 Jan 2010 14:52:06 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 21 Jan 2010 14:49:11 -0500 To: Paul Hoffman From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: Eric Rescorla , Edward Lewis , dnsop WG Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 19:52:14 -0000 At 11:38 -0800 1/21/10, Paul Hoffman wrote: >At 2:17 PM -0500 1/21/10, Edward Lewis wrote: >>At 11:05 -0800 1/21/10, Eric Rescorla wrote: >I have tried, repeatedly, to do so, but I am not an expert, nor apparently >enough of an authority for you. Ekr is both; let's see if he likes my >response above. Just to remove any thought that I intended to slight anyone - I must have missed whatever you had said before. ;) >You're better off wishing for a pony. I thought so. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From ekr@rtfm.com Thu Jan 21 12:12:59 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458443A6A86 for ; Thu, 21 Jan 2010 12:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fG2wbmLuY1Os for ; Thu, 21 Jan 2010 12:12:58 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 59E2D3A6806 for ; Thu, 21 Jan 2010 12:12:57 -0800 (PST) Received: by yxe30 with SMTP id 30so368781yxe.29 for ; Thu, 21 Jan 2010 12:12:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.13.27 with SMTP id 27mr1921316agm.28.1264104770610; Thu, 21 Jan 2010 12:12:50 -0800 (PST) In-Reply-To: References: Date: Thu, 21 Jan 2010 12:12:50 -0800 Message-ID: From: Eric Rescorla To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsop WG , Edward Lewis Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 20:12:59 -0000 On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman wrot= e: > At 2:17 PM -0500 1/21/10, Edward Lewis wrote: >>At 11:05 -0800 1/21/10, Eric Rescorla wrote: >>>I still don't understand why this implies the need for regular changes >>>as opposed to changes triggered by personnel changes. >> >>I'm a bit lost following this thread now. >> >>For the time being, let's ignore personnel changes and whether a key is i= n an HSM (environment), i.e., assume there's no organizational threat to a = key. >> >>The question is, how long does a key last? >> >>Meaning - if I am using an RSA-SHA256 key of 1024 bits, at what point doe= s it's security value reach essentially 0? >> >>Is the point X number of signatures? > > No. There is no suspicion on the part of any cryptographer that I know of= that the number of visible signatures is significant for a 1024-bit or abo= ve key. Agreed. Recall that with PKC an attacker can generate as many plaintext/ciphertext pairs as he wants. >>Is the point Y number of days? > > Yes, if the number of days is in the thousands (currently) and the value = of this key is high. Otherwise, no. I actually sort of disagree with this. I don't see how to evaluate this question in a meaningful way, and it's not a cryptographic question. Let's say for the sake of argument that we know if requires C CPU-hours to break a key and that each CPU costs $H but is free to run once you own it (not true). In that case, an attacker with $D to spend can break a single key in C/(D/H) hours. How long is that key secure for? Who knows. Most of the variance is in attacker motivation and funding, not time. > For most keys, no, at least for the next five years or so. That is, the *= cost* of breaking a 1024-bit key, when that is feasible, is still much high= er than the value of the broken key. Remember that a broken signing key is = only valuable until the fact that it is broken is discovered and fixed. So,= even if an attacker breaks your signing key, when he/she starts to use it = for nefarious purposes and you discover that, you roll your key and the ent= ire time of breaking the new key must be used again before they can mount a= nother attack. Exactly. So rolling it preemptively doesn't help much. -Ekr >>The "need for regular changes" stems from assumptions made in the early d= ays of DNSSEC development that have gone pretty much unchallenged until rec= ently. =A0The door is open to (re)visit this topic, if anyone wants to vent= ure opinions. > > See above. :-) So, the referenced post summarizes my opinion. I don't care enough about it= to fight it to the death here, however. >>What I'd like to hear is: >> >>"Crypto-expert __________ says an RSA-SHA256 key of 1024 bits is good for= _______ signatures/days." > > If you hear that, the the value for the first variable will be worthless.= You have to factor in the value of the key to the attacker for the short p= eriod in which they can use it before their actions are discovered and the = broken key is replaced. I more or less agree with this. You may want to hear that, but there's no meaningful answer. -Ekr From mohta@necom830.hpcl.titech.ac.jp Thu Jan 21 12:19:02 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308923A67AF for ; Thu, 21 Jan 2010 12:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.553 X-Spam-Level: * X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643] 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 Mh9to35fSpix for ; Thu, 21 Jan 2010 12:19:01 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id E4B663A6816 for ; Thu, 21 Jan 2010 12:19:00 -0800 (PST) Received: (qmail 43938 invoked from network); 21 Jan 2010 21:11:22 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jan 2010 21:11:22 -0000 Message-ID: <4B58B686.7050801@necom830.hpcl.titech.ac.jp> Date: Fri, 22 Jan 2010 05:18:14 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Edward Lewis References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Eric Rescorla , dnsop WG , "Rose, Scott W." Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 20:19:02 -0000 Edward Lewis wrote: > Also, what was not anticipated was the coming of automated provisioning, Yes, it was anticipated. It was obvious from the beginning of DNSSEC that automated provisioning operationally unavoidable. > At the time too - > HSMs didn't exist in our world, and we still thought that all signing > would be done on a machine with an air-gap to the Internet. In draft-ohta-simple-dns-00.txt (August 1994), it is already written In cases where frequent and/or automatic update of a zone is desired, it is necessary to make signature generation mechanism of the zone accessible on-line. Still, it is worthwhile to keep the secret information and secure time stamping mechanism of the zone off-line. HSM was also considered but was not essential, because secret keys of signature genration mechanisms may be physically protected in various ways. > So many assumptions have changed...but the idea of KSK/ZSK hasn't. It is merely that your assumptions including that on KSK/ZSK have been bogus. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Thu Jan 21 12:26:00 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8DCF3A6ABF for ; Thu, 21 Jan 2010 12:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.482 X-Spam-Level: ** X-Spam-Status: No, score=2.482 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643] 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 lBAW8XqjTIyk for ; Thu, 21 Jan 2010 12:26:00 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id B0A8F28C126 for ; Thu, 21 Jan 2010 12:25:59 -0800 (PST) Received: (qmail 44743 invoked from network); 21 Jan 2010 21:18:37 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jan 2010 21:18:37 -0000 Message-ID: <4B58B839.8070705@necom830.hpcl.titech.ac.jp> Date: Fri, 22 Jan 2010 05:25:29 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Andrew Sullivan References: <20100121153929.GF81286@shinkuro.com> <20100121160220.GH81286@shinkuro.com> <20100121165804.GP81286@shinkuro.com> In-Reply-To: <20100121165804.GP81286@shinkuro.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 20:26:00 -0000 Andrew Sullivan wrote: > I fully agree. I just want to make sure we're not holding ourselves > to an operational standard that is just impossible to reach. If we > want "proof" and "facts" about whether something won't ever be > compromised, Remember that DNSSEC was developed because it was believed to make DNS proven to be secure. > it's not going to happen (so I'm very keen we not put > anything resembling such language in any draft). That's all I was > saying. You are saying DNSSEC is *NOT* cryptographically secure. You are saying DNSSEC merely operationally secure. And, you are right. That is, there is no point of deploying DNSSEC. Masataka Ohta From ajs@shinkuro.com Thu Jan 21 12:27:52 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EFB43A6A88 for ; Thu, 21 Jan 2010 12:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.086 X-Spam-Level: X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[AWL=-0.487, 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 AQ-EHe1GG-5V for ; Thu, 21 Jan 2010 12:27:51 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 99CA93A69C6 for ; Thu, 21 Jan 2010 12:27:51 -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 180892FE8CA1 for ; Thu, 21 Jan 2010 20:27:47 +0000 (UTC) Date: Thu, 21 Jan 2010 15:27:45 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20100121202745.GZ81286@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: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 20:27:52 -0000 On Thu, Jan 21, 2010 at 12:12:50PM -0800, Eric Rescorla wrote: > On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman wrote: > > is still much higher than the value of the broken key. Remember > > that a broken signing key is only valuable until the fact that it > > is broken is discovered and fixed. So, even if an attacker breaks > > your signing key, when he/she starts to use it for nefarious > > purposes and you discover that, you roll your key and the entire > > time of breaking the new key must be used again before they can > > mount another attack. > > Exactly. So rolling it preemptively doesn't help much. What about the argument that you might not discover the nefarious use (because a small number of DNS transactions, carefully selected, are the only misdirected ones, and everything else appears normal, so you chalk it up to user error)? Remember that unlike many cryptographic protocols, there's no real end-to-end communication here. It could well be hard for a key owner to detect the compromise in a DNS context than in many other contexts. If one accepts that argument (I don't know I do, but let's accept it for the sake of argument), then rolling regularly (modulo jitter) could be argued for on the grounds that it will cut off even undetected compromises. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Thu Jan 21 12:40:11 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651EB3A6881 for ; Thu, 21 Jan 2010 12:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=-0.474, 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 pZEFASphmGwJ for ; Thu, 21 Jan 2010 12:40:08 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 52C923A6816 for ; Thu, 21 Jan 2010 12:40:08 -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 D80FB2FE8CA1 for ; Thu, 21 Jan 2010 20:40:03 +0000 (UTC) Date: Thu, 21 Jan 2010 15:40:02 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20100121204001.GA81286@shinkuro.com> References: <20100121153929.GF81286@shinkuro.com> <20100121160220.GH81286@shinkuro.com> <20100121165804.GP81286@shinkuro.com> <4B58B839.8070705@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B58B839.8070705@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 20:40:11 -0000 On Fri, Jan 22, 2010 at 05:25:29AM +0900, Masataka Ohta wrote: > Andrew Sullivan wrote: > > > I fully agree. I just want to make sure we're not holding ourselves > > to an operational standard that is just impossible to reach. If we > > want "proof" and "facts" about whether something won't ever be > > compromised, > > Remember that DNSSEC was developed because it was believed to make > DNS proven to be secure. You're equivocating on "proof" or "secure" or maybe both. DNSSEC allows you to prove that, assuming secure keys, you're getting the the correct (i.e. authoritatively-sourced) answer. It does not allow you to prove that the keys were handled properly, that Dr Evil hasn't taken over the authoritative machine, that we really are living in a Euclidean universe with the relevant mathematical structures, or that ChipManufactureCorp didn't have a serious bug that caused every cryptographic operation it ever does to be predictable. It also doesn't allow you to prove that Bishop Berkeley's metaphysics was wrong, such that you are in fact connecting to a computer somewhere out there in the world and not just a representation-of-foreign-computer in your consciousness. No other cryptographic proof can ever prove such things, either, since a cryptographic system invariably involves those nasty graphos, who are prone to making errors. Moreover, no existing system can prove that there is not an undiscovered vulnerability of an algorithm (though I understand there are proofs that, under known mathematical assumptions, some algorithms cannot be broken. That's not the same thing). If you wish otherwise, I think you are asking that Godel be proven wrong. If you dislike the word "prove" and cognates to be used for anything other than mathematical certainty, then I suggest you translate any use of "proof" that involves parts of the physical universe into some other term like "increased confidence in the empirico-statistical sense". A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From paul.hoffman@vpnc.org Thu Jan 21 12:54:42 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71C628C15C for ; Thu, 21 Jan 2010 12:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 cYDGTvsYTNro for ; Thu, 21 Jan 2010 12:54:41 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CCAA73A6A95 for ; Thu, 21 Jan 2010 12:54:41 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0LKsasi074338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 13:54:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100121202745.GZ81286@shinkuro.com> References: <20100121202745.GZ81286@shinkuro.com> Date: Thu, 21 Jan 2010 12:54:34 -0800 To: Andrew Sullivan , dnsop@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 20:54:42 -0000 At 3:27 PM -0500 1/21/10, Andrew Sullivan wrote: >On Thu, Jan 21, 2010 at 12:12:50PM -0800, Eric Rescorla wrote: >> On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman wrote: > >> > is still much higher than the value of the broken key. Remember >> > that a broken signing key is only valuable until the fact that it >> > is broken is discovered and fixed. So, even if an attacker breaks >> > your signing key, when he/she starts to use it for nefarious >> > purposes and you discover that, you roll your key and the entire >> > time of breaking the new key must be used again before they can >> > mount another attack. >> >> Exactly. So rolling it preemptively doesn't help much. > >What about the argument that you might not discover the nefarious use >(because a small number of DNS transactions, carefully selected, are >the only misdirected ones, and everything else appears normal, so you >chalk it up to user error)? Remember that unlike many cryptographic >protocols, there's no real end-to-end communication here. It could >well be hard for a key owner to detect the compromise in a DNS context >than in many other contexts. > >If one accepts that argument (I don't know I do, but let's accept it >for the sake of argument), then rolling regularly (modulo jitter) >could be argued for on the grounds that it will cut off even >undetected compromises. ...as long as there is no cost to rolling regularly. But there are many: - A botched roll can cause validating resolvers to not trust any of your answers - A botched roll can (I think) cause your zone to go bogus - Regular rolling can give you a false sense of security about your rolling process These are about as intangible as the cost of an attacker using a compromised key until you discover and change the key. Thus, you want to make the cost to the attacker as high as possible. The easiest way to do that is a longer key, such as 2048 bits, or a better signing algorithm, such as ECDSA. --Paul Hoffman, Director --VPN Consortium From mohta@necom830.hpcl.titech.ac.jp Thu Jan 21 13:10:16 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44453A6AE4 for ; Thu, 21 Jan 2010 13:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.947 X-Spam-Level: ** X-Spam-Status: No, score=2.947 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643] 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 HzDHhTs2yagI for ; Thu, 21 Jan 2010 13:10:15 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 84D783A6ABF for ; Thu, 21 Jan 2010 13:10:15 -0800 (PST) Received: (qmail 47395 invoked from network); 21 Jan 2010 22:02:31 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jan 2010 22:02:31 -0000 Message-ID: <4B58C283.6050602@necom830.hpcl.titech.ac.jp> Date: Fri, 22 Jan 2010 06:09:23 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Andrew Sullivan References: <20100121153929.GF81286@shinkuro.com> <20100121160220.GH81286@shinkuro.com> <20100121165804.GP81286@shinkuro.com> <4B58B839.8070705@necom830.hpcl.titech.ac.jp> <20100121204001.GA81286@shinkuro.com> In-Reply-To: <20100121204001.GA81286@shinkuro.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:10:16 -0000 Andrew Sullivan wrote: >>Remember that DNSSEC was developed because it was believed to make >>DNS proven to be secure. > You're equivocating on "proof" or "secure" or maybe both. > > DNSSEC allows you to prove that, assuming secure keys, you're getting > the the correct (i.e. authoritatively-sourced) answer. As a person who have been working on DNS before early days of DNSSEC, I remember very well why DNSSEC was developed. As is written in RFC2065: Careful key generation is a sometimes overlooked but absolutely essential element in any cryptographically secure system. That is, DNSSEC was wrongly believed to be cryptographically secure. > If you dislike the word "prove" and cognates to be used for anything "cryptographically secure" is fatal enough. Masataka Ohta From Ed.Lewis@neustar.biz Thu Jan 21 13:14:15 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF563A67AF for ; Thu, 21 Jan 2010 13:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=-0.327, 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 E0qULZtZZ5YM for ; Thu, 21 Jan 2010 13:14:14 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 89EA23A6ABF for ; Thu, 21 Jan 2010 13:14:14 -0800 (PST) Received: from [10.31.200.228] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0LLE69s011756; Thu, 21 Jan 2010 16:14:08 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20100121202745.GZ81286@shinkuro.com> Date: Thu, 21 Jan 2010 16:14:03 -0500 To: Paul Hoffman From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: Andrew Sullivan , dnsop@ietf.org Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:14:15 -0000 At 12:54 -0800 1/21/10, Paul Hoffman wrote: >...as long as there is no cost to rolling regularly. But there are many: I'm finding this discussion enlightening and interesting. If the logic is that the only need to roll is event-based (detecting a violation) because there is risk of a roll going badly - then there's a reason to regularly "drill" when there's no threat to make sure you minimize the chance of a screw-up during a real emergency. How ironic. ;) What scares me (too) is Andrew's observation that you might fail to detect a bad key because of the size of a zone and potentially a targeted attack on just one or two domains. Perhaps monthly rolls aren't needed for crypto-sake, but the more apparent this is the more apparent we need regular rolls for operations-sake. A bad roll will be detected and fixed faster than a secretly broken key and an isolated target. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From drc@virtualized.org Thu Jan 21 13:19:44 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DBE93A6A21 for ; Thu, 21 Jan 2010 13:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ShZDjU7x2ps7 for ; Thu, 21 Jan 2010 13:19:43 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 9314B3A6AC3 for ; Thu, 21 Jan 2010 13:19:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 6BF19A396E2; Thu, 21 Jan 2010 13:19:39 -0800 (PST) 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 Y4ig+SHv+zQP; Thu, 21 Jan 2010 13:19:37 -0800 (PST) Received: from 102.99.224.10.in-addr.arpa (m110436d0.tmodns.net [208.54.4.17]) by virtualized.org (Postfix) with ESMTP id 44D1BA396D7; Thu, 21 Jan 2010 13:19:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Thu, 21 Jan 2010 13:19:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org> References: <20100121202745.GZ81286@shinkuro.com> To: Edward Lewis X-Mailer: Apple Mail (2.1077) Cc: Andrew Sullivan , dnsop@ietf.org, Paul Hoffman Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:19:44 -0000 On Jan 21, 2010, at 1:14 PM, Edward Lewis wrote: > Perhaps monthly rolls aren't needed for crypto-sake, but the more = apparent this is the more apparent we need regular rolls for = operations-sake. Thanks. While I might agree that _theoretically_ longer keys and/or better = algorithms removes or at least reduces the need to do frequent roles, = the operational reality empirically proven in a variety of fields is = that if you don't exercise stuff, it is going to break when you need it. Regards, -drc From ekr@rtfm.com Thu Jan 21 13:26:42 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDAC03A68FC for ; Thu, 21 Jan 2010 13:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 QssYjAdQ6-9Z for ; Thu, 21 Jan 2010 13:26:42 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 0410C3A67FC for ; Thu, 21 Jan 2010 13:26:41 -0800 (PST) Received: by yxe30 with SMTP id 30so435652yxe.29 for ; Thu, 21 Jan 2010 13:26:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.63.29 with SMTP id q29mr1978773agk.72.1264109188204; Thu, 21 Jan 2010 13:26:28 -0800 (PST) In-Reply-To: <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org> References: <20100121202745.GZ81286@shinkuro.com> <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org> Date: Thu, 21 Jan 2010 13:26:28 -0800 Message-ID: From: Eric Rescorla To: David Conrad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Andrew Sullivan , dnsop@ietf.org, Edward Lewis , Paul Hoffman Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:26:42 -0000 Again, I don't feel strongly about this, but I don't really find this very convincing. Presumably there are all sorts of other credentials that control access to = the ZSK (e.g., administrator SSH private keys, root passwords, etc.) Do you als= o propose to roll all of these every month? If not, why not? -Ekr On Thu, Jan 21, 2010 at 1:19 PM, David Conrad wrote: > On Jan 21, 2010, at 1:14 PM, Edward Lewis wrote: >> Perhaps monthly rolls aren't needed for crypto-sake, but the more appare= nt this is the more apparent we need regular rolls for operations-sake. > > Thanks. > > While I might agree that _theoretically_ longer keys and/or better algori= thms removes or at least reduces the need to do frequent roles, the operati= onal reality empirically proven in a variety of fields is that if you don't= exercise stuff, it is going to break when you need it. > > Regards, > -drc > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From ajs@shinkuro.com Thu Jan 21 13:29:45 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311B528C0EA for ; Thu, 21 Jan 2010 13:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.06 X-Spam-Level: X-Spam-Status: No, score=-3.06 tagged_above=-999 required=5 tests=[AWL=-0.461, 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 aYM6zBdx+grY for ; Thu, 21 Jan 2010 13:29:44 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 2893D28C18A for ; Thu, 21 Jan 2010 13:29:44 -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 9D9F32FE8CA1 for ; Thu, 21 Jan 2010 21:29:39 +0000 (UTC) Date: Thu, 21 Jan 2010 16:29:38 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20100121212937.GB81286@shinkuro.com> References: <20100121202745.GZ81286@shinkuro.com> 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: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:29:45 -0000 On Thu, Jan 21, 2010 at 04:14:03PM -0500, Edward Lewis wrote: > > I'm finding this discussion enlightening and interesting. Me too. I also think that discussion of exactly this sort belongs in the advice we give to operators. Understanding the trade-offs and the reason for them is exactly what makes for selecting the right policies given the operational considerations of the environment in which one is working. I don't think there's one answer for this question, because what is right is surely related to other considerations. For instance, despite what David says downthread about operational realities and exercise, such exercise is a complete waste of time if the person who does the work is different every time (as might well be the case under a lot of outsourcing contracts). In that circumstance, Paul is probably right: the risk of blowing the key roll outweighs the benefits of practice. One also worries a little that many operations people (me included) so often think "you need to practice this" includes "in production". (But I haven't worked many places where I've had a real, true, complete copy of my production systems just for running fire drills.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ed.Lewis@neustar.biz Thu Jan 21 13:43:01 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722DC3A68B3 for ; Thu, 21 Jan 2010 13:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=-0.337, 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 v4iBJpXWjxvH for ; Thu, 21 Jan 2010 13:43:00 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 84F2C3A67A7 for ; Thu, 21 Jan 2010 13:43:00 -0800 (PST) Received: from [10.31.200.228] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0LLgpBs012127; Thu, 21 Jan 2010 16:42:52 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20100121202745.GZ81286@shinkuro.com> <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org> Date: Thu, 21 Jan 2010 16:42:46 -0500 To: Eric Rescorla From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: Andrew Sullivan , dnsop@ietf.org, Edward Lewis , David Conrad , Paul Hoffman Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:43:01 -0000 As a matter of fact, a lot of the security credentials (SSH keys, passwords, etc.) are rolled on a regular basis already, as part of institutional security policies. But I think a point has been missed - the roll of keys on a periodic basis is needed to *exercise the activity* if not achieve a higher level of security. At 13:26 -0800 1/21/10, Eric Rescorla wrote: >Again, I don't feel strongly about this, but I don't really find this >very convincing. > >Presumably there are all sorts of other credentials that control access to the >ZSK (e.g., administrator SSH private keys, root passwords, etc.) Do you also >propose to roll all of these every month? If not, why not? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From Ed.Lewis@neustar.biz Thu Jan 21 13:45:25 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E293A6765 for ; Thu, 21 Jan 2010 13:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=-0.319, 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 LmslR3IYZZ8O for ; Thu, 21 Jan 2010 13:45:25 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id B0FFC28C176 for ; Thu, 21 Jan 2010 13:45:24 -0800 (PST) Received: from [10.31.200.228] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0LLjGKb012170; Thu, 21 Jan 2010 16:45:17 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100121212937.GB81286@shinkuro.com> References: <20100121202745.GZ81286@shinkuro.com> <20100121212937.GB81286@shinkuro.com> Date: Thu, 21 Jan 2010 16:45:12 -0500 To: dnsop@ietf.org From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:45:25 -0000 At 16:29 -0500 1/21/10, Andrew Sullivan wrote: >One also worries a little that many operations people (me included) so >often think "you need to practice this" includes "in production". >(But I haven't worked many places where I've had a real, true, >complete copy of my production systems just for running fire drills.) But where else (besides production) can you also test that ISPs get the right key into their verifiers? The Internet is an interconnected mesh of entities, no walled garden is an island... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From drc@virtualized.org Thu Jan 21 13:48:07 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE2228C107 for ; Thu, 21 Jan 2010 13:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 NWXGQuc+IdWf for ; Thu, 21 Jan 2010 13:48:07 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 08DAE28C101 for ; Thu, 21 Jan 2010 13:48:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 5DC24A39988; Thu, 21 Jan 2010 13:48:03 -0800 (PST) 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 o5DlaAe8togG; Thu, 21 Jan 2010 13:48:01 -0800 (PST) Received: from 123.98.224.10.in-addr.arpa (m160436d0.tmodns.net [208.54.4.22]) by virtualized.org (Postfix) with ESMTP id D864DA39977; Thu, 21 Jan 2010 13:47:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Thu, 21 Jan 2010 13:47:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3CF8AD7C-45E0-4850-A433-42149EEAB8C1@virtualized.org> References: <20100121202745.GZ81286@shinkuro.com> <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org> To: Edward Lewis X-Mailer: Apple Mail (2.1077) Cc: Andrew Sullivan , Eric Rescorla , dnsop@ietf.org, Paul Hoffman Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:48:07 -0000 On Jan 21, 2010, at 1:42 PM, Edward Lewis wrote: >> Presumably there are all sorts of other credentials that control = access to the >> ZSK (e.g., administrator SSH private keys, root passwords, etc.) Do = you also >> propose to roll all of these every month? If not, why not? ... > But I think a point has been missed - the roll of keys on a periodic = basis is needed to *exercise the activity* if not achieve a higher level = of security. +1 Fixing secretly compromised ZSKs is a side benefit. Regards, -drc From paul.hoffman@vpnc.org Thu Jan 21 13:49:06 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3A5F28C1AC for ; Thu, 21 Jan 2010 13:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 5PP7j6NMLQqZ for ; Thu, 21 Jan 2010 13:49:05 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B5E9B28C1AA for ; Thu, 21 Jan 2010 13:49:05 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0LLn0KW077800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Jan 2010 14:49:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20100121202745.GZ81286@shinkuro.com> Date: Thu, 21 Jan 2010 13:48:17 -0800 To: dnsop@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:49:06 -0000 At 4:14 PM -0500 1/21/10, Edward Lewis wrote: >At 12:54 -0800 1/21/10, Paul Hoffman wrote: > >>...as long as there is no cost to rolling regularly. But there are many: > >I'm finding this discussion enlightening and interesting. > >If the logic is that the only need to roll is event-based (detecting a violation) because there is risk of a roll going badly - then there's a reason to regularly "drill" when there's no threat to make sure you minimize the chance of a screw-up during a real emergency. > >How ironic. ;) Yep. It is also ironic (and iconic) that the DNSSEC community is just now discovering the operational tradeoffs that the security industry has known for well over a decade. >What scares me (too) is Andrew's observation that you might fail to detect a bad key because of the size of a zone and potentially a targeted attack on just one or two domains. What he is saying is the same thing that Eric and I said: you *have* to factor in the value to the attacker of using the compromised key versus the risk that being caught using it will force him to have to re-do all his work. >Perhaps monthly rolls aren't needed for crypto-sake, but the more apparent this is the more apparent we need regular rolls for operations-sake. Why do you equate "regular" with "monthly"? And why do they have to be "regular"? A perfectly valid operational goal would be "whenever there is enough new staff who should see how we do a roll, plus once and a while during a period where, if we botch it, there is the least amount of damage and the best opportunity to fix it". For VeriSign, that might translate to "monthly", but for ImportantCompany.com, it might translate to "once a year or so". >A bad roll will be detected and fixed faster than a secretly broken key and an isolated target. Sure, but "time" is the wrong unit of measure: "cost" is. The reputation cost for a botched roll could be much, much higher than a small number of believed answers to an "isolated target". At 1:26 PM -0800 1/21/10, Eric Rescorla wrote: >Presumably there are all sorts of other credentials that control access to the >ZSK (e.g., administrator SSH private keys, root passwords, etc.) Do you also >propose to roll all of these every month? If not, why not? Bingo. --Paul Hoffman, Director --VPN Consortium From drc@virtualized.org Thu Jan 21 13:58:01 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6E53A67DA for ; Thu, 21 Jan 2010 13:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 5wBoXL+g3qMe for ; Thu, 21 Jan 2010 13:58:00 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id C26913A6928 for ; Thu, 21 Jan 2010 13:58:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 2ADCEA39A88; Thu, 21 Jan 2010 13:57:57 -0800 (PST) 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 wstx9vNnpEOo; Thu, 21 Jan 2010 13:57:55 -0800 (PST) Received: from 123.98.224.10.in-addr.arpa (m160436d0.tmodns.net [208.54.4.22]) by virtualized.org (Postfix) with ESMTP id 42A48A39A7A; Thu, 21 Jan 2010 13:57:53 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20100121212937.GB81286@shinkuro.com> Date: Thu, 21 Jan 2010 13:57:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <455DA067-4681-4570-9E0B-0B159A0FC1E4@virtualized.org> References: <20100121202745.GZ81286@shinkuro.com> <20100121212937.GB81286@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1077) Cc: dnsop@ietf.org Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:58:01 -0000 Andrew, On Jan 21, 2010, at 1:29 PM, Andrew Sullivan wrote: > For instance, despite what David says downthread about operational > realities and exercise, such exercise is a complete waste of time if > the person who does the work is different every time (as might well be > the case under a lot of outsourcing contracts). Err, no. The exercises would not be a waste of time. First time a scheduled roll botches, any rational organization would = institute policies and processes to ensure that such a botch does not = reoccur. First time a scheduled roll botches with a new outsourced = contractor, any rational organization would institute policies and = processes to ensure that such a botch does not reoccur. Etc. There is a reason people have "fire drills" on a periodic schedule. = Folks really concerned about operational readiness also have those = drills on unannounced schedules. As Ed points out, the issues here are confused because of the assumption = that it is done for crypto security. The crypto stuff is (in my mind) a = side benefit. Regards, -drc From roy@dnss.ec Thu Jan 21 14:11:40 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF983A68B3 for ; Thu, 21 Jan 2010 14:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=0.698, 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 PKVtaA2QT7ZK for ; Thu, 21 Jan 2010 14:11:39 -0800 (PST) Received: from mail.schlyter.se (trinitario.schlyter.se [195.47.254.10]) by core3.amsl.com (Postfix) with ESMTP id 879B93A67E2 for ; Thu, 21 Jan 2010 14:11:39 -0800 (PST) Received: from [192.168.1.2] (unknown [201.238.167.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roy) by mail.schlyter.se (Postfix) with ESMTPSA id 1C8E52D4CC; Thu, 21 Jan 2010 23:11:22 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Roy Arends In-Reply-To: Date: Thu, 21 Jan 2010 17:11:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100121202745.GZ81286@shinkuro.com> <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org> To: Edward Lewis X-Mailer: Apple Mail (2.1077) Cc: Andrew Sullivan , Eric Rescorla , Paul Hoffman , dnsop@ietf.org, David Conrad Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 22:11:41 -0000 On Jan 21, 2010, at 4:42 PM, Edward Lewis wrote: > As a matter of fact, a lot of the security credentials (SSH keys, = passwords, etc.) are rolled on a regular basis already, as part of = institutional security policies. >=20 > But I think a point has been missed - the roll of keys on a periodic = basis is needed to *exercise the activity* if not achieve a higher level = of security. I'd recommend that 'exercise the activity' is not done on critical = production systems. Roy=20= From ajs@shinkuro.com Thu Jan 21 14:20:28 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 639A73A6ABF for ; Thu, 21 Jan 2010 14:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[AWL=-0.449, 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 GUQEpJ-pqIZY for ; Thu, 21 Jan 2010 14:20:27 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 583C13A6A8A for ; Thu, 21 Jan 2010 14:20:27 -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 7F7D72FE8CA1 for ; Thu, 21 Jan 2010 22:20:22 +0000 (UTC) Date: Thu, 21 Jan 2010 17:20:20 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20100121222020.GD81286@shinkuro.com> References: <20100121202745.GZ81286@shinkuro.com> <20100121212937.GB81286@shinkuro.com> <455DA067-4681-4570-9E0B-0B159A0FC1E4@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <455DA067-4681-4570-9E0B-0B159A0FC1E4@virtualized.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 22:20:28 -0000 On Thu, Jan 21, 2010 at 01:57:49PM -0800, David Conrad wrote: > > First time a scheduled roll botches, any rational organization would > institute policies and processes to ensure that such a botch does > not reoccur. First time a scheduled roll botches with a new > outsourced contractor, any rational organization would institute > policies and processes to ensure that such a botch does not reoccur. You have worked in more enlightened organizations than I, then. In my experience, with a lot of this sort of outsourcing, what will happen is that the outsourcing company will produce an incident report detailing the many ways the overworked drone who didn't know what he was doing screwed up, why their JD Power or whatever surveys prove that this never happens to them, and the 40 meetings that will be held to ensure that even though this was in fact an impossible event, it will never happen again. In an organization that actually knows what it is doing technologically, I'm sure you're right. In an organization that doesn't actually care about running its systems because everyone there has something else they're really doing, DNSSEC will be handed out to someone else. The people in that organization will have _no clue_ how to evaluate the goodness or badness of the DNSSEC procedures of said contractors. Or maybe one person in the company will, but he will be doing the work of three people and won't have time to pay close attention to any of this. The DNS is _not important_ to most of the people who have to rely on it, any more than the details of my plumbing system are something I think about every time I wash my hands (and yes, I have replaced my own pipes). Asking people to roll their keys all the time is like telling them that they need to do annual maintenance checking the washers in all their sinks, to make sure that they're not having leaks. Good, sane practice; but they're not going to do it. They'll notice when a drip starts, and that day they'll call a plumber. > There is a reason people have "fire drills" on a periodic schedule. When we have fire drills, in my experience, we don't actually set off the alarms and run the sprinklers (or set the building on fire). We do it in a controlled, test way, with a mechanism to warn the fire department and so on. And actually, in many places, everyone knows when a fire drill is happening. We don't seem to have mechanisms for all this stuff everywhere in the DNS. Finally, there are places where fire drills practically never happen -- I've never once been in a movie theatre where a fire drill happened during a show, for instance. And for good reason: the risk of setting off a panic and hurting people is much greater than the risk that people won't know what to do in case of a real fire. I'm not trying to say, "Never roll your keys under any circumstances." I am arguing, however, that the advice in a document about how to manage your systems has to contain second-order advice about evaluating risk and reward, if we want that advice to be helpful. Rolling keys entails some risk, and if that risk is greater than the combination of the risk that the key is going to be compromised in the key lifetime and the risk reduction from key rolling practice, then the person deciding to do the key roll anyway is actually being irresponsible: they're taking greater risk than need be. Different environments entail different results for that risk evaluation, because the keys are not all of the same value. The keys for mytinycornerof.universe.example.com are just not as valuable as the keys for the root, and that means I have to make trade-offs that might be different than those for the root. Isn't that obvious? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From paul@xelerance.com Thu Jan 21 14:24:37 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DED23A6ABF for ; Thu, 21 Jan 2010 14:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_00=-2.599, US_DOLLARS_3=0.63] 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 0748DMn2JAJk for ; Thu, 21 Jan 2010 14:24:35 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id AFA0F3A6781 for ; Thu, 21 Jan 2010 14:24:35 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 8D3AB571B3; Thu, 21 Jan 2010 17:24:30 -0500 (EST) Date: Thu, 21 Jan 2010 17:24:30 -0500 (EST) From: Paul Wouters To: Edward Lewis 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: Eric Rescorla , dnsop WG Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 22:24:37 -0000 On Thu, 21 Jan 2010, Edward Lewis wrote: > What I'd like to hear is: > > "Crypto-expert __________ says an RSA-SHA256 key of 1024 bits is good for > _______ signatures/days." I did ask my local Waterloo based cryptographer (Ian Goldberg) this question about a year ago for RSA-SHA1. And apart from his advise to use RSASSA-PSS and not PKCS1-v1_5, he thought a year would be extremely safe. I just asked another Toronto based cryptographer, Kelly Rose, the same question, and he said he would not trust it for more then two years. Also, consider this paper from July 2009: https://documents.epfl.ch/users/l/le/lenstra/public/papers/ecdl.pdf Next considering special purpose hardware, the most optimistic approach suggests that sieving for a 1024-bit RSA modulus can be done in a year for about US $10,000,000, plus a one-time development cost of about US $20,000,000, As for your specific birthday present, you will not get it. The same paper says: Estimates should thus not be read as threatening but as confidence-inspiring. > That's what I'd like for my birthday present this year. How about a cookie instead? Paul From roy@dnss.ec Thu Jan 21 14:36:36 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3F13A67ED for ; Thu, 21 Jan 2010 14:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.349, 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 9lBe2Xl0zviZ for ; Thu, 21 Jan 2010 14:36:35 -0800 (PST) Received: from mail.schlyter.se (trinitario.schlyter.se [195.47.254.10]) by core3.amsl.com (Postfix) with ESMTP id 8B27F3A676A for ; Thu, 21 Jan 2010 14:36:35 -0800 (PST) Received: from [192.168.1.2] (unknown [201.238.167.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roy) by mail.schlyter.se (Postfix) with ESMTPSA id 46B832D4AD; Thu, 21 Jan 2010 23:36:26 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Roy Arends In-Reply-To: <3CF8AD7C-45E0-4850-A433-42149EEAB8C1@virtualized.org> Date: Thu, 21 Jan 2010 17:36:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6820CEC7-211E-4B77-9DA6-238C8875CBCE@dnss.ec> References: <20100121202745.GZ81286@shinkuro.com> <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org> <3CF8AD7C-45E0-4850-A433-42149EEAB8C1@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1077) Cc: Andrew Sullivan , Eric Rescorla , Edward Lewis , dnsop@ietf.org, Paul Hoffman Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 22:36:36 -0000 On Jan 21, 2010, at 4:47 PM, David Conrad wrote: > On Jan 21, 2010, at 1:42 PM, Edward Lewis wrote: >>> Presumably there are all sorts of other credentials that control = access to the >>> ZSK (e.g., administrator SSH private keys, root passwords, etc.) Do = you also >>> propose to roll all of these every month? If not, why not? > ... >> But I think a point has been missed - the roll of keys on a periodic = basis is needed to *exercise the activity* if not achieve a higher level = of security. >=20 > +1 >=20 > Fixing secretly compromised ZSKs is a side benefit. Rolling to mitigate secretly compromised keys suggests that compromising = a key is a one-off event. If its compromised once, you have to assume = its compromised often. It will probably compromised after each roll. = Compromising a key likely stems from bad operational hygiene, not from = advances in cryptography. Rolling keys won't help here. I agree with EKR. I don't appreciate the frequent rollover syndrome.=20 Roy= From ekr@rtfm.com Thu Jan 21 14:37:07 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271A528C160 for ; Thu, 21 Jan 2010 14:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, US_DOLLARS_3=0.63] 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 Up9dDs8Sf+UI for ; Thu, 21 Jan 2010 14:37:06 -0800 (PST) Received: from mail-yw0-f201.google.com (mail-yw0-f201.google.com [209.85.211.201]) by core3.amsl.com (Postfix) with ESMTP id 5E6FC28C105 for ; Thu, 21 Jan 2010 14:37:06 -0800 (PST) Received: by ywh39 with SMTP id 39so1043707ywh.17 for ; Thu, 21 Jan 2010 14:36:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.47.6 with SMTP id u6mr2050458agu.22.1264113417986; Thu, 21 Jan 2010 14:36:57 -0800 (PST) In-Reply-To: References: Date: Thu, 21 Jan 2010 14:36:57 -0800 Message-ID: From: Eric Rescorla To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsop WG , Edward Lewis Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 22:37:07 -0000 On Thu, Jan 21, 2010 at 2:24 PM, Paul Wouters wrote: > On Thu, 21 Jan 2010, Edward Lewis wrote: > >> What I'd like to hear is: >> >> "Crypto-expert __________ says an RSA-SHA256 key of 1024 bits is good fo= r >> _______ signatures/days." > > I did ask my local Waterloo based cryptographer (Ian Goldberg) this > question about a year ago for RSA-SHA1. And apart from his advise to use > RSASSA-PSS and not PKCS1-v1_5, he thought a year would be extremely safe. > I just asked another Toronto based cryptographer, Kelly Rose, the same > question, and he said he would not trust it for more then two years. > > Also, consider this paper from July 2009: > > https://documents.epfl.ch/users/l/le/lenstra/public/papers/ecdl.pdf > > =A0 =A0Next considering special purpose hardware, the most optimistic > =A0 =A0approach suggests that sieving for a 1024-bit RSA modulus can be > =A0 =A0done in a year for about US $10,000,000, plus a one-time developme= nt > =A0 =A0cost of about US $20,000,000, And if your attacker has a budget of $1,000,000? Or $100,000,000? The point is that the numbers depend on your model of the attacker more than on the cryptography. -Ekr From tglassey@earthlink.net Thu Jan 21 14:57:54 2010 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D4C28C126 for ; Thu, 21 Jan 2010 14:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, 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 pnOUhNp2chd6 for ; Thu, 21 Jan 2010 14:57:52 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 5C0A528C0EA for ; Thu, 21 Jan 2010 14:57:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Yht3dwMx8AHatr70y7Ukxxq63SfoKcuPP8uCnEWzaMRblvwjPcaTbk0fdEvePtS6; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.149] (helo=[192.168.1.168]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NY5yF-0002ke-Uj for dnsop@ietf.org; Thu, 21 Jan 2010 17:57:48 -0500 Message-ID: <4B58DBEB.8000904@earthlink.net> Date: Thu, 21 Jan 2010 14:57:47 -0800 From: Todd Glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: dnsop@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070909000509090809060301" X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7968d7380a0484c5a57d4a4c783d104231350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.149 Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 22:57:54 -0000 This is a multi-part message in MIME format. --------------070909000509090809060301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/21/2010 12:12 PM, Eric Rescorla wrote: > On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman wrote: > >> At 2:17 PM -0500 1/21/10, Edward Lewis wrote: >> >>> At 11:05 -0800 1/21/10, Eric Rescorla wrote: >>> >>>> I still don't understand why this implies the need for regular changes >>>> as opposed to changes triggered by personnel changes. >>>> >>> I'm a bit lost following this thread now. >>> >>> For the time being, let's ignore personnel changes and whether a key is in an HSM (environment), i.e., assume there's no organizational threat to a key. >>> >>> The question is, how long does a key last? >>> >>> Meaning - if I am using an RSA-SHA256 key of 1024 bits, at what point does it's security value reach essentially 0? >>> >>> Is the point X number of signatures? >>> >> No. There is no suspicion on the part of any cryptographer that I know of that the number of visible signatures is significant for a 1024-bit or above key. >> > Agreed. Recall that with PKC an attacker can generate as many > plaintext/ciphertext pairs as > he wants. > > > >>> Is the point Y number of days? >>> >> Yes, if the number of days is in the thousands (currently) and the value of this key is high. Otherwise, no. >> > I actually sort of disagree with this. I don't see how to evaluate > this question in a meaningful > way, and it's not a cryptographic question. Let's say for the sake of > argument that we know > if requires C CPU-hours to break a key and that each CPU costs $H but > is free to run once > you own it (not true). In that case, an attacker with $D to spend can > break a single key in > C/(D/H) hours. How long is that key secure for? Who knows. Most of > the variance is in attacker > motivation and funding, not time. > > > > Actually Eric if the credential is only valid for a period of time which is less than the amount of time needed with CPU Resource created by $D (i.e the money to pay for CPU $H) then the process is very relevant so the issue is how long is the credential negotiable for and is that number less than the perimeter of the 'can be hacked with these resources' ??? http://www.nvidia.com/object/cuda_home.html# >> For most keys, no, at least for the next five years or so. No its not. >> That is, the *cost* of breaking a 1024-bit key, when that is feasible, is still much higher than the value of the broken key. The problem is that nVidia CUDA based brute force engines are available that produce 42TF of compute engine off the shelf and for under 10K... and gee whiz they rock for factoring. Especially when ten gamers get together and put 20 of the SLI enabled GX2 and other quad GPU cards which effectively sport 240 thread cores per card. Compare that to the wimpy Quad-Core P4's on the market today and you will start to see the future. In this instance nVidia's TESLA systems rock http://www.nvidia.com/object/tesla_computing_solutions.html - Imaging what you can do to a PW with one of these running FreeBSD or Linux and John the Ripper. I think its less than 2 years before factoring engines based on nVidia Cores are common place outside the NSA. >> Remember that a broken signing key is only valuable until the fact that it is broken is discovered and fixed. So, even if an attacker breaks your signing key, when he/she starts to use it for nefarious purposes and you discover that, you roll your key and the entire time of breaking the new key must be used again before they can mount another attack. >> > Exactly. So rolling it preemptively doesn't help much. > > -Ekr > > > >>> The "need for regular changes" stems from assumptions made in the early days of DNSSEC development that have gone pretty much unchallenged until recently. The door is open to (re)visit this topic, if anyone wants to venture opinions. >>> >> See above. :-) >> > So, the referenced post summarizes my opinion. I don't care enough about it to > fight it to the death here, however. > > > >>> What I'd like to hear is: >>> >>> "Crypto-expert __________ says an RSA-SHA256 key of 1024 bits is good for _______ signatures/days." >>> >> If you hear that, the the value for the first variable will be worthless. You have to factor in the value of the key to the attacker for the short period in which they can use it before their actions are discovered and the broken key is replaced. >> > > I more or less agree with this. You may want to hear that, but there's > no meaningful answer. > > -Ekr > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.432 / Virus Database: 271.1.1/2636 - Release Date: 01/21/10 07:34:00 > > --------------070909000509090809060301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/21/2010 12:12 PM, Eric Rescorla wrote: 
On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
  
At 2:17 PM -0500 1/21/10, Edward Lewis wrote:
    
At 11:05 -0800 1/21/10, Eric Rescorla wrote:
      
I still don't understand why this implies the need for regular changes
as opposed to changes triggered by personnel changes.
        
I'm a bit lost following this thread now.

For the time being, let's ignore personnel changes and whether a key is in an HSM (environment), i.e., assume there's no organizational threat to a key.

The question is, how long does a key last?

Meaning - if I am using an RSA-SHA256 key of 1024 bits, at what point does it's security value reach essentially 0?

Is the point X number of signatures?
      
No. There is no suspicion on the part of any cryptographer that I know of that the number of visible signatures is significant for a 1024-bit or above key.
    
Agreed. Recall that with PKC an attacker can generate as many
plaintext/ciphertext pairs as
he wants.


  
Is the point Y number of days?
      
Yes, if the number of days is in the thousands (currently) and the value of this key is high. Otherwise, no.
    
I actually sort of disagree with this. I don't see how to evaluate
this question in a meaningful
way, and it's not a cryptographic question. Let's say for the sake of
argument that we know
if requires C CPU-hours to break a key and that each CPU costs $H but
is free to run once
you own it (not true). In that case, an attacker with $D to spend can
break a single key in
C/(D/H) hours.  How long is that key secure for? Who knows. Most of
the variance is in attacker
motivation and funding, not time.
Actually Eric if the credential is only valid for a period of time which is less than the amount of time needed with CPU Resource created by $D (i.e the money to pay for CPU $H) then the process is very relevant so the issue is how long is the credential negotiable for and is that number less than the perimeter of the 'can be hacked with these resources' ???

http://www.nvidia.com/object/cuda_home.html#




  

    
For most keys, no, at least for the next five years or so. 

  



No its not.  



  

    
That is, the *cost* of breaking a 1024-bit key, when that is feasible, is still much higher than the value of the broken key. 

  



 The problem is that nVidia CUDA based brute force engines are
available that produce 42TF of compute engine off the shelf and for
under 10K... and gee whiz they rock for factoring. Especially when ten
gamers get together and put 20 of the SLI enabled GX2 and other quad
GPU cards which effectively sport 240 thread cores per card. Compare
that to the wimpy Quad-Core P4's on the market today and you will start
to see the future.  



In this instance nVidia's TESLA systems rock
http://www.nvidia.com/object/tesla_computing_solutions.html - Imaging
what you can do to a PW with one of these running FreeBSD or Linux and
John the Ripper. I think its less than 2 years before factoring engines
based on nVidia Cores are common place outside the NSA. 



  

    
Remember that a broken signing key is only valuable until the fact that it is broken is discovered and fixed. So, even if an attacker breaks your signing key, when he/she starts to use it for nefarious purposes and you discover that, you roll your key and the entire time of breaking the new key must be used again before they can mount another attack.
    

  

  
Exactly. So rolling it preemptively doesn't help much.

-Ekr


  

  

    

      
The "need for regular changes" stems from assumptions made in the early days of DNSSEC development that have gone pretty much unchallenged until recently.  The door is open to (re)visit this topic, if anyone wants to venture opinions.
      

    

    
See above. :-)
    

  

  
So, the referenced post summarizes my opinion. I don't care enough about it to
fight it to the death here, however.


  

  

    

      
What I'd like to hear is:

"Crypto-expert __________ says an RSA-SHA256 key of 1024 bits is good for _______ signatures/days."
      

    

    
If you hear that, the the value for the first variable will be worthless. You have to factor in the value of the key to the attacker for the short period in which they can use it before their actions are discovered and the broken key is replaced.
    

  

  

I more or less agree with this. You may want to hear that, but there's
no meaningful answer.

-Ekr
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

  


No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.432 / Virus Database: 271.1.1/2636 - Release Date: 01/21/10 07:34:00

  








--------------070909000509090809060301--

From tglassey@earthlink.net  Thu Jan 21 15:03:28 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE59528C0EA for ; Thu, 21 Jan 2010 15:03:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.044
X-Spam-Level: 
X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.554,  BAYES_00=-2.599, 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 9qUqQoOlufqT for ; Thu, 21 Jan 2010 15:03:27 -0800 (PST)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 485043A6920 for ; Thu, 21 Jan 2010 15:03:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=DmF21RbAxyPomjfvfGIF6zYU9YWAwyJhaBbSco7X47U9Eb3vOtozEcmk5w+Qa/Ed; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.149] (helo=[192.168.1.168]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NY63f-0005Wq-21 for dnsop@ietf.org; Thu, 21 Jan 2010 18:03:23 -0500
Message-ID: <4B58DD3A.5010203@earthlink.net>
Date: Thu, 21 Jan 2010 15:03:22 -0800
From: Todd Glassey 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: dnsop@ietf.org
References: 							<20100121202745.GZ81286@shinkuro.com>		 <20100121212937.GB81286@shinkuro.com>
In-Reply-To: <20100121212937.GB81286@shinkuro.com>
Content-Type: multipart/alternative; boundary="------------050207060803020504040506"
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec791688758f2778578f04d3de93f1edbb94350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.149
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 23:03:28 -0000

This is a multi-part message in MIME format.
--------------050207060803020504040506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 1/21/2010 1:29 PM, Andrew Sullivan wrote:
> On Thu, Jan 21, 2010 at 04:14:03PM -0500, Edward Lewis wrote:
>    
>> I'm finding this discussion enlightening and interesting.
>>      
> Me too.  I also think that discussion of exactly this sort belongs in
> the advice we give to operators.  Understanding the trade-offs and the
> reason for them is exactly what makes for selecting the right policies
> given the operational considerations of the environment in which one
> is working.  I don't think there's one answer for this question,
> because what is right is surely related to other considerations.
>
>    
Andrew you are right here - its not a matter of what is right - its a 
matter of "how to" and that's the key I think.
> For instance, despite what David says downthread about operational
> realities and exercise, such exercise is a complete waste of time if
> the person who does the work is different every time (as might well be
> the case under a lot of outsourcing contracts).
Hmmm - let me push back. Not necessarily - the real issue is the proper 
evidence of the functioning of the DNSOP is the key here. The problem is 
that DNS log data sucks now. It was designed by techies for debugging 
and not for evidence which is what it needs to be specifically. That 
said - the real issue is how chain of custody is maintained and proven 
after the fact since in the real time if the DNS doesnt work or works 
wrong theorhetically the user is bright enough to catch that, but  
longer term - how to you prove three years in the future that the 
resolutions done today actually happened and were done correctly.

 From my point of view this isnt about just working right in the present 
its about working right in creating enduring evidence of that operation.

Todd Glassey
> In that circumstance,
> Paul is probably right: the risk of blowing the key roll outweighs the
> benefits of practice.
>
> One also worries a little that many operations people (me included) so
> often think "you need to practice this" includes "in production".
> (But I haven't worked many places where I've had a real, true,
> complete copy of my production systems just for running fire drills.)
>
> A
>
>    
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.432 / Virus Database: 271.1.1/2636 - Release Date: 01/21/10 07:34:00
>
>    


--------------050207060803020504040506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


On 1/21/2010 1:29 PM, Andrew Sullivan wrote:


  
On Thu, Jan 21, 2010 at 04:14:03PM -0500, Edward Lewis wrote:
  

  

    
I'm finding this discussion enlightening and interesting.
    

  

  
Me too.  I also think that discussion of exactly this sort belongs in
the advice we give to operators.  Understanding the trade-offs and the
reason for them is exactly what makes for selecting the right policies
given the operational considerations of the environment in which one
is working.  I don't think there's one answer for this question,
because what is right is surely related to other considerations.

  



Andrew you are right here - its not a matter of what is right - its a
matter of "how to" and that's the key I think. 



  
For instance, despite what David says downthread about operational
realities and exercise, such exercise is a complete waste of time if
the person who does the work is different every time (as might well be
the case under a lot of outsourcing contracts). 



Hmmm - let me push back. Not necessarily - the real issue is the proper
evidence of the functioning of the DNSOP is the key here. The problem
is that DNS log data sucks now. It was designed by techies for
debugging and not for evidence which is what it needs to be
specifically. That said - the real issue is how chain of custody is
maintained and proven after the fact since in the real time if the DNS
doesnt work or works wrong theorhetically the user is bright enough to
catch that, but  longer term - how to you prove three years in the
future that the resolutions done today actually happened and were done
correctly. 



>From my point of view this isnt about just working right in the present
its about working right in creating enduring evidence of that
operation. 



Todd Glassey



  
In that circumstance,
Paul is probably right: the risk of blowing the key roll outweighs the
benefits of practice.

One also worries a little that many operations people (me included) so
often think "you need to practice this" includes "in production".
(But I haven't worked many places where I've had a real, true,
complete copy of my production systems just for running fire drills.)

A

  

  


No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.432 / Virus Database: 271.1.1/2636 - Release Date: 01/21/10 07:34:00

  








--------------050207060803020504040506--

From jim@rfc1035.com  Thu Jan 21 15:03:37 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413103A6AF9 for ; Thu, 21 Jan 2010 15:03:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.009
X-Spam-Level: 
X-Spam-Status: No, score=-3.009 tagged_above=-999 required=5 tests=[AWL=-0.410, 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 htEPAEWFoOFA for ; Thu, 21 Jan 2010 15:03:36 -0800 (PST)
Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 2CDA93A6AF7 for ; Thu, 21 Jan 2010 15:03:36 -0800 (PST)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id E61BD154283B; Thu, 21 Jan 2010 23:03:29 +0000 (GMT)
Message-Id: <645C47F3-91A7-4874-B0DD-402F1A7AE307@rfc1035.com>
From: Jim Reid 
To: Roy Arends 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 21 Jan 2010 23:03:29 +0000
References: 	 	 	 	 	 	 <20100121202745.GZ81286@shinkuro.com>	 	 	 <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org>   
X-Mailer: Apple Mail (2.936)
Cc: Eric Rescorla , Andrew Sullivan , dnsop@ietf.org, Edward Lewis , Paul Hoffman , David Conrad 
Subject: [DNSOP] key rollover for real
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 23:03:37 -0000

On 21 Jan 2010, at 22:11, Roy Arends wrote:

> I'd recommend that 'exercise the activity' is not done on critical  
> production systems.

I'd recommend the opposite. Sort of: carry out these drills in the  
production environment but clearly not on the systems that are  
actually handling the operational load.

If your processes and policies aren't up to the job of working in a  
critical production environment, they're fundamentally broken because  
they don't do what they're supposed to do. Think about it Roy. Key  
rollovers will *have* to be done in a production environment, and not  
always according to a previously planned schedule. So whatever  
processes and procedures someone devises for doing a key rollover  
should be robust enough to cope with emergencies such as a compromised  
key.

True mission critical environments know how to handle scheduled  
changes and unplanned interventions: -- applying patches, replacing  
hardware, OS upgrades, etc -- without compromising service. In such  
settings, a key rollover would just be another thing to add to the ops  
team's list and it shouldn't matter if that rollover was planned or not.


From paul@xelerance.com  Thu Jan 21 15:09:01 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC393A681B for ; Thu, 21 Jan 2010 15:09:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.705
X-Spam-Level: 
X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, US_DOLLARS_3=0.63]
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 z0D+cE55UYan for ; Thu, 21 Jan 2010 15:09:01 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id DD2723A659B for ; Thu, 21 Jan 2010 15:09:00 -0800 (PST)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id F3E58571B3; Thu, 21 Jan 2010 18:08:55 -0500 (EST)
Date: Thu, 21 Jan 2010 18:08:55 -0500 (EST)
From: Paul Wouters 
To: Eric Rescorla 
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=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Cc: dnsop WG 
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 23:09:01 -0000

On Thu, 21 Jan 2010, Eric Rescorla wrote:

>> Also, consider this paper from July 2009:
>>
>> https://documents.epfl.ch/users/l/le/lenstra/public/papers/ecdl.pdf
>>
>>    Next considering special purpose hardware, the most optimistic
>>    approach suggests that sieving for a 1024-bit RSA modulus can be
>>    done in a year for about US $10,000,000, plus a one-time development
>>    cost of about US $20,000,000,
>
>
> And if your attacker has a budget of $1,000,000? Or $100,000,000?
>
> The point is that the numbers depend on your model of the attacker
> more than on the cryptography.

The full paper has a cost matrix. Though I just noticed they changed the
URL of the paper :(

Paul

From roy@dnss.ec  Thu Jan 21 15:55:51 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4FA28C1C2 for ; Thu, 21 Jan 2010 15:55:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.016
X-Spam-Level: 
X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.233,  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 3mLDB2NiV7Fj for ; Thu, 21 Jan 2010 15:55:51 -0800 (PST)
Received: from mail.schlyter.se (trinitario.schlyter.se [195.47.254.10]) by core3.amsl.com (Postfix) with ESMTP id DDA593A67B7 for ; Thu, 21 Jan 2010 15:55:50 -0800 (PST)
Received: from [192.168.1.2] (unknown [201.238.167.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roy) by mail.schlyter.se (Postfix) with ESMTPSA id EB8042D4AD; Fri, 22 Jan 2010 00:55:17 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Roy Arends 
In-Reply-To: <645C47F3-91A7-4874-B0DD-402F1A7AE307@rfc1035.com>
Date: Thu, 21 Jan 2010 18:55:11 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 	 	 	 	 	 	 <20100121202745.GZ81286@shinkuro.com>	 	 	 <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org>    <645C47F3-91A7-4874-B0DD-402F1A7AE307@rfc1035.com>
To: Jim Reid 
X-Mailer: Apple Mail (2.1077)
Cc: Eric Rescorla , Andrew Sullivan , dnsop@ietf.org, Edward Lewis , David Conrad , Paul Hoffman 
Subject: Re: [DNSOP] key rollover for real
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 23:55:51 -0000

On Jan 21, 2010, at 6:03 PM, Jim Reid wrote:

> On 21 Jan 2010, at 22:11, Roy Arends wrote:
>=20
>> I'd recommend that 'exercise the activity' is not done on critical =
production systems.
>=20
> I'd recommend the opposite. Sort of: carry out these drills in the =
production environment but clearly not on the systems that are actually =
handling the operational load.
> If your processes and policies aren't up to the job of working in a =
critical production environment, they're fundamentally broken because

Hold on a minute. I'm referring to 'exercise the activity' as in =
practicing the processes and policies. You are saying that processes and =
policies should be up to the job. Those are two different things.

> they don't do what they're supposed to do. Think about it Roy. Key =
rollovers will *have* to be done in a production environment, and not =
always according to a previously planned schedule.

Sure.

> So whatever processes and procedures someone devises for doing a key =
rollover should be robust enough to cope with emergencies such as a =
compromised key.

Absolutely. Until then, don't roll.=20

> True mission critical environments know how to handle scheduled =
changes and unplanned interventions: -- applying patches, replacing =
hardware, OS upgrades, etc -- without compromising service. In such =
settings, a key rollover would just be another thing to add to the ops =
team's list and it shouldn't matter if that rollover was planned or not.

Absolutely.=20

I'm all for proper policies, procedures, processes. You get there by =
(among other things) 'exercise the activity'. I'm also for that. I'm =
arguing that the exercising should not be done on critical production =
systems. Think about it Jim.

Roy




From ekr@rtfm.com  Thu Jan 21 16:42:07 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F153A6801 for ; Thu, 21 Jan 2010 16:42:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.617
X-Spam-Level: 
X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, US_DOLLARS_3=0.63]
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 doEw5njDyvpy for ; Thu, 21 Jan 2010 16:42:06 -0800 (PST)
Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 1C0513A67B7 for ; Thu, 21 Jan 2010 16:42:06 -0800 (PST)
Received: by yxe30 with SMTP id 30so585473yxe.29 for ; Thu, 21 Jan 2010 16:41:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.91.27.2 with SMTP id e2mr2161777agj.32.1264120919084; Thu, 21  Jan 2010 16:41:59 -0800 (PST)
In-Reply-To: 
References:        
Date: Thu, 21 Jan 2010 16:41:58 -0800
Message-ID: 
From: Eric Rescorla 
To: Paul Wouters 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: dnsop WG 
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 00:42:07 -0000

On Thu, Jan 21, 2010 at 3:08 PM, Paul Wouters  wrote:
> On Thu, 21 Jan 2010, Eric Rescorla wrote:
>
>>> Also, consider this paper from July 2009:
>>>
>>> https://documents.epfl.ch/users/l/le/lenstra/public/papers/ecdl.pdf
>>>
>>> =A0 =A0Next considering special purpose hardware, the most optimistic
>>> =A0 =A0approach suggests that sieving for a 1024-bit RSA modulus can be
>>> =A0 =A0done in a year for about US $10,000,000, plus a one-time develop=
ment
>>> =A0 =A0cost of about US $20,000,000,
>>
>>
>> And if your attacker has a budget of $1,000,000? Or $100,000,000?
>>
>> The point is that the numbers depend on your model of the attacker
>> more than on the cryptography.
>
> The full paper has a cost matrix. Though I just noticed they changed the
> URL of the paper :(

Yes, but my point is that the safety period depends on your assumptions
about the attacker's resources, which is why this is not really a technical
issue.

-Ekr

From jim@rfc1035.com  Thu Jan 21 16:57:20 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F0D28C103 for ; Thu, 21 Jan 2010 16:57:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.972
X-Spam-Level: 
X-Spam-Status: No, score=-2.972 tagged_above=-999 required=5 tests=[AWL=-0.373, 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 CxdWo7XEzorR for ; Thu, 21 Jan 2010 16:57:20 -0800 (PST)
Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id E5A1628C0F7 for ; Thu, 21 Jan 2010 16:57:19 -0800 (PST)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 19A89154283B; Fri, 22 Jan 2010 00:57:14 +0000 (GMT)
Message-Id: <503DA9EF-A56F-4069-8C79-ED09F30FFD69@rfc1035.com>
From: Jim Reid 
To: Roy Arends 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 22 Jan 2010 00:57:13 +0000
References: 	 	 	 	 	 	 <20100121202745.GZ81286@shinkuro.com>	 	 	 <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org>    <645C47F3-91A7-4874-B0DD-402F1A7AE307@rfc1035.com> 
X-Mailer: Apple Mail (2.936)
Cc: Eric Rescorla , Andrew Sullivan , dnsop@ietf.org, Edward Lewis , David Conrad , Paul Hoffman 
Subject: Re: [DNSOP] key rollover for real
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 00:57:20 -0000

On 21 Jan 2010, at 23:55, Roy Arends wrote:

> I'm arguing that the exercising should not be done on critical  
> production systems.

Argue all you like. :-) But if those procedures, policies and  
processes are not exercised on the critical production systems *for  
real* there is no way of knowing for sure if they'll work or not. It  
would be most unfortunate to discover that they don't work whenever  
there's a genuine reason for using them on the critical production  
environment. By all means test them and run exercises elsewhere, but  
they do need to be invoked from time to time in the live environment.  
And not just for drills.

From roy@dnss.ec  Thu Jan 21 17:42:38 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04AD13A67B7 for ; Thu, 21 Jan 2010 17:42:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.075
X-Spam-Level: 
X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.175,  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 O7m76+2tGo2F for ; Thu, 21 Jan 2010 17:42:37 -0800 (PST)
Received: from mail.schlyter.se (trinitario.schlyter.se [195.47.254.10]) by core3.amsl.com (Postfix) with ESMTP id 207A03A67E5 for ; Thu, 21 Jan 2010 17:42:37 -0800 (PST)
Received: from [192.168.1.2] (unknown [201.238.167.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roy) by mail.schlyter.se (Postfix) with ESMTPSA id 992902D4D4; Fri, 22 Jan 2010 02:42:25 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Roy Arends 
In-Reply-To: <503DA9EF-A56F-4069-8C79-ED09F30FFD69@rfc1035.com>
Date: Thu, 21 Jan 2010 20:42:21 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <6CAF0EAA-5AD7-4E3D-A503-3B55AB0CE34B@dnss.ec>
References: 	 	 	 	 	 	 <20100121202745.GZ81286@shinkuro.com>	 	 	 <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org>    <645C47F3-91A7-4874-B0DD-402F1A7AE307@rfc1035.com>  <503DA9EF-A56F-4069-8C79-ED09F30FFD69@rfc1035.com>
To: Jim Reid 
X-Mailer: Apple Mail (2.1077)
Cc: Eric Rescorla , Andrew Sullivan , dnsop@ietf.org, Edward Lewis , Paul Hoffman , David Conrad 
Subject: Re: [DNSOP] key rollover for real
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 01:42:38 -0000

On Jan 21, 2010, at 7:57 PM, Jim Reid wrote:

> On 21 Jan 2010, at 23:55, Roy Arends wrote:
>=20
>> I'm arguing that the exercising should not be done on critical =
production systems.
>=20
> Argue all you like. :-) But if those procedures, policies and =
processes are not exercised on the critical production systems *for =
real* there is no way of knowing for sure if they'll work or not.

You're contradicting yourself. Just minutes ago, you wrote:

"True mission critical environments know how to handle scheduled changes =
and unplanned interventions: -- applying patches, replacing hardware, OS =
upgrades, etc -- without compromising service. In such settings, a key =
rollover would just be another thing to add to the ops team's list and =
it shouldn't matter if that rollover was planned or not."

> It would be most unfortunate to discover that they don't work whenever =
there's a genuine reason for using them on the critical production =
environment.

Indeed it would. I'm not saying that procedures shouldn't be tested. I'm =
telling you that when you want to educate an SA, you do it elsewhere. If =
you want to test a procedure, you do that _within_ the company, on its =
own time schedule, without unnecessary announcements. I really hope you =
agree that its silly to roll a key frequently, say monthly and announce =
the exact time when you're going to roll it, giving miscreant another =
chance next month if they miss the opportunity to mess things up. That =
is what is currently happening. There is a danger in that. When I point =
that out, folks immediately grab RFC4641, telling me they _have_ to roll =
frequently.

> By all means test them and run exercises elsewhere,

Thank you!

> but they do need to be invoked from time to time in the live =
environment.

Sure.=20

> And not just for drills.

Fine.

Roy=

From paul@xelerance.com  Thu Jan 21 21:09:17 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9933A686E for ; Thu, 21 Jan 2010 21:09:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.873
X-Spam-Level: 
X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=-0.274, 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 Pn3vA4lp2QiF for ; Thu, 21 Jan 2010 21:09:16 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 92FE63A6851 for ; Thu, 21 Jan 2010 21:09:16 -0800 (PST)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 9BF2E571B3; Fri, 22 Jan 2010 00:09:11 -0500 (EST)
Date: Fri, 22 Jan 2010 00:09:11 -0500 (EST)
From: Paul Wouters 
To: Eric Rescorla 
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: dnsop WG 
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 05:09:17 -0000

On Thu, 21 Jan 2010, Eric Rescorla wrote:

>>> The point is that the numbers depend on your model of the attacker
>>> more than on the cryptography.

> Yes, but my point is that the safety period depends on your assumptions
> about the attacker's resources, which is why this is not really a technical
> issue.

It is also based on the presumed technological advances of attackers. If
you talk to a cryptographer about a 1024 bit RSA key, they will tell you
"don't use that anymore". When you tell them "well, it is very useful
to us to reduce packet size in DNS" they tell you "go use ECC".

We made a technological trade of. Though extremely conservative, all the
cryptographers (or really cryptanalysts) I talked to are more conservative
then we have been. Whether you call this technical or philosophical, does
not really change the issue. The model of the attacker is a fundamental
part of the cryptography.

Paul

From ekr@rtfm.com  Thu Jan 21 21:24:50 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9F93A6866 for ; Thu, 21 Jan 2010 21:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.079,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 hpnNZ7Md7lsh for ; Thu, 21 Jan 2010 21:24:49 -0800 (PST)
Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 5C2E03A6864 for ; Thu, 21 Jan 2010 21:24:49 -0800 (PST)
Received: by yxe30 with SMTP id 30so759845yxe.29 for ; Thu, 21 Jan 2010 21:24:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.91.79.14 with SMTP id g14mr2360416agl.37.1264137880059; Thu,  21 Jan 2010 21:24:40 -0800 (PST)
In-Reply-To: 
References:          
Date: Thu, 21 Jan 2010 21:24:39 -0800
Message-ID: 
From: Eric Rescorla 
To: Paul Wouters 
Content-Type: text/plain; charset=ISO-8859-1
Cc: dnsop WG 
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 05:24:50 -0000

On Thu, Jan 21, 2010 at 9:09 PM, Paul Wouters  wrote:
> On Thu, 21 Jan 2010, Eric Rescorla wrote:
>
>>>> The point is that the numbers depend on your model of the attacker
>>>> more than on the cryptography.
>
>> Yes, but my point is that the safety period depends on your assumptions
>> about the attacker's resources, which is why this is not really a
>> technical
>> issue.
>
> It is also based on the presumed technological advances of attackers. If
> you talk to a cryptographer about a 1024 bit RSA key, they will tell you
> "don't use that anymore". When you tell them "well, it is very useful
> to us to reduce packet size in DNS" they tell you "go use ECC".
>
> We made a technological trade of. Though extremely conservative, all the
> cryptographers (or really cryptanalysts) I talked to are more conservative
> then we have been. Whether you call this technical or philosophical, does
> not really change the issue. The model of the attacker is a fundamental
> part of the cryptography.

I really have no idea what you're talking about here. There is widespread
agreement about the technical difficulty of attacking RSA. The question
of how that impacts your behaviors has primarily an economic question,
not a cryptographic one.

With that said, cryptographers actually don't tend to think particularly deeply
about the attack model; rather they assume a certain fairly idealized model
of attacker capabilities and try to demonstrate that their systems have
certain properties under those models. This is fundamentally different
from the kind of thinking required here.

-Ekr

From olaf@NLnetLabs.nl  Fri Jan 22 03:04:24 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738213A695F for ; Fri, 22 Jan 2010 03:04:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Level: 
X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, 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 3uiki77G6TXY for ; Fri, 22 Jan 2010 03:04:23 -0800 (PST)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 6AF513A687C for ; Fri, 22 Jan 2010 03:04:22 -0800 (PST)
Received: from [IPv6:2001:7b8:206:1:226:bbff:fe0e:7cc7] ([IPv6:2001:7b8:206:1:226:bbff:fe0e:7cc7]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0MB4GOY050311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Jan 2010 12:04:16 +0100 (CET) (envelope-from olaf@NLnetLabs.nl)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Olaf Kolkman 
In-Reply-To: 
Date: Fri, 22 Jan 2010 12:04:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl>
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl> 
To: dnsop WG 
X-Mailer: Apple Mail (2.1077)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 22 Jan 2010 12:04:16 +0100 (CET)
Subject: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 11:04:24 -0000

On Jan 21, 2010, at 6:52 PM, Paul Wouters wrote:

> On Thu, 21 Jan 2010, Olaf Kolkman wrote:
>=20
>> In trying to get a reasonable version 2 out of the door before =
Anaheim I am trying to identify and where possibly close open issues.
>>=20
>> As a reminder: =
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has the open =
issues listed and a per issue highlight of their history.
>=20
> I still don't see any recommendations regarding NSEC vs NSEC3. I =
mailed you
> some comments about two IETF's ago I believe. Do you still have that =
email,
> or should I try to dig it out?

That was oversight. In fact I need to close/re read the mail (and follow =
up thread) on your comments on the other topics. But for the benefit of =
opening discussion here is the relevant open issue =
(http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/NSEC-NSEC3) =
including your straw man text for the working group to comment on.

--Olaf


$Id: NSEC-NSEC3 36 2010-01-22 11:02:32Z olaf $
20100122
   NSEC-NSEC3
   Paul Wouters
   Added: 22 jan 2010
  =20
   Discussion missing about NSEC vs NSEC3 Parameters
   from:
   http://www.ietf.org/mail-archive/web/dnsop/current/msg07282.html

Discussion:

	From: 	Paul Wouters 
	Subject: 	Comments/Additions on I-D =
Action:draft-ietf-dnsop-rfc4641bis-01.txt
	Date: 	April 28, 2009 12:23:21 AM GMT+02:00
	To: 	Olaf Kolkman 
	Cc: 	dnsop WG , namedroppers@ops.ietf.org WG =




I am furthermore missing a discussion on NSEC vs NSEC3 and NSEC3 =
parameters.
I've tried to write something sensible that is included below, as a =
presumed
section 5:


5 Next Record type

There are currently two types of next records that are provide
authenticated denial of existence of DNS data in a zone.

- The NSEC (RFC 4034) record builds a linked list of sorted RRlabels
 with their record types in the zone.

- The NSEC3 (RFC5 155) record builds a similar linked list, but
 uses hashes instead of the RRLabels.

5.1 Reasons for the existence of NSEC and NSEC3

The NSEC record requires no cryptographic operations aside from =
validating
its associated signature record. It is human readable and can be used in
manual queries to determin correct operation.  The disadvantage is that =
it
allows for "zone walking", where one can request all the entries of a =
zone
by following the next RRlabel pointed to in each subsequent NSEC record.

Though some claim all data in the DNS should be considered public, it
sometimes is considered to be more then private, but less then public =
data.

The NSEC3 record uses a hashing method of the requested RRlabel.
To increase the workload required to guess entries in the zone, the =
number
of hashing interations can be specified in the NSEC3 record. =
Additionally,
a salt can be specified that also modifies the hashes. Note that NSEC3
does not give full protection against information leakage from the zone.

5.2 NSEC or NSEC3

For small zones that only contain contain records in the APEX and a few
common (guessable) RRlabels such as "www" or "mail", NSEC3 provides no
real additional security, and the use of NSEC is recommended to ease
the work required by signers and validating resolvers.

For large zones where there is an implication of "not readilly =
available"
RRlabels, such as those where one has to sign an NDA before obtaining =
it,
NSEC3 is recommended.

5.3 NSEC3 parameters

The NSEC3 hashing includes the FQDN in its uncompressed form. This
ensures brute force work done by an attacker for one (FQDN) RRlabel
cannot be re-used for another (FQDN) RRlabel attack, as these entries
are per definition unique.

5.3.1 NSEC3 Algorithm

The NSEC3 algorithm is specified as a version of the DNSKEY algorithm.
The current options are:

Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm 3, DSA.
Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5, RSASHA1.

The algorithm choice therefor depends solely on the DNSKEY algorithm
picked.

[Note that there is an issue here as well as mentioned in Section 3.4
regarding RSASSA-PKCS1-v1_5 vs RSASSA-PSS as well as no algorithm choice
for SHA-256]

5.3.2 NSEC3 Iterations

RFC-5155 describes the useful limits of iterations compared to RSA key
size. These are 150 iterations for 1024 bit keys, 500 iterations for
2048 bit keys and 2,500 iterations for 4096 bit keys. Choosing 2/3rd of
the maximum is deemed to be a sufficiently costly yet not excessive =
value.

5.3.3 NSEC3 Salt

The salt with NSEC3 is not used to increase the work required by an
attacker attacking multiple domains, but as a method to enable creating =
a
new set of hash values if at some point that might be required. The salt
is used as a "roll over". The FQDN RRlabel, which is part of the value
that is hashed, already ensures that brute force work for one RRlabel
can not be re-used to attack other RRlabel due to their uniquenes.

Key rollovers limit the amount of time attackers can spend on attacking
a certain key before it is retired. The salt serves the same purpose for
the hashes, which are independant of the key being used, and therefor
do not change when rolling over a key. Changing the salt would cause an
attacker to lose all precalculated work for that zone.

The salt of all NSEC3 records in a zone needs to be the same.
Since changing the salt requires the NSEC3 records to be regenerated,
and thus requires generating new RRSIG's over these NSEC3 records, it
is recommended to only change the salt when changing the Zone Signing =
Key,
as that process in itself already requires all RRSIG's to be =
regenerated.

5.3.4 Opt-out

An Opt-Out NSEC3 RR does not assert the existence or non-existence of =
the
insecure delegations that it may cover. This allows for the addition or
removal of these delegations without recalculating or re- signing RRs in
the NSEC3 RR chain. Therefor, Opt-Out should be avoided if possible. A
scenario where one of the authoratative nameservers of a zone does not
have enough resources to hold the additional NSEC3 records in memory is
one of very few reasons to deploy with Opt-Out.









________________________________________________________=20

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140,=20
http://www.nlnetlabs.nl/               1098 XG Amsterdam


From marka@isc.org  Fri Jan 22 04:09:24 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236523A6965 for ; Fri, 22 Jan 2010 04:09:24 -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 v8awrv-txQm6 for ; Fri, 22 Jan 2010 04:09:23 -0800 (PST)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 04EF33A68F1 for ; Fri, 22 Jan 2010 04:09:23 -0800 (PST)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 47221E60D3; Fri, 22 Jan 2010 12:09:17 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o0MC9BTi050626; Fri, 22 Jan 2010 23:09:11 +1100 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <201001221209.o0MC9BTi050626@drugs.dv.isc.org>
To: Olaf Kolkman 
From: Mark Andrews 
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>  <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> 
In-reply-to: Your message of "Fri, 22 Jan 2010 12:04:07 BST." <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> 
Date: Fri, 22 Jan 2010 23:09:11 +1100
Sender: marka@isc.org
Cc: dnsop WG 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 12:09:24 -0000

Additionally NSEC3 provides no real benefit is highly structured zones
like IP6.ARPA.  It is relatively easy to enumerate a IP6.ARPA zone even
if it is using NSEC3 by making use of the zone's structure.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From ajs@shinkuro.com  Fri Jan 22 04:45:55 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28083A68E1 for ; Fri, 22 Jan 2010 04:45:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.665
X-Spam-Level: 
X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, US_DOLLARS_3=0.63]
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 kiNpoYmaNCXM for ; Fri, 22 Jan 2010 04:45:55 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 01EB23A6804 for ; Fri, 22 Jan 2010 04:45:54 -0800 (PST)
Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4E9602FE8CA1 for ; Fri, 22 Jan 2010 12:45:48 +0000 (UTC)
Date: Fri, 22 Jan 2010 07:45:45 -0500
From: Andrew Sullivan 
To: dnsop@ietf.org
Message-ID: <20100122124539.GB84189@shinkuro.com>
References: <20100121202745.GZ81286@shinkuro.com>   <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org>    <645C47F3-91A7-4874-B0DD-402F1A7AE307@rfc1035.com>  <503DA9EF-A56F-4069-8C79-ED09F30FFD69@rfc1035.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <503DA9EF-A56F-4069-8C79-ED09F30FFD69@rfc1035.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [DNSOP] key rollover for real
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 12:45:56 -0000

On Fri, Jan 22, 2010 at 12:57:13AM +0000, Jim Reid wrote:
> invoked from time to time in the live environment. And not just for 
> drills.

That sounds rather like a claim that we need to go around and set
buildings on fire from time to time (or have levees break, or cause 7+
Richter-scale earthquakes, or pick your analogy) in order to make sure
that the procedures are in place.

It is simply not true that everything needs to be done "for real" in
order to be sure it can be done.  I don't think we should have live
nuclear-weapon ICBM tests just to see whether the reaction procedures
of the local elementary school are up to snuff.  As I've now said
several times, the risk of some activities is greater than the reward
from seeing how well your operation of that activity follows the
plans.

The question here is how great the risk of key rolling is: is it more
like live ICBM tests, or is it more like changing your underwear (the
procedures for which I'm sure we all hope everyone keeps in good
nick)?  I claim the answer to that question is, "It depends," and we
need to give people advice on how to decide where on the
nuclear-war/underpants scale they lie.  I think EKR and Paul have
suggested ways to say that.  I enclose below some additional
long-winded text in case any of it can be useful.

    Keys in use do not become weaker with continued use, and there are
    not strong arguments from a cryptographic point of view that keys
    need to be rolled frequently or even with any regularity.  

    Given the state of the cryptographic art as of this writing, the
    chances of a key (selected in accordance with the recommendations
    in this Section 3) being broken by cryptanalysis is exceeding low.
    It is important to evaluate continuously that risk.  When making
    an evaluation, it is important to remember that the main question
    is one of cost versus value: 

        1.  What will it cost an attacker to crack the key?

        2.  What will the benefit to the attacker be (i.e. what is the
    value of the key)?

        3.  How long can the attacker realistically expect to gain
    from the attack?

    To take a deliberately bad example, if it costs $1,000,000 to
    crack the key once a month, and the attacker can only actually use
    the compromised key one time before being detected, then the value
    of that single use needs to be at least $1,000,000 (however one
    calculates that value) to make the attack worth performing.

    Each key rollover comes with some risks and rewards.  Every key
    rollover runs a small risk that the new key will not be available
    somewhere in time for the old key to be removed, if only because
    of the possibility that a validator has misconfigured the old key
    as a preferred trust anchor.  Errors in the key rollover
    procedures or their execution can also lead to the new key not
    being available in time.  If some validating resolver attempts to
    use the old key, and cannot (or will not, by configuration) use
    the new key after the rollover has completed, then that validator
    will treat the zone as bogus.

    Sites that have well-automated and carefully-tested key rollover
    procedures, particularly if the site is well-monitored from
    diverse networks, are somewhat less likely to face long-term
    outages due to key rollover problems; at the same time, such
    high-value zones are more likely to suffer embarrassment from a
    botched key rollover.  By similar reasoning, a small site for
    which DNSSEC is at most a part-time occupation for one staff
    member might run great risk of outage during a key rollover, just
    because the testing and detection of DNS issues may not be as
    complete as at a larger site.  Most sites will fall in a continuum
    between these extremes.  Determining policy around key rollover --
    whether to do it, how frequently if so, and whether regularly if
    so -- is a matter of operational policy that needs to be
    established for each site, taking into account the considerations
    above.

Someone might be able to edit that into something less wordy and more useful.

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

From olaf@NLnetLabs.nl  Fri Jan 22 04:54:16 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AFFD3A698E for ; Fri, 22 Jan 2010 04:54:16 -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.050, BAYES_00=-2.599, 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 WpV1VZZigtTP for ; Fri, 22 Jan 2010 04:54:15 -0800 (PST)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id CDD9A3A6804 for ; Fri, 22 Jan 2010 04:54:14 -0800 (PST)
Received: from [IPv6:2001:7b8:206:1:226:bbff:fe0e:7cc7] ([IPv6:2001:7b8:206:1:226:bbff:fe0e:7cc7]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0MCs4eI059260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Jan 2010 13:54:04 +0100 (CET) (envelope-from olaf@NLnetLabs.nl)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Olaf Kolkman 
In-Reply-To: <201001221209.o0MC9BTi050626@drugs.dv.isc.org>
Date: Fri, 22 Jan 2010 13:54:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <73CA2B67-5CE6-463A-827B-C7007137C909@NLnetLabs.nl>
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>  <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> <201001221209.o0MC9BTi050626@drugs.dv.isc.org>
To: Mark Andrews 
X-Mailer: Apple Mail (2.1077)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 22 Jan 2010 13:54:04 +0100 (CET)
Cc: dnsop WG 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 12:54:16 -0000

On Jan 22, 2010, at 1:09 PM, Mark Andrews wrote:

>=20
> Additionally NSEC3 provides no real benefit is highly structured zones
> like IP6.ARPA.  It is relatively easy to enumerate a IP6.ARPA zone =
even
> if it is using NSEC3 by making use of the zone's structure.



ACK good point. Maybe we need a little more descriptive about the =
methodology how the structure can be explored.


--Olaf
________________________________________________________=20

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140,=20
http://www.nlnetlabs.nl/               1098 XG Amsterdam


From tglassey@earthlink.net  Fri Jan 22 06:51:49 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E588D3A698C for ; Fri, 22 Jan 2010 06:51:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.228
X-Spam-Level: 
X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.370,  BAYES_00=-2.599, 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 ylhV5yl6ozFf for ; Fri, 22 Jan 2010 06:51:48 -0800 (PST)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 86C3A3A68DB for ; Fri, 22 Jan 2010 06:51:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=k4z1ZOiZcJ6KNH8s4a45B63YiYALtrrr7XdLGsIf2nCBuagivQlsbKAqubmq0Wzx; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.149] (helo=[192.168.1.100]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NYKrQ-00007G-5A for dnsop@ietf.org; Fri, 22 Jan 2010 09:51:44 -0500
Message-ID: <4B59BB7F.3040700@earthlink.net>
Date: Fri, 22 Jan 2010 06:51:43 -0800
From: Todd Glassey 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: dnsop@ietf.org
References: 									 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050403040902090705070201"
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec793f955fb5b10973f8c059defc177c23ca350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.149
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 14:51:50 -0000

This is a multi-part message in MIME format.
--------------050403040902090705070201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 1/21/2010 9:24 PM, Eric Rescorla wrote:
> On Thu, Jan 21, 2010 at 9:09 PM, Paul Wouters  wrote:
>    
>> On Thu, 21 Jan 2010, Eric Rescorla wrote:
>>
>>      
>>>>> The point is that the numbers depend on your model of the attacker
>>>>> more than on the cryptography.
>>>>>            
>>      
>>> Yes, but my point is that the safety period depends on your assumptions
>>> about the attacker's resources, which is why this is not really a
>>> technical
>>> issue.
>>>        
>> It is also based on the presumed technological advances of attackers. If
>> you talk to a cryptographer about a 1024 bit RSA key, they will tell you
>> "don't use that anymore". When you tell them "well, it is very useful
>> to us to reduce packet size in DNS" they tell you "go use ECC".
>>
>> We made a technological trade of. Though extremely conservative, all the
>> cryptographers (or really cryptanalysts) I talked to are more conservative
>> then we have been. Whether you call this technical or philosophical, does
>> not really change the issue. The model of the attacker is a fundamental
>> part of the cryptography.
>>      
> I really have no idea what you're talking about here. There is widespread
> agreement about the technical difficulty of attacking RSA. The question
> of how that impacts your behaviors has primarily an economic question,
> not a cryptographic one.
>
> With that said, cryptographers actually don't tend to think particularly deeply
> about the attack model;
Understatement
>   rather they assume a certain fairly idealized model
> of attacker capabilities and try to demonstrate that their systems have
> certain properties under those models. This is fundamentally different
> from the kind of thinking required here.
>    
Or how their crypto-algorithm works in production for that matter. The 
use model issue is why there is so much bad crytography out there IMHO

Todd Glassey
> -Ekr
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.432 / Virus Database: 271.1.1/2637 - Release Date: 01/21/10 19:34:00
>
>    


--------------050403040902090705070201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  


On 1/21/2010 9:24 PM, Eric Rescorla wrote:


  
On Thu, Jan 21, 2010 at 9:09 PM, Paul Wouters <paul@xelerance.com> wrote:
  

  

    
On Thu, 21 Jan 2010, Eric Rescorla wrote:

    

    

      

        

          
The point is that the numbers depend on your model of the attacker
more than on the cryptography.
          

        

      

    

    
    

    

      
Yes, but my point is that the safety period depends on your assumptions
about the attacker's resources, which is why this is not really a
technical
issue.
      

    

    
It is also based on the presumed technological advances of attackers. If
you talk to a cryptographer about a 1024 bit RSA key, they will tell you
"don't use that anymore". When you tell them "well, it is very useful
to us to reduce packet size in DNS" they tell you "go use ECC".

We made a technological trade of. Though extremely conservative, all the
cryptographers (or really cryptanalysts) I talked to are more conservative
then we have been. Whether you call this technical or philosophical, does
not really change the issue. The model of the attacker is a fundamental
part of the cryptography.
    

  

  
I really have no idea what you're talking about here. There is widespread
agreement about the technical difficulty of attacking RSA. The question
of how that impacts your behaviors has primarily an economic question,
not a cryptographic one.

With that said, cryptographers actually don't tend to think particularly deeply
about the attack model;



Understatement



  
 rather they assume a certain fairly idealized model
of attacker capabilities and try to demonstrate that their systems have
certain properties under those models. This is fundamentally different
from the kind of thinking required here.
  



Or how their crypto-algorithm works in production for that matter. The
use model issue is why there is so much bad crytography out there IMHO



Todd Glassey


  
-Ekr
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

  


No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.432 / Virus Database: 271.1.1/2637 - Release Date: 01/21/10 19:34:00

  








--------------050403040902090705070201--

From fanf2@hermes.cam.ac.uk  Fri Jan 22 08:57:05 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037033A6950 for ; Fri, 22 Jan 2010 08:57:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.549
X-Spam-Level: 
X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050,  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 Rv-FJegansB6 for ; Fri, 22 Jan 2010 08:57:04 -0800 (PST)
Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by core3.amsl.com (Postfix) with ESMTP id F118B3A6807 for ; Fri, 22 Jan 2010 08:57:03 -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]:53047) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1NYMoa-0005H5-KR (Exim 4.70) (return-path ); Fri, 22 Jan 2010 16:56:56 +0000
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1NYMoa-0004Og-AB (Exim 4.67) (return-path ); Fri, 22 Jan 2010 16:56:56 +0000
Date: Fri, 22 Jan 2010 16:56:56 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Paul Hoffman 
In-Reply-To: 
Message-ID: 
References:        <20100121202745.GZ81286@shinkuro.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: Andrew Sullivan , dnsop@ietf.org
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 16:57:05 -0000

On Thu, 21 Jan 2010, Paul Hoffman wrote:
>
> - Regular rolling can give you a false sense of security about your rolling process

How can you have any sense of security about your rolling process if you
don't exercise it?

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

From paul.hoffman@vpnc.org  Fri Jan 22 09:14:53 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D1C28C125 for ; Fri, 22 Jan 2010 09:14:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.022
X-Spam-Level: 
X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 KxK-n9DeYeAl for ; Fri, 22 Jan 2010 09:14:52 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 597D428C124 for ; Fri, 22 Jan 2010 09:14:52 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0MHDNE6057887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 10:13:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:        <20100121202745.GZ81286@shinkuro.com>  
Date: Fri, 22 Jan 2010 09:13:22 -0800
To: Tony Finch 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: Andrew Sullivan , dnsop@ietf.org
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 17:14:53 -0000

At 4:56 PM +0000 1/22/10, Tony Finch wrote:
>On Thu, 21 Jan 2010, Paul Hoffman wrote:
>>
>> - Regular rolling can give you a false sense of security about your rolling process
>
>How can you have any sense of security about your rolling process if you
>don't exercise it?

Why do people think the opposite of "regular" is "never"?

--Paul Hoffman, Director
--VPN Consortium

From jabley@hopcount.ca  Fri Jan 22 09:52:14 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081233A688F for ; Fri, 22 Jan 2010 09:52:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.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 B1Ik66EiovRe for ; Fri, 22 Jan 2010 09:52:13 -0800 (PST)
Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 2A90A3A6870 for ; Fri, 22 Jan 2010 09:52:13 -0800 (PST)
Received: from [199.212.90.17] (helo=dh17.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYNfy-0008UP-Fi; Fri, 22 Jan 2010 17:52:07 +0000
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Joe Abley 
In-Reply-To: <20100122124539.GB84189@shinkuro.com>
Date: Fri, 22 Jan 2010 12:52:05 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20100121202745.GZ81286@shinkuro.com>   <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org>    <645C47F3-91A7-4874-B0DD-402F1A7AE307@rfc1035.com>  <503DA9EF-A56F-4069-8C79-ED09F30FFD69@rfc1035.com> <20100122124539.GB84189@shinkuro.com>
To: Andrew Sullivan 
X-Mailer: Apple Mail (2.1077)
X-SA-Exim-Connect-IP: 199.212.90.17
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
Subject: Re: [DNSOP] key rollover for real
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 17:52:14 -0000

On 2010-01-22, at 07:45, Andrew Sullivan wrote:

> It is simply not true that everything needs to be done "for real" in
> order to be sure it can be done.

I think that's true. However, for procedures (manual or automated) that =
are required to function seamlessly and transparently in production, =
with no impact to service, I am generally in favour of exercising them =
regularly in production.

Additionally, with the case of key rolls, there are two sides to the =
exercise -- you need to be sure that you can do them seamlessly on the =
server side, and you also need to be sure that the client side can =
accommodate the change. The only way I can think of doing that in any =
real way is to roll your keys in production. You don't know your client =
base well enough on the Internet to be able to have them test against a =
lab (or test at all).

I don't think it matters whether the key roll schedule is perfectly =
periodic (e.g. every interval T) or event-driven (e.g. every time =
someone joins or leaves the operations team) but in general I am not =
comfortable relying on important machinery to work when you need it if =
it's not exercised.

If you need an analogy, I think generator testing is a better one than =
launching ICBMs at schools. You hope never to need your generator, but =
you test it regularly anyway just in case.


Joe


From Ed.Lewis@neustar.biz  Fri Jan 22 09:56:59 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F6D3A688F for ; Fri, 22 Jan 2010 09:56:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.902
X-Spam-Level: 
X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=-0.303, 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 Z18vxbL2l1ME for ; Fri, 22 Jan 2010 09:56:58 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 71ADD3A6807 for ; Fri, 22 Jan 2010 09:56:57 -0800 (PST)
Received: from [10.31.200.180] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0MHupbj020032; Fri, 22 Jan 2010 12:56:52 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <20100121222020.GD81286@shinkuro.com>
References:      <20100121202745.GZ81286@shinkuro.com>   <20100121212937.GB81286@shinkuro.com> <455DA067-4681-4570-9E0B-0B159A0FC1E4@virtualized.org> <20100121222020.GD81286@shinkuro.com>
Date: Fri, 22 Jan 2010 12:50:36 -0500
To: dnsop@ietf.org
From: Edward Lewis 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Cc: ed.lewis@neustar.biz
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 17:56:59 -0000

At 17:11 -0500 1/21/10, Roy Arends wrote:

>I'd recommend that 'exercise the activity' is not done on critical
>production systems.

There's a difference between "exercise" and test/training/etc.  You 
do want to "exercise" on the real systems.

At 17:20 -0500 1/21/10, Andrew Sullivan wrote:

>You have worked in more enlightened organizations than I, then.

Not trying to be funny, but there are a number of times in the thread 
that I thought to myself "geez, we all have 'different' operational 
situations."

Every organization is more enlightened than the others in some way 
and vice versa.

I am not saying this to stoke any commercial rivalries but as a 
comment that the draft document reflect that there are a wide array 
of operational practices and situations.  Not everyone out-sources, 
not everyone has high turnover.  And so on.

At 9:13 -0800 1/22/10, Paul Hoffman wrote:

>Why do people think the opposite of "regular" is "never"?

Because that's the way it is. ;)

"cron does not play dice with the universe."

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

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

From alex@alex.org.uk  Fri Jan 22 10:04:20 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3CD3A6A76 for ; Fri, 22 Jan 2010 10:04:20 -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 X5L3ahGyMyhk for ; Fri, 22 Jan 2010 10:04:19 -0800 (PST)
Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 291233A688F for ; Fri, 22 Jan 2010 10:04:18 -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 5031DC56269; Fri, 22 Jan 2010 18:04:13 +0000 (GMT)
Date: Fri, 22 Jan 2010 18:04:12 +0000
From: Alex Bligh 
To: Olaf Kolkman , dnsop WG 
Message-ID: <24C8A8E2A81760E31D4CDE4A@Ximines.local>
In-Reply-To: <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl>
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>  <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Alex Bligh 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Alex Bligh 
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 18:04:20 -0000

--On 22 January 2010 12:04:07 +0100 Olaf Kolkman  wrote:

Strawman text said:
> Though some claim all data in the DNS should be considered public, it
> sometimes is considered to be more then private, but less then public
> data.

That does not describe the problem well, in that (1) it is not
the data that is somewhere between public and private, it is
that the mechanisms of access to that data that change, and (2) it
completely ignores opt-out. How about

	Though all agree DNS data should be accessible through query
	mechanisms, a side effect of NSEC is that it allows the contents of
	a zone file to be enumerate in full by sequential query. Whilst for
	some operators this behaviour is acceptable or even desirable, for
	others it is undesirable for policy, regulatory or other reasons.
	This is the first reason for development of NSEC3.
	
	The second reason for the existence of NSEC3 is that NSEC requires
	a signature over every RR in the zonefile, thereby ensuring that
	any denial of existence is cryptographically signed. However, in a
	large zonefile containing many delegations very few of which are to
	signed zones, this may produce unacceptable additional overhead
	especially where insecure delegations are subject to frequent
	update (a typical example might be a TLD operator with few
	registrants using secure delegations). NSEC3 allows intervals
	between two such delegations to "Opt-out" in which case they may
	contain one more more insecure delegations, thus reducing the size
	and cryptographic complexity of the zone.

> 5.3.4 Opt-out
>
> An Opt-Out NSEC3 RR does not assert the existence or non-existence of the
> insecure delegations that it may cover. This allows for the addition or
> removal of these delegations without recalculating or re- signing RRs in
> the NSEC3 RR chain. Therefor, Opt-Out should be avoided if possible.

1. Therefor*e*

2. I don't think the last sentence follows from the foregoing, in that
   this behaviour is desirable for the zone operator! (I know what
   you mean).

3. Aside from that, I don't think an injunction to avoid Opt-Out in
   these terms is sensible in a delegation only zone. In such a zone,
   I don't really see the additional security risk from opt out across
   insecure delegations, given if a spoof can be done, it can be
   done at the delegated zone level. There are considerable operational
   advantages in Opt Out (zone size, cryptographic complexity etc.)
   for large zones only sparsely populated with secure delegations,
   particularly where few queries have DO set anyway.

-- 
Alex Bligh

From alex@alex.org.uk  Fri Jan 22 10:05:06 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A993A6A76 for ; Fri, 22 Jan 2010 10:05:05 -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 kKROWwX5hPKT for ; Fri, 22 Jan 2010 10:05:05 -0800 (PST)
Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id E934F3A6A8C for ; Fri, 22 Jan 2010 10:05:04 -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 C6305C563AE; Fri, 22 Jan 2010 18:04:59 +0000 (GMT)
Date: Fri, 22 Jan 2010 18:04:58 +0000
From: Alex Bligh 
To: Mark Andrews , Olaf Kolkman 
Message-ID: <5F4116ACFDDCBEB4137C4AC0@Ximines.local>
In-Reply-To: <201001221209.o0MC9BTi050626@drugs.dv.isc.org>
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>  <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl>  <201001221209.o0MC9BTi050626@drugs.dv.isc.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: dnsop WG , Alex Bligh 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Alex Bligh 
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 18:05:06 -0000

--On 22 January 2010 23:09:11 +1100 Mark Andrews  wrote:

> Additionally NSEC3 provides no real benefit is highly structured zones
> like IP6.ARPA.  It is relatively easy to enumerate a IP6.ARPA zone even
> if it is using NSEC3 by making use of the zone's structure.

e164.arpa. is probably the poster child for this.

-- 
Alex Bligh

From alex@alex.org.uk  Fri Jan 22 10:05:53 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04A928C0EE for ; Fri, 22 Jan 2010 10:05:53 -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 YopQYCalKrzT for ; Fri, 22 Jan 2010 10:05:53 -0800 (PST)
Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id CBDBF3A6961 for ; Fri, 22 Jan 2010 10:05:52 -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 79414C56454; Fri, 22 Jan 2010 18:05:47 +0000 (GMT)
Date: Fri, 22 Jan 2010 18:05:46 +0000
From: Alex Bligh 
To: Paul Hoffman , Tony Finch 
Message-ID: <1C34A57EB724F3A68C4B5F6B@Ximines.local>
In-Reply-To: 
References:     	  <20100121202745.GZ81286@shinkuro.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: Andrew Sullivan , dnsop@ietf.org, Alex Bligh 
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Alex Bligh 
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 18:05:53 -0000

--On 22 January 2010 09:13:22 -0800 Paul Hoffman  
wrote:

>>> - Regular rolling can give you a false sense of security about your
>>> rolling process
>>
>> How can you have any sense of security about your rolling process if you
>> don't exercise it?
>
> Why do people think the opposite of "regular" is "never"?

There seems to be some confusion of "regular" and "frequent" too.

-- 
Alex Bligh

From danny@tcb.net  Fri Jan 22 10:07:08 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CAEA3A6AA3 for ; Fri, 22 Jan 2010 10:07: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 B6bgGeQNHjxp for ; Fri, 22 Jan 2010 10:07:07 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id C6A293A6A9B for ; Fri, 22 Jan 2010 10:07:07 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id B9D412684EA; Fri, 22 Jan 2010 11:07:03 -0700 (MST)
Received: from [192.168.1.64] (173.5.109.249 [173.5.109.249]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for dnsop@ietf.org; Fri, 22 Jan 2010 11:07:03 -0700 (MST) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=173.5.109.249; client-port=58310; syn-fingerprint=65535:42:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0
From: Danny McPherson 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Fri, 22 Jan 2010 11:06:46 -0700
Message-Id: <2304E0BD-9D1B-4731-933B-F187FC72D529@tcb.net>
To: "dnsop@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1077)
X-Mailer: Apple Mail (2.1077)
Subject: [DNSOP] DNSSEC Operational Considerations
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 18:07:08 -0000

Does anyone have a decent reference to a document that outlines
what operators should be considering WRT DNSSEC (e.g., >512B 
thing, allowing TCP, EDNS0 considerations, validating recursors 
deployment, any studies to projections of recursive load hits 
for RAM, CPU and transactions in various implementations and 
platforms, other firewall policies, etc..)?

I'm writing something up and wanted to provide a summary, 
with some nice useful references that are actionable for your
average ISP operator.  Most of the stuff I've seen that 
already exists in a form easily consumable by network operators 
seems heavily root and TLD focused, and I'd like to say "here 
are some things you need to do to prepare for the root signing, 
even if you're not signing your own zones)...

Thanks in advance!

-danny

From tglassey@earthlink.net  Fri Jan 22 11:43:34 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C7F13A6A6F for ; Fri, 22 Jan 2010 11:43:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.321
X-Spam-Level: 
X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.277,  BAYES_00=-2.599, 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 l4oYXplJ4xHo for ; Fri, 22 Jan 2010 11:43:33 -0800 (PST)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 426C73A6846 for ; Fri, 22 Jan 2010 11:43:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VAUP2U+hEDBWtndtqHMQolxcc8FOY5dQYOuqviuct+9GrdD1mIR25T0aTSEJugz3; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.149] (helo=[192.168.1.168]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NYPPg-0003Cb-1M; Fri, 22 Jan 2010 14:43:24 -0500
Message-ID: <4B59FFDB.7090605@earthlink.net>
Date: Fri, 22 Jan 2010 11:43:23 -0800
From: Todd Glassey 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: Alex Bligh , dnsop WG 
References: 							<20100121202745.GZ81286@shinkuro.com>			 <1C34A57EB724F3A68C4B5F6B@Ximines.local>
In-Reply-To: <1C34A57EB724F3A68C4B5F6B@Ximines.local>
Content-Type: multipart/alternative; boundary="------------060807060001000302030807"
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79178c89aaf0c900640d2aa58d0c23a459350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.149
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 19:43:34 -0000

This is a multi-part message in MIME format.
--------------060807060001000302030807
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 1/22/2010 10:05 AM, Alex Bligh wrote:
>
>
> --On 22 January 2010 09:13:22 -0800 Paul Hoffman 
>  wrote:
>
>>>> - Regular rolling can give you a false sense of security about your
>>>> rolling process

You mean a periodic process to rotate the keys... OK what is the 
periodicity of this?
>>>
>>> How can you have any sense of security about your rolling process if 
>>> you
>>> don't exercise it?
>>
>> Why do people think the opposite of "regular" is "never"?
You mean why to techies think the opposite of regular is never...
>
> There seems to be some confusion of "regular" and "frequent" too.
Agreed - so again what is the periodicity of the key rolls.

Todd
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.432 / Virus Database: 271.1.1/2638 - Release Date: 01/22/10 07:34:00
>
>    


--------------060807060001000302030807
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


On 1/22/2010 10:05 AM, Alex Bligh wrote:



  

--On 22 January 2010 09:13:22 -0800 Paul Hoffman
<paul.hoffman@vpnc.org> wrote:
  

  

  

    

      
- Regular rolling can give you a false
sense of security about your
        

rolling process
        

      

    

  





You mean a periodic process to rotate the keys... OK what is the
periodicity of this?



  

    


How can you have any sense of security about your rolling process if
you
      

don't exercise it?
      

    

    

Why do people think the opposite of "regular" is "never"?
    

  



You mean why to techies think the opposite of regular is never... 




There seems to be some confusion of "regular" and "frequent" too.
  



Agreed - so again what is the periodicity of the key rolls.



Todd




  


No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.432 / Virus Database: 271.1.1/2638 - Release Date: 01/22/10 07:34:00

  








--------------060807060001000302030807--

From paul@xelerance.com  Fri Jan 22 11:44:00 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3B43A6AA3 for ; Fri, 22 Jan 2010 11:44:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.827
X-Spam-Level: 
X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.228, 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 KVIBeGeKIDuc for ; Fri, 22 Jan 2010 11:43:59 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 08D8A3A6A6F for ; Fri, 22 Jan 2010 11:43:59 -0800 (PST)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 0E3DE571B4; Fri, 22 Jan 2010 14:43:54 -0500 (EST)
Date: Fri, 22 Jan 2010 14:43:54 -0500 (EST)
From: Paul Wouters 
To: Danny McPherson 
In-Reply-To: <2304E0BD-9D1B-4731-933B-F187FC72D529@tcb.net>
Message-ID: 
References: <2304E0BD-9D1B-4731-933B-F187FC72D529@tcb.net>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "dnsop@ietf.org WG" 
Subject: Re: [DNSOP] DNSSEC Operational Considerations
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 19:44:00 -0000

On Fri, 22 Jan 2010, Danny McPherson wrote:

> Does anyone have a decent reference to a document that outlines
> what operators should be considering WRT DNSSEC (e.g., >512B
> thing, allowing TCP, EDNS0 considerations, validating recursors
> deployment, any studies to projections of recursive load hits
> for RAM, CPU and transactions in various implementations and
> platforms, other firewall policies, etc..)?

See http://www.nlnetlabs.nl/svn/rfc4641bis/trunk
and http://www-x.antd.nist.gov/dnssec/

Paul

From paul@xelerance.com  Fri Jan 22 11:51:44 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36623A6938 for ; Fri, 22 Jan 2010 11:51:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level: 
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[AWL=-0.196, 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 9E6bj6-Bjx8Y for ; Fri, 22 Jan 2010 11:51:43 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 73C313A6936 for ; Fri, 22 Jan 2010 11:51:43 -0800 (PST)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 11F11571B4; Fri, 22 Jan 2010 14:51:39 -0500 (EST)
Date: Fri, 22 Jan 2010 14:51:38 -0500 (EST)
From: Paul Wouters 
To: Alex Bligh 
In-Reply-To: <24C8A8E2A81760E31D4CDE4A@Ximines.local>
Message-ID: 
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>  <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> <24C8A8E2A81760E31D4CDE4A@Ximines.local>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: dnsop WG 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 19:51:44 -0000

On Fri, 22 Jan 2010, Alex Bligh wrote:

> completely ignores opt-out. How about
>
> 	Though all agree DNS data should be accessible through query
> 	mechanisms, a side effect of NSEC is that it allows the contents of
> 	a zone file to be enumerate in full by sequential query. Whilst for
> 	some operators this behaviour is acceptable or even desirable, for
> 	others it is undesirable for policy, regulatory or other reasons.
> 	This is the first reason for development of NSEC3.
>
> 	The second reason for the existence of NSEC3 is that NSEC requires
> 	a signature over every RR in the zonefile, thereby ensuring that
> 	any denial of existence is cryptographically signed. However, in a
> 	large zonefile containing many delegations very few of which are to
> 	signed zones, this may produce unacceptable additional overhead
> 	especially where insecure delegations are subject to frequent
> 	update (a typical example might be a TLD operator with few
> 	registrants using secure delegations). NSEC3 allows intervals
> 	between two such delegations to "Opt-out" in which case they may
> 	contain one more more insecure delegations, thus reducing the size
> 	and cryptographic complexity of the zone.

Sounds good.

>> the NSEC3 RR chain. Therefor, Opt-Out should be avoided if possible.
>
> 1. Therefor*e*
>
> 2. I don't think the last sentence follows from the foregoing, in that
>  this behaviour is desirable for the zone operator! (I know what
>  you mean).
>
> 3. Aside from that, I don't think an injunction to avoid Opt-Out in
>  these terms is sensible in a delegation only zone. In such a zone,
>  I don't really see the additional security risk from opt out across
>  insecure delegations, given if a spoof can be done, it can be
>  done at the delegated zone level.

If I secure example.org, and .org is signed, OPT-OUT might cause a spoofed
exemple.org to not be caught by the user's validating resolver. Therefor,
I do think opt-out should be avoided when possible.


>  There are considerable operational
>  advantages in Opt Out (zone size, cryptographic complexity etc.)

I understand zone size, though I don't understand "cryptographic complexity".
Having different "security values" attached to data within the same zone seems
more complex to me, not less complex?

>  for large zones only sparsely populated with secure delegations,
>  particularly where few queries have DO set anyway.

I'd like to avoid circular adoption loop arguments :)

Paul

From alex@alex.org.uk  Fri Jan 22 12:31:20 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFFE23A6944 for ; Fri, 22 Jan 2010 12:31:20 -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 9qgQ46bIvi5d for ; Fri, 22 Jan 2010 12:31:19 -0800 (PST)
Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 329603A6837 for ; Fri, 22 Jan 2010 12:31:18 -0800 (PST)
Received: from [192.168.100.124] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 91018C563AD; Fri, 22 Jan 2010 20:31:13 +0000 (GMT)
Date: Fri, 22 Jan 2010 20:31:12 +0000
From: Alex Bligh 
To: Paul Wouters 
Message-ID: 
In-Reply-To: 
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>  <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> <24C8A8E2A81760E31D4CDE4A@Ximines.local> 
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: dnsop WG , Alex Bligh 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Alex Bligh 
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 20:31:20 -0000

Paul,

--On 22 January 2010 14:51:38 -0500 Paul Wouters  wrote:

>>> the NSEC3 RR chain. Therefor, Opt-Out should be avoided if possible.
>>
>> 1. Therefor*e*
>>
>> 2. I don't think the last sentence follows from the foregoing, in that
>>  this behaviour is desirable for the zone operator! (I know what
>>  you mean).
>>
>> 3. Aside from that, I don't think an injunction to avoid Opt-Out in
>>  these terms is sensible in a delegation only zone. In such a zone,
>>  I don't really see the additional security risk from opt out across
>>  insecure delegations, given if a spoof can be done, it can be
>>  done at the delegated zone level.
>
> If I secure example.org, and .org is signed, OPT-OUT might cause a spoofed
> exemple.org to not be caught by the user's validating resolver. Therefor,
> I do think opt-out should be avoided when possible.

If I run .org, which is signed, but example.org is NOT signed (i.e.
is an unsigned delegation), there seems to be little reason to avoid opt out
across it. Whilst it might be harder to spoof the absence or existence
of the delegation, I can still spoof the contents (or absence of
contents) in example.org. So, whilst opt-out should be avoided
across intervals containing secure delegations, I see no reason
to avoid it across intervals that don't contain secure delegations.

>>  There are considerable operational
>>  advantages in Opt Out (zone size, cryptographic complexity etc.)
>
> I understand zone size, though I don't understand "cryptographic
> complexity".
> Having different "security values" attached to data within the same zone
> seems
> more complex to me, not less complex?

I meant computational resource requirements resultant from crypto
operations, not algorithmic complexity.

The owner names in NSEC3 RRs are cryptographic hashes of the original owner
name. Assume you have a delegation only zone consisting of sparse secure
delegations amongst many insecure delegations. If you are using NSEC3 at
all, using opt-out substantially reduces the number of NSEC3 records (since
many insecure delegations will cluster together within the opt-out
interval) and thus the length of the NSEC3 chain, and hence reduce the
number of cryptographic hash calculations. Similarly the zone itself is
smaller, so less work to sign. The situation is exacerbated where the
insecure delegations are volatile.


It might be worth mentioning (but is perhaps blindingly obvious) that
NSEC3 is substantially more complex in terms of implementation than
NSEC. Whilst one can by visual inspection spot the odd problem with
a small zone's NSEC chain, it's far harder with NSEC3. Obviously, if
a tool chain is used to NSECify and sign the zone, that's a problem
for the implementor rather than the operator.

-- 
Alex Bligh

From Ed.Lewis@neustar.biz  Fri Jan 22 12:46:09 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE0F3A67AA for ; Fri, 22 Jan 2010 12:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.846
X-Spam-Level: 
X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, 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 JXdRM7VkS3cO for ; Fri, 22 Jan 2010 12:46:08 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E31EA3A67A5 for ; Fri, 22 Jan 2010 12:46:07 -0800 (PST)
Received: from [10.31.200.180] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0MKjvHv021388; Fri, 22 Jan 2010 15:45:58 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>  <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> <24C8A8E2A81760E31D4CDE4A@Ximines.local>  
Date: Fri, 22 Jan 2010 15:45:54 -0500
To: Alex Bligh 
From: Edward Lewis 
Content-Type: multipart/alternative; boundary="============_-947929338==_ma============"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Cc: dnsop WG , Alex Bligh 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 20:46:09 -0000

--============_-947929338==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 20:31 +0000 1/22/10, Alex Bligh wrote:


>contents) in example.org. So, whilst opt-out should be avoided
>across intervals containing secure delegations, I see no reason
>to avoid it across intervals that don't contain secure delegations.

Opt-out is restricted to "intervals" that contain only unsecured delegations.

RFC 5155:
6.  Opt-Out
... (first paragraph's last sentence):
    name of the delegation.  Setting the Opt-Out flag modifies this by
    allowing insecure delegations to exist within the signed zone without
    a corresponding NSEC3 RR at the hashed owner name of the delegation.

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

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
--============_-947929338==_ma============
Content-Type: text/html; charset="us-ascii"


Re: [DNSOP] rfc4641bis: NSEC vs
NSEC3.

At 20:31 +0000 1/22/10, Alex Bligh wrote:








>contents) in example.org. So, whilst opt-out should be
avoided

>across intervals containing secure delegations, I see no
reason

>to avoid it across intervals that don't contain secure
delegations.




Opt-out is restricted to "intervals" that contain only
unsecured delegations.





RFC 5155:


6.  Opt-Out


... (first paragraph's last sentence):


   name of the delegation.  Setting the Opt-Out
flag modifies this by

   allowing insecure delegations to exist within the signed
zone without


   a corresponding NSEC3 RR at the hashed owner name of
the delegation.





-- 



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


Edward
Lewis             

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





As with IPv6, the problem with the deployment of frictionless
surfaces is


that they're not getting traction.



--============_-947929338==_ma============--

From alex@alex.org.uk  Fri Jan 22 12:54:27 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A213A6867 for ; Fri, 22 Jan 2010 12:54:27 -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 I3n6c3nzpMV1 for ; Fri, 22 Jan 2010 12:54:26 -0800 (PST)
Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 585523A67A5 for ; Fri, 22 Jan 2010 12:54:26 -0800 (PST)
Received: from [192.168.100.124] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id CA565C563AD; Fri, 22 Jan 2010 20:54:20 +0000 (GMT)
Date: Fri, 22 Jan 2010 20:54:20 +0000
From: Alex Bligh 
To: Edward Lewis 
Message-ID: <13EEA44D7ADF3D8C09360D49@nimrod.local>
In-Reply-To: 
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>  <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> <24C8A8E2A81760E31D4CDE4A@Ximines.local>   
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: dnsop WG , Alex Bligh 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Alex Bligh 
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 20:54:27 -0000

--On 22 January 2010 15:45:54 -0500 Edward Lewis  
wrote:

>> contents) in example.org. So, whilst opt-out should be avoided
>> across intervals containing secure delegations, I see no reason
>> to avoid it across intervals that don't contain secure delegations.
>
> Opt-out is restricted to "intervals" that contain only unsecured
> delegations.

Doh! Yes indeed. In which case I stand by my original argument: I can't
see how opt-out really increase spoofability. It can't affect
a secure delegation, and the contents of an insecure delegation
or denial thereof (if not the delegation itself) are spoofable
with or without opt-out. Paul's example of a secure delegation
with opt-out across it can't exist.

-- 
Alex Bligh

From paul.hoffman@vpnc.org  Fri Jan 22 13:01:06 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2C93A67AA for ; Fri, 22 Jan 2010 13:01:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.022
X-Spam-Level: 
X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 7ZrlMrIY9EF9 for ; Fri, 22 Jan 2010 13:01:05 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 7D1BB3A6778 for ; Fri, 22 Jan 2010 13:01:05 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0MKZIg9072405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 13:35:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <20100122201803.GA24117@vacation.karoshi.com.>
References:       <20100121202745.GZ81286@shinkuro.com>    <20100122201803.GA24117@vacation.karoshi.com.>
Date: Fri, 22 Jan 2010 12:35:17 -0800
To: bmanning@vacation.karoshi.com
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: Tony Finch , Andrew Sullivan , dnsop@ietf.org
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 21:01:06 -0000

At 8:18 PM +0000 1/22/10, bmanning@vacation.karoshi.com wrote:
>On Fri, Jan 22, 2010 at 09:13:22AM -0800, Paul Hoffman wrote:
>> At 4:56 PM +0000 1/22/10, Tony Finch wrote:
>> >On Thu, 21 Jan 2010, Paul Hoffman wrote:
>> >>
>> >> - Regular rolling can give you a false sense of security about your rolling process
>> >
>> >How can you have any sense of security about your rolling process if you
>> >don't exercise it?
>>
>> Why do people think the opposite of "regular" is "never"?
>>
>> --Paul Hoffman, Director
>
>	
>	to borrow from Andrew - let me posit an analogy...
>
>	would you rather have your LASIX or LIOP  surgery done
>	by someone who has done 12,000 such procedures and
>	does a couple a week or someone who has done a dozen
>	and does them about every couple years or so?
>
>	sure, the doctor who does them all the time -might- get
>	sloppy and cut corners  --  but is that worse than someone
>	who has only passing understanding of what they are actually
>	doing?
>
>	the risk isn't -never-, the risk is lack of experience.

Why do people think this is about "the risk" instead of "the risks"?

--Paul Hoffman, Director
--VPN Consortium

From paul@xelerance.com  Fri Jan 22 16:01:44 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6323A681F for ; Fri, 22 Jan 2010 16:01:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.77
X-Spam-Level: 
X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=-0.171,  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 hJIHLniOUbgx for ; Fri, 22 Jan 2010 16:01:43 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 8CF803A659B for ; Fri, 22 Jan 2010 16:01:43 -0800 (PST)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 7352B571B4; Fri, 22 Jan 2010 19:01:38 -0500 (EST)
Date: Fri, 22 Jan 2010 19:01:38 -0500 (EST)
From: Paul Wouters 
To: Alex Bligh 
In-Reply-To: 
Message-ID: 
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>  <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> <24C8A8E2A81760E31D4CDE4A@Ximines.local>  
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: dnsop WG 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 00:01:44 -0000

On Fri, 22 Jan 2010, Alex Bligh wrote:

>> If I secure example.org, and .org is signed, OPT-OUT might cause a spoofed
>> exemple.org to not be caught by the user's validating resolver. Therefor,
>> I do think opt-out should be avoided when possible.
>
> If I run .org, which is signed, but example.org is NOT signed (i.e.

I was talking about the situation where example.org is signed, the .org
is optout and exemple.org does not exist. For many, it is impossible
to register all typo-squat domains, so this is a real scenario.

> is an unsigned delegation), there seems to be little reason to avoid opt out
> across it.

Having verifiable deniability for typo-squated domaims is very useful.

> I meant computational resource requirements resultant from crypto
> operations, not algorithmic complexity.

I had no problems doing this on a 1.2M domains TLD zone, using off the
shelf hardware, integrating into the TLD's hourly update interval.
(http://www.cira.ca/dnssec/)

The only issues encountered were indeed the increased memory usage
on the nameservers, but those can still run fine on commodity hardware.
Though I recommend 64bit to avoid and 3G or 4G memory allocation per 
process issues.

> It might be worth mentioning (but is perhaps blindingly obvious) that
> NSEC3 is substantially more complex in terms of implementation than
> NSEC. Whilst one can by visual inspection spot the odd problem with
> a small zone's NSEC chain, it's far harder with NSEC3. Obviously, if
> a tool chain is used to NSECify and sign the zone, that's a problem
> for the implementor rather than the operator.

Commercial and free tools are readilly available.

Paul

From ajs@shinkuro.com  Fri Jan 22 16:17:22 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD0328B797 for ; Fri, 22 Jan 2010 16:17:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.823
X-Spam-Level: 
X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.157,  BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
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 sHhzYV3AWnH8 for ; Fri, 22 Jan 2010 16:17:21 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 5C64D3A659B for ; Fri, 22 Jan 2010 16:17:21 -0800 (PST)
Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 946532FE8CA1 for ; Sat, 23 Jan 2010 00:17:12 +0000 (UTC)
Date: Fri, 22 Jan 2010 19:17:09 -0500
From: Andrew Sullivan 
To: dnsop@ietf.org
Message-ID: <20100123001706.GB85026@shinkuro.com>
References:  <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org>    <645C47F3-91A7-4874-B0DD-402F1A7AE307@rfc1035.com>  <503DA9EF-A56F-4069-8C79-ED09F30FFD69@rfc1035.com> <20100122124539.GB84189@shinkuro.com> <20100122152302.GA22286@vacation.karoshi.com.>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100122152302.GA22286@vacation.karoshi.com.>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [DNSOP] key rollover for real
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 00:17:22 -0000

On Fri, Jan 22, 2010 at 03:23:02PM +0000, bmanning@vacation.karoshi.com wrote:

> 	the apparent nub of the argument is... we need to be
> 	able to do this rollover thing, but if we screw up
> 	it will be hard to put back together... so we won't
> 	actually do the task - and hope that we'll never	
> 	pull the trigger.

That's question-begging.  The exact question under dispute is whether
"we need to be able to do this rollover thing".  Maybe one needs to be
able to do it, and maybe not, and maybe the event itself is so rare in
some zones that treating every occasion as the 1st time is the right
approach.  That's exactly what's up for debate.  Some (I am among
them) claim that there's a risk/reward trade-off, and others seem to
start with the premise that it is a necessary event.  Only if you
accept the latter can you argue that it's the sort of operational
event that must be undertaken with any regularity, and even then I
think the argument is weak.

> 	DNS operators -have- to pay attention these days or 
> 	the system will stop working.  

This is true, but it's unrelated to key rolls.  It has to do with the
resigning period, which is a completely different issue.

On Fri, Jan 22, 2010 at 12:52:05PM -0500, Joe Abley wrote:

> I don't think it matters whether the key roll schedule is perfectly
> periodic (e.g. every interval T) or event-driven (e.g. every time
> someone joins or leaves the operations team) but in general I am not
> comfortable relying on important machinery to work when you need it
> if it's not exercised.

Ok, except that each exercise of this machinery is in fact a case of
"needing it", since you're going to do exactly the things you'd need
to do when you need it.  The problem with the key roll as "exercising
the machinery" is that it's a destructive test.  

> If you need an analogy, I think generator testing is a better one
> than launching ICBMs at schools. You hope never to need your
> generator, but you test it regularly anyway just in case.

Good analogy.  What you do here depends on your operation.  If you are
the sort of hugely-automated total 24x7 shop that needs to be able to
prove in a controlled fashion that your generators all work, come on
line, and take the load, then maybe (and only maybe) you turn the
whole thing on, flip everything over to generators, and so on from
time to time (in a controlled way) to prove that it all works.  But if
you have a tiny generator that is supposed to allow you to operate a
couple things in your house in case of a snowstorm, all you do is fire
it up and make sure it produces power.  Which sort of test you ought
to do is governed by what kind of needs you have.

Since I think I've sung that refrain to everyone's boredom, however,
I'll shut up about it now.  

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

From drc@virtualized.org  Fri Jan 22 18:07:24 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5478C3A6811 for ; Fri, 22 Jan 2010 18:07:24 -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 7i-OPZa8lCRQ for ; Fri, 22 Jan 2010 18:07:23 -0800 (PST)
Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 259A53A67A3 for ; Fri, 22 Jan 2010 18:07:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id F17E3A3E425; Fri, 22 Jan 2010 18:07:16 -0800 (PST)
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 HW2D9WhGBf1n; Fri, 22 Jan 2010 18:07:13 -0800 (PST)
Received: from [192.168.1.2] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 40C8BA3E410; Fri, 22 Jan 2010 18:07:13 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: David Conrad 
In-Reply-To: <20100123001706.GB85026@shinkuro.com>
Date: Fri, 22 Jan 2010 18:07:12 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org>    <645C47F3-91A7-4874-B0DD-402F1A7AE307@rfc1035.com>  <503DA9EF-A56F-4069-8C79-ED09F30FFD69@rfc1035.com> <20100122124539.GB84189@shinkuro.com> <20100122152302.GA22286@vacation.karoshi.com.> <20100123001706.GB85026@shinkuro.com>
To: Andrew Sullivan 
X-Mailer: Apple Mail (2.1077)
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] key rollover for real
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 02:07:24 -0000

Andrew,

> Which sort of test you ought to do is governed by what kind of needs =
you have.

I've been in places where folks really needed to rely on generators =
kicking in during a power outage.  When the generators turned out to be =
reasonably good at being pieces of industrial art because folks forgot =
to fill the diesel tank, there were many unhappy customers.  Oddly, a =
periodic test of the backup generators was soon instituted.

Pragmatically speaking, which sort of tests you do depend on how much =
you care.  If you're going to go to the trouble of signing your zone, it =
would seem to me it implies your level of care is high enough that you'd =
actually try to do things so they don't break when you need them.  If =
not, why bother signing?

> Since I think I've sung that refrain to everyone's boredom, however, =
I'll shut up about it now. =20

Yep, I've given up too.  Operationally, people will do what they think =
is appropriate regardless of what is written in an RFC.  In some version =
of an ideal world, folks who care about "doing the right thing" could =
point to an RFC and ask vendors if they implement that RFC (presuming =
the RFC describes doing the right thing).  I don't fully get why it =
makes sense to dumb down RFCs in this context, but I'm sure it's because =
I'm missing something.

Regards,
-drc


From alex@alex.org.uk  Fri Jan 22 20:56:44 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297713A67B7 for ; Fri, 22 Jan 2010 20:56:44 -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 X2l9cZbTeYop for ; Fri, 22 Jan 2010 20:56:43 -0800 (PST)
Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 11C5B3A63D3 for ; Fri, 22 Jan 2010 20:56:42 -0800 (PST)
Received: from [192.168.100.124] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id D97BAC563AD; Sat, 23 Jan 2010 04:56:32 +0000 (GMT)
Date: Sat, 23 Jan 2010 04:56:33 +0000
From: Alex Bligh 
To: Paul Wouters 
Message-ID: <185C280129C4C3502DAC0F80@nimrod.local>
In-Reply-To: 
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr>  <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>    <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl>  <24C8A8E2A81760E31D4CDE4A@Ximines.local>   
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: dnsop WG , Alex Bligh 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Alex Bligh 
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 04:56:44 -0000

Paul,

> I was talking about the situation where example.org is signed, the .org
> is optout and exemple.org does not exist. For many, it is impossible
> to register all typo-squat domains, so this is a real scenario.

Ah, didn't spot the 'e'.

> Having verifiable deniability for typo-squated domaims is very useful.

If expensive, where 99% of your domains are unsigned.

> I had no problems doing this on a 1.2M domains TLD zone, using off the
> shelf hardware, integrating into the TLD's hourly update interval.
> (http://www.cira.ca/dnssec/)
>
> The only issues encountered were indeed the increased memory usage
> on the nameservers, but those can still run fine on commodity hardware.
> Though I recommend 64bit to avoid and 3G or 4G memory allocation per
> process issues.

And on a 100M TLD zone that needs near real time updates? I don't
know whether zone growth predictions exceed Moore's law or vice
versa, to see whether this is a growing problem or not. I agree
that the computational complexity argument is a minority problem.

>> It might be worth mentioning (but is perhaps blindingly obvious) that
>> NSEC3 is substantially more complex in terms of implementation than
>> NSEC. Whilst one can by visual inspection spot the odd problem with
>> a small zone's NSEC chain, it's far harder with NSEC3. Obviously, if
>> a tool chain is used to NSECify and sign the zone, that's a problem
>> for the implementor rather than the operator.
>
> Commercial and free tools are readilly available.

Sure. Just rehearsing an argument I've heard others use against NSEC3.

-- 
Alex Bligh

From alex@alex.org.uk  Fri Jan 22 21:07:01 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19AC3A67F4 for ; Fri, 22 Jan 2010 21:07:00 -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 jA8L9HX-NgXs for ; Fri, 22 Jan 2010 21:07:00 -0800 (PST)
Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id F2CC63A63D3 for ; Fri, 22 Jan 2010 21:06:57 -0800 (PST)
Received: from [192.168.100.124] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 659EAC563AC; Sat, 23 Jan 2010 05:06:50 +0000 (GMT)
Date: Sat, 23 Jan 2010 05:06:50 +0000
From: Alex Bligh 
To: Alex Bligh , Paul Wouters 
Message-ID: 
In-Reply-To: <185C280129C4C3502DAC0F80@nimrod.local>
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr>  <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>    <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl>  <24C8A8E2A81760E31D4CDE4A@Ximines.local>    <185C280129C4C3502DAC0F80@nimrod.local>
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: dnsop WG , Alex Bligh 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Alex Bligh 
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 05:07:01 -0000

--On 23 January 2010 04:56:33 +0000 Alex Bligh  wrote:

>> Having verifiable deniability for typo-squated domaims is very useful.
>
> If expensive, where 99% of your domains are unsigned.

By which I mean expensive given this isn't the cheapest attack vector.
If I want to typo squat with a non-existent domain (and it's only
non-existent domains where verification of denial of existence is
an issue), I could just register the domain which would be far
more reliable than all the hocus pocus needed to get spoofing to
work. It's not that hard to get an SSL cert either. And if I
have got the technology to spoof, why not attack one of the 99%
unsigned domains in the zone, rather than an unregistered typo-squat
of a signed one, as the pickings will be far greater?

-- 
Alex Bligh

From ekr@rtfm.com  Fri Jan 22 21:14:37 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A703A63D3 for ; Fri, 22 Jan 2010 21:14:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.914
X-Spam-Level: 
X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.063,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 IcvyC-HQeOQI for ; Fri, 22 Jan 2010 21:14:36 -0800 (PST)
Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 32C0D3A680B for ; Fri, 22 Jan 2010 21:14:36 -0800 (PST)
Received: by pzk4 with SMTP id 4so1503404pzk.32 for ; Fri, 22 Jan 2010 21:14:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.6.25 with SMTP id 25mr2631796waf.25.1264223666883; Fri, 22  Jan 2010 21:14:26 -0800 (PST)
In-Reply-To: 
References:     <20100121202745.GZ81286@shinkuro.com>    <20100122201803.GA24117@vacation.karoshi.com.> 
Date: Fri, 22 Jan 2010 21:14:26 -0800
Message-ID: 
From: Eric Rescorla 
To: Paul Hoffman 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Tony Finch , Andrew Sullivan , bmanning@vacation.karoshi.com, dnsop@ietf.org
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 05:14:37 -0000

On Fri, Jan 22, 2010 at 12:35 PM, Paul Hoffman  wrot=
e:
> At 8:18 PM +0000 1/22/10, bmanning@vacation.karoshi.com wrote:
>>On Fri, Jan 22, 2010 at 09:13:22AM -0800, Paul Hoffman wrote:
>>> At 4:56 PM +0000 1/22/10, Tony Finch wrote:
>>> >On Thu, 21 Jan 2010, Paul Hoffman wrote:
>>> >>
>>> >> - Regular rolling can give you a false sense of security about your =
rolling process
>>> >
>>> >How can you have any sense of security about your rolling process if y=
ou
>>> >don't exercise it?
>>>
>>> Why do people think the opposite of "regular" is "never"?
>>>
>>> --Paul Hoffman, Director
>>
>>
>> =A0 =A0 =A0 to borrow from Andrew - let me posit an analogy...
>>
>> =A0 =A0 =A0 would you rather have your LASIX or LIOP =A0surgery done
>> =A0 =A0 =A0 by someone who has done 12,000 such procedures and
>> =A0 =A0 =A0 does a couple a week or someone who has done a dozen
>> =A0 =A0 =A0 and does them about every couple years or so?
>>
>> =A0 =A0 =A0 sure, the doctor who does them all the time -might- get
>> =A0 =A0 =A0 sloppy and cut corners =A0-- =A0but is that worse than someo=
ne
>> =A0 =A0 =A0 who has only passing understanding of what they are actually
>> =A0 =A0 =A0 doing?
>>
>> =A0 =A0 =A0 the risk isn't -never-, the risk is lack of experience.
>
> Why do people think this is about "the risk" instead of "the risks"?

I haven't formed a useful opinion one way or the other about the operationa=
l
value of frequent key rollovers. However, it seems to me that the value
of those practices is more or less independent of key size, so we've
travelled fairly far afield from the original claim that we need rollovers
to compensate for being forced to use overly-short RSA keys.

-Ekr

From Niall.oReilly@ucd.ie  Sat Jan 23 07:46:10 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB86F3A6944 for ; Sat, 23 Jan 2010 07:46:10 -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 VVURN+oiqR8l for ; Sat, 23 Jan 2010 07:46:10 -0800 (PST)
Received: from dakota.ucd.ie (mailhost.ucd.ie [193.1.169.34]) by core3.amsl.com (Postfix) with ESMTP id 0AEAD3A692A for ; Sat, 23 Jan 2010 07:46:10 -0800 (PST)
Received: from conversion-daemon.dakota.ucd.ie by dakota.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) id <0KWP00901I6U4V00@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for dnsop@ietf.org; Sat, 23 Jan 2010 15:46:04 +0000 (GMT)
Received: from [10.0.1.177] (bark.no8.be [83.141.81.52]) by dakota.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTPSA id <0KWP00608IGPF000@dakota.ucd.ie> for dnsop@ietf.org; Sat, 23 Jan 2010 15:46:01 +0000 (GMT)
Date: Sat, 23 Jan 2010 15:46:00 +0000
From: Niall O'Reilly 
In-reply-to: <1C34A57EB724F3A68C4B5F6B@Ximines.local>
To: dnsop@ietf.org
Message-id: <4B5B19B8.805@ucd.ie>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=UTF-8
Content-transfer-encoding: 7BIT
References:        <20100121202745.GZ81286@shinkuro.com>    <1C34A57EB724F3A68C4B5F6B@Ximines.local>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
Cc: Niall.oReilly@ucd.ie
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 15:46:10 -0000

Alex Bligh wrote:
> 
> 
> --On 22 January 2010 09:13:22 -0800 Paul Hoffman  
> wrote:
> 
>>>> - Regular rolling can give you a false sense of security about your
>>>> rolling process
>>>
>>> How can you have any sense of security about your rolling process if you
>>> don't exercise it?
>>
>> Why do people think the opposite of "regular" is "never"?
> 
> There seems to be some confusion of "regular" and "frequent" too.

	Not to mention conflation of "regular" and "periodic".



From ogud@ogud.com  Sat Jan 23 09:25:24 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0493A6961 for ; Sat, 23 Jan 2010 09:25:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.381
X-Spam-Level: 
X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, J_CHICKENPOX_47=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 JR1O6BLHeJeO for ; Sat, 23 Jan 2010 09:25:23 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id A429D3A6956 for ; Sat, 23 Jan 2010 09:25:23 -0800 (PST)
Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0NHP5sV053866; Sat, 23 Jan 2010 12:25:05 -0500 (EST) (envelope-from ogud@ogud.com)
Message-Id: <201001231725.o0NHP5sV053866@stora.ogud.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sat, 23 Jan 2010 12:25:00 -0500
To: Alex Bligh , Edward Lewis 
From: Olafur Gudmundsson 
In-Reply-To: <13EEA44D7ADF3D8C09360D49@nimrod.local>
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>  <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> <24C8A8E2A81760E31D4CDE4A@Ximines.local>    <13EEA44D7ADF3D8C09360D49@nimrod.local>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Cc: dnsop WG , Alex Bligh 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 17:25:24 -0000

At 15:54 22/01/2010, Alex Bligh wrote:


>--On 22 January 2010 15:45:54 -0500 Edward Lewis  wrote:
>
>>>contents) in example.org. So, whilst opt-out should be avoided
>>>across intervals containing secure delegations, I see no reason
>>>to avoid it across intervals that don't contain secure delegations.
>>
>>Opt-out is restricted to "intervals" that contain only unsecured
>>delegations.
>
>Doh! Yes indeed. In which case I stand by my original argument: I can't
>see how opt-out really increase spoofability. It can't affect
>a secure delegation, and the contents of an insecure delegation
>or denial thereof (if not the delegation itself) are spoofable
>with or without opt-out. Paul's example of a secure delegation
>with opt-out across it can't exist.

Lets say example is signed, bank.example is signed using NSEC3 with opt-out
in one span to hide one division.
Lets say secure.bank.example by co-incidence falls into the opt-ed-out gap.
Now a phisher can attempt to insert an insecure delegation called 
secure.bank.example
into caches and send mails telling people to visit this site to claim 
their price

Opt-out was designed for large delegation-only/mostly zones, in almost all
other cases it should not be used.

The use of NSEC vs NSEC3 in zone is a different discussion.

A zone that contains guess-able names gains almost nothing from using NSEC3.
A zone operator may still feel better using NSEC3 :-)
If you really want to hide the content of your zone only epsilon 
signing will work
RFC4470+RFC4471.

         Olafur 


From paul.hoffman@vpnc.org  Sat Jan 23 09:46:05 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3661F3A6965 for ; Sat, 23 Jan 2010 09:46:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.023
X-Spam-Level: 
X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 8I25WF6bRQMD for ; Sat, 23 Jan 2010 09:46:04 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 57DFD3A692D for ; Sat, 23 Jan 2010 09:46:04 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0NHa3Ct038488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jan 2010 10:36:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:  <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org>    <645C47F3-91A7-4874-B0DD-402F1A7AE307@rfc1035.com>  <503DA9EF-A56F-4069-8C79-ED09F30FFD69@rfc1035.com> <20100122124539.GB84189@shinkuro.com> <20100122152302.GA22286@vacation.karoshi.com.> <20100123001706.GB85026@shinkuro.com> 
Date: Sat, 23 Jan 2010 09:36:03 -0800
To: David Conrad , Andrew Sullivan 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: dnsop@ietf.org
Subject: [DNSOP] Value of 4641bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 17:46:05 -0000

At 6:07 PM -0800 1/22/10, David Conrad wrote:
>Operationally, people will do what they think is appropriate regardless of what is written in an RFC.  In some version of an ideal world, folks who care about "doing the right thing" could point to an RFC and ask vendors if they implement that RFC (presuming the RFC describes doing the right thing).  I don't fully get why it makes sense to dumb down RFCs in this context, but I'm sure it's because I'm missing something.

You are. People will tell operators "an RFC exists that covers your operation, so you must follow it". We see that all the time in the IETF in general, and I believe at least one person said it at the mic at the DNSOP WG in Dublin.

Thus, we really want our operational RFCs to reflect the widest range of best practices that are actually considered "best". If we get lazy and just list one scenario, we will be hurting the Internet by restricting some organizations to following one model when another might have made more sense for them.

--Paul Hoffman, Director
--VPN Consortium

From alex@alex.org.uk  Sat Jan 23 10:16:23 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418A13A68DF for ; Sat, 23 Jan 2010 10:16:23 -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 lfgRjaJuW+HN for ; Sat, 23 Jan 2010 10:16:22 -0800 (PST)
Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id 7055C3A683C for ; Sat, 23 Jan 2010 10:16:22 -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 9FD24C563AC; Sat, 23 Jan 2010 18:16:16 +0000 (GMT)
Date: Sat, 23 Jan 2010 18:16:15 +0000
From: Alex Bligh 
To: Olafur Gudmundsson , Edward Lewis 
Message-ID: <6EA43DCC3C49948C424EA96D@Ximines.local>
In-Reply-To: <201001231725.o0NHP5sV053866@stora.ogud.com>
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>  <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> <24C8A8E2A81760E31D4CDE4A@Ximines.local>    <13EEA44D7ADF3D8C09360D49@nimrod.local> <201001231725.o0NHP5sV053866@stora.ogud.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: dnsop WG , Alex Bligh 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Alex Bligh 
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 18:16:23 -0000

--On 23 January 2010 12:25:00 -0500 Olafur Gudmundsson  
wrote:

> Opt-out was designed for large delegation-only/mostly zones, in almost all
> other cases it should not be used.

And this was the only use case I was suggesting was excepted from
the blanket "should not" (in fact I went further and said it should
only apply to large delegation-only/mostly zones where secure
delegations were sparse).

-- 
Alex Bligh

From mlarson@verisign.com  Sat Jan 23 17:00:20 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7171528C0F1 for ; Sat, 23 Jan 2010 17:00:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2
X-Spam-Level: **
X-Spam-Status: No, score=2 tagged_above=-999 required=5 tests=[BAYES_80=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 rj+FZF7vd38b for ; Sat, 23 Jan 2010 17:00:19 -0800 (PST)
Received: from mail.kahlerlarson.org (tornado.kahlerlarson.org [64.22.125.99]) by core3.amsl.com (Postfix) with ESMTP id 82B5A28C0E6 for ; Sat, 23 Jan 2010 17:00:19 -0800 (PST)
Received: from sirocco.local (pool-71-178-183-75.washdc.fios.verizon.net [71.178.183.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kahlerlarson.org (Postfix) with ESMTP id 008FA37CF6 for ; Sat, 23 Jan 2010 20:00:17 -0500 (EST)
Date: Sat, 23 Jan 2010 20:00:17 -0500
From: Matt Larson 
To: dnsop WG 
Message-ID: <20100124010017.GJ35464@sirocco.local>
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>  <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> <24C8A8E2A81760E31D4CDE4A@Ximines.local>   
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: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jan 2010 01:00:20 -0000

On Fri, 22 Jan 2010, Paul Wouters wrote:
> On Fri, 22 Jan 2010, Alex Bligh wrote:
>> I meant computational resource requirements resultant from crypto
>> operations, not algorithmic complexity.
>
> I had no problems doing this on a 1.2M domains TLD zone, using off the
> shelf hardware, integrating into the TLD's hourly update interval.
> (http://www.cira.ca/dnssec/)

Try 100M delegations, updated every 15 seconds, and sending the
resulting large non-Opt-out zone to places with poor connectivity such
as Nairobi, Kenya.

Arguments such as "I did it on once on commodity hardware with freely
available tools" or "you can implement that in an afternoon" do not
transfer well to large, critically important TLDs (or any large-scale,
critical service).

Matt

From mayer@gis.net  Sat Jan 23 21:39:44 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CE8C3A67F8 for ; Sat, 23 Jan 2010 21:39:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 xbb6s5ZuuXwH for ; Sat, 23 Jan 2010 21:39:43 -0800 (PST)
Received: from gis.net (mx05.gis.net [208.218.130.13]) by core3.amsl.com (Postfix) with ESMTP id 163CA3A67E1 for ; Sat, 23 Jan 2010 21:39:41 -0800 (PST)
Received: from [127.0.0.1] ([63.209.235.12]) by mx05.gis.net; Sun, 24 Jan 2010 00:38:26 -0500
Message-ID: <4B5BDCCB.50504@gis.net>
Date: Sun, 24 Jan 2010 00:38:19 -0500
From: Danny Mayer 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Alfred_H=CEnes?= 
References: <201001132058.VAA11959@TR-Sys.de>
In-Reply-To: <201001132058.VAA11959@TR-Sys.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Sun, 24 Jan 2010 01:36:57 -0800
Cc: namedroppers@ops.ietf.org, dnsop@ietf.org
Subject: Re: [DNSOP] [dnsext] Re:  Priming query transport selection
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mayer@gis.net
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jan 2010 05:39:44 -0000

Alfred HÎnes wrote:
> I apologize for cross-posting due to topical overlap.
> Please confine follow-up messages to the appropriate list.
> 
> 
> In the message to DNSOP regarding draft-ietf-dnsop-resolver-priming-02
> archived at
>   ,
> Olafur Gudmundsson scratched at a topic of interest to namedroppers
> as well; he wrote:
> 
>>  ...
>>
>> Background:
>> 26 signed glue records will require about 5K answer if each RRSet is
>> signed by a single 1024 bit RSA key.
>> This will never fit into an ENDS0 answer as number of implementations
>> have 4096 byte hard limit on answer size.
> 
> 
> Did you read the News these days?
> 
> An international team lead by the BSI (the "German NSA") and others
> has solved the RSA-768 challenge, and experts reportedly expect, due
> to significant progresses, that RSA-1024 will be solved in a rather
> short time, likely by the end of this year or so!
> 
> This means that we should immediately plan operationally for
> widespread use of 2048-bit RSA keys in the "near" future.
> 
> 
>> As of today all the root servers instances that my host reached
>> answered a TCP query.
>>
>> Proposed replacement text:
>>
>> |2.1.  Parameters of a Priming Query
>> |
>> |  A priming query MUST use a QNAME of "." and a QTYPE of NS, QCLASS
>> |  of IN, with RD bit set to 0, the source port of the query should
>> |  be randomly selected [RFC5452].
>> |
>> |  A DNSSEC aware resolver SHOULD sent the priming query over TCP.
>> |  If TCP is refused a different server SHOULD be tried, after 3 tries
>> |  the resolver SHOULD fall back on UDP.
>> |
>> |  A DNSSEC ignorant but EDNS0 capable, resolver SHOULD issue the
>> |  priming query over UDP, ENDS0 option MUST be included with buffer
>> |  size of 1220 or larger.  If the UDP query times out TCP SHOULD be
>> |  tried.
>> |
>> |  An EDNS0 ignorant resolver MUST issue the priming query over UDP.
>>
>> ...

I'm not sure I understand the point to this part. Since this is a draft
and you would be talking about the next versions of resolvers that would
be expect to support this (as opposed to existing ones) why would you
expect there to be any future resolver ignorant of DNSSEC? Aren't we
trying to make DNSSEC mandatory for future resolvers?

Danny



From A.Hoenes@TR-Sys.de  Sun Jan 24 08:23:49 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4733A68F0 for ; Sun, 24 Jan 2010 08:23:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.851
X-Spam-Level: ***
X-Spam-Status: No, score=3.851 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
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 RmTQF38nq2Si for ; Sun, 24 Jan 2010 08:23:48 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 2672B3A688D for ; Sun, 24 Jan 2010 08:23:46 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA250800206; Sun, 24 Jan 2010 17:23:26 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA00666; Sun, 24 Jan 2010 17:23:24 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= 
Message-Id: <201001241623.RAA00666@TR-Sys.de>
To: mayer@gis.net
Date: Sun, 24 Jan 2010 17:23:24 +0100 (MEZ)
In-Reply-To: <4B5BDCCB.50504@gis.net> from Danny Mayer at Jan "24, " 2010 "00:38:19" am
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org, dnsop@ietf.org
Subject: Re: [DNSOP] [dnsext] Re:  Priming query transport selection
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jan 2010 16:23:49 -0000

Danny Mayer wrote, in a response sent to me, referring to
Olafur Gudmundsson's text proposal quoted in my posting on Jan 13:

>>> Proposed replacement text:
>>>
>>> |2.1.  Parameters of a Priming Query
>>> |
>>> |  A priming query MUST use a QNAME of "." and a QTYPE of NS, QCLASS
>>> |  of IN, with RD bit set to 0, the source port of the query should
>>> |  be randomly selected [RFC5452].
>>> |
>>> |  A DNSSEC aware resolver SHOULD sent the priming query over TCP.
>>> |  If TCP is refused a different server SHOULD be tried, after 3 tries
>>> |  the resolver SHOULD fall back on UDP.
>>> |
>>> |  A DNSSEC ignorant but EDNS0 capable, resolver SHOULD issue the
>>> |  priming query over UDP, ENDS0 option MUST be included with buffer
>>> |  size of 1220 or larger.  If the UDP query times out TCP SHOULD be
>>> |  tried.
>>> |
>>> |  An EDNS0 ignorant resolver MUST issue the priming query over UDP.
>>>
>>> ...
>
> I'm not sure I understand the point to this part. Since this is a draft
> and you would be talking about the next versions of resolvers that would
> be expect to support this (as opposed to existing ones) why would you
> expect there to be any future resolver ignorant of DNSSEC? Aren't we
> trying to make DNSSEC mandatory for future resolvers?
>
> Danny

Danny,
Please note that the quoted block of text wasn't mine, so maybe your
message ought to have be addressed primarily to its author.
But never mind.  It has arrived there and on the lists.

The primary goals of my posting were to point out that:

  - limiting the recommended priming query discussion and advice
    in teh Priming Query draft by a perspective on 1024-bit RSA keys
    and signatures is too narrow-headed if the advice shall last
    for more than a very small couple of years, and

  - with respect to message size issues and efficiency, DNSEXT
    should resume work on ECC keys and signatures for DNSSEC ASAP.

Regarding your argument agaibst Olafur's suggested text, I fear
there will be lots of resolvers for many years that cannot reasonably
be expected to be DNSSEC aware, i.e. performing DNSSEC validation.

I do not want to touch on policy issues -- whether CPE and end
systems are in a better place for providing useful trust by
performing DNSSEC validation than typical large-scale caching
resolvers provided and maintained by ISPs.

However:
DNSSEC is a huge code addition, in particular for embedded TCP/IP
implementations; the proliferation of signature algorithms we are
starting to admit will make things even more complicated.
In contrast, EDNS0 is a rather tiny addition providing general
utility and it indeed really should be supported by such
implementations.
Therefore, I believe that we should give valid advice for such
small-scale implementions as well -- they'll depend on working
priming queries in any case.

As pointed out by other folks in another current thread on DNSOP,
BCP documents should not restrict the advice they are giving to a
single mainstream scenario when the topic is more general in
nature, but better cover various important scenarios.
Thus, I indeed recommend to keep appropriate advice for DNSSEC
unaware resolvers in the Priming Query draft.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+


From thierry.moreau@connotech.com  Sun Jan 24 09:16:27 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424FA3A690B for ; Sun, 24 Jan 2010 09:16:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=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 YwmWO0bl8UxB for ; Sun, 24 Jan 2010 09:16:26 -0800 (PST)
Received: from smtp121.rog.mail.re2.yahoo.com (smtp121.rog.mail.re2.yahoo.com [206.190.53.26]) by core3.amsl.com (Postfix) with SMTP id 360943A681E for ; Sun, 24 Jan 2010 09:16:25 -0800 (PST)
Received: (qmail 18561 invoked from network); 24 Jan 2010 17:16:25 -0000
Received: from 209-148-182-228.dynamic.rogerstelecom.net (thierry.moreau@209.148.182.228 with plain) by smtp121.rog.mail.re2.yahoo.com with SMTP; 24 Jan 2010 09:16:25 -0800 PST
X-Yahoo-SMTP: 7IPMVjmswBCDdW1xQhDBl8GZu.GNdc4Rou3wNA--
X-YMail-OSG: BWM8ID0VM1lMKKbamxioK_tR3z8Kv1NF_JFS90GW983M0z6LwhXzF2QJUDJikmnjKQ--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4B5C82E2.5020606@connotech.com>
Date: Sun, 24 Jan 2010 12:26:58 -0500
From: Thierry Moreau 
User-Agent: Thunderbird 2.0.0.17 (X11/20090608)
MIME-Version: 1.0
To: Paul Hoffman 
References: 	<06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org>				<645C47F3-91A7-4874-B0DD-402F1A7AE307@rfc1035.com>		<503DA9EF-A56F-4069-8C79-ED09F30FFD69@rfc1035.com>	<20100122124539.GB84189@shinkuro.com>	<20100122152302.GA22286@vacation.karoshi.com.>	<20100123001706.GB85026@shinkuro.com>	 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dnsop@ietf.org, David Conrad 
Subject: Re: [DNSOP] Value of 4641bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jan 2010 17:16:27 -0000

Paul Hoffman wrote:
> At 6:07 PM -0800 1/22/10, David Conrad wrote:
>   
>> Operationally, people will do what they think is appropriate regardless of what is written in an RFC.  In some version of an ideal world, folks who care about "doing the right thing" could point to an RFC and ask vendors if they implement that RFC (pre
>>     
> suming the RFC describes doing the right thing).  I don't fully get why it makes sense to dumb down RFCs in this context, but I'm sure it's because I'm missing something.
>
> You are. People will tell operators "an RFC exists that covers your operation, so you must follow it". We see that all the time in the IETF in general, and I believe at least one person said it at the mic at the DNSOP WG in Dublin.
>
> Thus, we really want our operational RFCs to reflect the widest range of best practices that are actually considered "best". If we get lazy and just list one scenario, we will be hurting the Internet by restricting some organizations to following one mo
> del when another might have made more sense for them.
>   
Then, you perpetuate the IT security paradigm where the operator 
complies to an auditable specifications-based operations guide, but the 
attackers are given opportunities to pass through the cracks.

That's because a given (operational) instance applies a single scenario 
that is unique and never fully examined: the RFC approach with multiple 
scenarios fails to provide a full analysis opportunity for any single 
one (that would be obviously out of scope in some aspects).

For instance, full review of an operational plan requires disclosure of 
internal security measures (around personnel turnover) that are not 
typically subject to formalization in a form suitable for IT security 
analysis.

I don't have an answer for this paradox.

Regards,

- Thierry Moreau
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>   


From mehmet@icann.org  Mon Jan 25 01:56:53 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21CE73A682C for ; Mon, 25 Jan 2010 01:56:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.74
X-Spam-Level: 
X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axjPBFpCSh19 for ; Mon, 25 Jan 2010 01:56:52 -0800 (PST)
Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 89BEF3A672E for ; Mon, 25 Jan 2010 01:56:52 -0800 (PST)
Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 25 Jan 2010 01:56:58 -0800
From: Mehmet Akcin 
To: Mehmet Akcin 
Date: Mon, 25 Jan 2010 01:56:56 -0800
Thread-Topic: L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
Thread-Index: AcqdpLpX5r4QkemmKkie8KwdeGSmHw==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.3.0.091002
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 25 Jan 2010 02:00:00 -0800
Subject: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 09:56:53 -0000

Hi

As part of staged, incremental deployment of DNSSEC in the root zone L-Root
will begin serving a Deliberately Unvalidatable Root Zone (DURZ) after the
completion of its scheduled maintenance at 2010-01-27 1800 UTC - 2000 UTC

Please contact L-Root NOC via noc@dns.icann.org or T: +1.310.301.5817 if yo=
u
have any questions.

Please contact with rootsign@icann.org if you have any questions regarding
DNSSEC Deployment at root zone.

Regards

Joe Abley / Mehmet Akcin / Dave Knight
ICANN DNS Ops / L-ROOT


From Ed.Lewis@neustar.biz  Mon Jan 25 09:56:16 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14073A686C for ; Mon, 25 Jan 2010 09:56:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.195
X-Spam-Level: 
X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=0.545,  BAYES_20=-0.74]
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 jGyWZ12cAB7f for ; Mon, 25 Jan 2010 09:56:16 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id DCDDF3A67F7 for ; Mon, 25 Jan 2010 09:56:15 -0800 (PST)
Received: from [10.31.200.251] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0PHuDCa069598; Mon, 25 Jan 2010 12:56:14 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:     <20100121202745.GZ81286@shinkuro.com>    <20100122201803.GA24117@vacation.karoshi.com.>  
Date: Mon, 25 Jan 2010 12:56:09 -0500
To: Eric Rescorla 
From: Edward Lewis 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Cc: Tony Finch , Andrew Sullivan , bmanning@vacation.karoshi.com, dnsop@ietf.org, Paul Hoffman 
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 17:56:16 -0000

At 21:14 -0800 1/22/10, Eric Rescorla wrote:

>I haven't formed a useful opinion one way or the other about the operational
>value of frequent key rollovers. However, it seems to me that the value
>of those practices is more or less independent of key size, so we've
>travelled fairly far afield from the original claim that we need rollovers
>to compensate for being forced to use overly-short RSA keys.

What I've taken from this thread is that choices made for key 
management are not driven by cryptographic considerations.  What I 
wonder now is whether my choice for key size is too big - the cost of 
that is the DNS response datagram size.

I envision monthly changes of the ZSK and annual changes of the KSK. 
I can't see any savings in extending the periodicity of this, but I 
can see savings in lowering the number of bits needed to send the 
public key and signature along.

Last time I looked (a few months ago) most signed TLDs to use 2048 
bit KSKs and 1024 bit ZSKs.   Perhaps there is no reason to have two 
different sized keys, I would guess that since "a chain is only as 
strong as its weakest link" all keys could be dropped to 1024, or 
even less.

But what nags at me are the NIST recommendations that talk of a keys 
having so many bits of randomness - like a 1K or 2K key having 112 
bits.

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

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

From paul@xelerance.com  Mon Jan 25 10:05:33 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCAF3A68B6 for ; Mon, 25 Jan 2010 10:05:33 -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 RAg8vsLhOl4L for ; Mon, 25 Jan 2010 10:05:32 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 25F813A688D for ; Mon, 25 Jan 2010 10:05:30 -0800 (PST)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id B3475571B8; Mon, 25 Jan 2010 13:05:35 -0500 (EST)
Date: Mon, 25 Jan 2010 13:05:35 -0500 (EST)
From: Paul Wouters 
To: Edward Lewis 
In-Reply-To: 
Message-ID: 
References:     <20100121202745.GZ81286@shinkuro.com>    <20100122201803.GA24117@vacation.karoshi.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: dnsop@ietf.org
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 18:05:33 -0000

On Mon, 25 Jan 2010, Edward Lewis wrote:

> Last time I looked (a few months ago) most signed TLDs to use 2048 bit KSKs 
> and 1024 bit ZSKs.   Perhaps there is no reason to have two different sized 
> keys, I would guess that since "a chain is only as strong as its weakest 
> link" all keys could be dropped to 1024, or even less.

The weakness of a key is partially determined by the length of its usage
period. If you plan to use the KSK for a period 12 times longer, making it
1024 is not making it equal to the ZSK strength of "1024 for 30 days"

I don't think people have experienced serious troubles with 2048 bit keys,
though if you want to go higher, you're probably better of waiting for ECC,
as that will give you smaller signatures compared to RSA with the same key
size. But AFAIK, no dns implementation supports ECC yet.

Paul

From Francis.Dupont@fdupont.fr  Mon Jan 25 10:34:54 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A243A6878 for ; Mon, 25 Jan 2010 10:34:54 -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=[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 vF4n9dNJBCBd for ; Mon, 25 Jan 2010 10:34:54 -0800 (PST)
Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id AA07E3A686C for ; Mon, 25 Jan 2010 10:34:53 -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 o0PIW4iv083151; Mon, 25 Jan 2010 18:32:04 GMT (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201001251832.o0PIW4iv083151@givry.fdupont.fr>
From: Francis Dupont 
To: Paul Wouters 
In-reply-to: Your message of Mon, 25 Jan 2010 13:05:35 EST.  
Date: Mon, 25 Jan 2010 18:32:04 +0000
Sender: Francis.Dupont@fdupont.fr
Cc: dnsop@ietf.org, Edward Lewis 
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 18:34:54 -0000

 In your previous mail you wrote:

   But AFAIK, no dns implementation supports ECC yet.
   
=> *** flame war ON ***

In fact it is no true: GOST (in its second version which will be used
for DNSSEC) is based on ECC.

*** flame war OFF ***

Francis.Dupont@fdupont.fr

PS: there is no real technical issue for ECC based DNSSEC: all it is
needed is reasonable support in not very last OpenSSLs.
So the real problems are:
 - a good draft
 - some consensus
 - IETF publication delays
IMHO we should ask Russ to nominate a cryptographer (or himself)
to re-initiate the process from the first step: a good draft
(here good is sound from a crypto point of view, easy to implement
(I already explained what I meant by this) and without a zillion
different options (what I believe was the problem of previous attempts)).

From paul.hoffman@vpnc.org  Mon Jan 25 10:44:59 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1418F3A67F2 for ; Mon, 25 Jan 2010 10:44:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level: 
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 mrSh94qNBcQq for ; Mon, 25 Jan 2010 10:44:58 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4806E3A67F0 for ; Mon, 25 Jan 2010 10:44:58 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0PIj3v5003895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 11:45:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:     <20100121202745.GZ81286@shinkuro.com>    <20100122201803.GA24117@vacation.karoshi.com.>    
Date: Mon, 25 Jan 2010 10:44:12 -0800
To: Paul Wouters , Edward Lewis 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 18:44:59 -0000

At 1:05 PM -0500 1/25/10, Paul Wouters wrote:
>On Mon, 25 Jan 2010, Edward Lewis wrote:
>
>>Last time I looked (a few months ago) most signed TLDs to use 2048 bit KSKs and 1024 bit ZSKs.   Perhaps there is no reason to have two different sized keys, I would guess that since "a chain is only as strong as its weakest link" all keys could be dropped to 1024, or even less.
>
>The weakness of a key is partially determined by the length of its usage
>period. If you plan to use the KSK for a period 12 times longer, making it
>1024 is not making it equal to the ZSK strength of "1024 for 30 days"

Exactly right, but still mostly irrelevant. What is the value of the keys you are talking about? Is one so valuable that an attacker would spend the amount of money and time needed to break it? What value would they get from that attack?

More importantly: could the attacker get move value from spending the money and time breaking a different key of the same size? Look at the myriad of 1024-bit keys in the world whose lifetimes are much longer than a year. If any of them would yield a better result for the attacker, he won't bother with yours; if yours is the highest value, he won't bother with the others.

If you really believe that a 1024-bit ZSK key is the appropriate size for a month, then you only need something about 12 times as strong for the KSK under the same threat model. 1536 bits would be much more than you needed; a rough estimate would be 1200 bits. The reason these numbers are never discussed in DNSOP is because no one is discussing their actual threat model and the estimated value of the attacks.

--Paul Hoffman, Director
--VPN Consortium

From scott.rose@nist.gov  Mon Jan 25 11:19:17 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C723A685F for ; Mon, 25 Jan 2010 11:19:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=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 4mDtZPnwh8hx for ; Mon, 25 Jan 2010 11:19:14 -0800 (PST)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 8E8EF3A6834 for ; Mon, 25 Jan 2010 11:19:14 -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 o0PJIcFh026162; Mon, 25 Jan 2010 14:18:38 -0500
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Mon, 25 Jan 2010 14:18:22 -0500
From: "Rose, Scott W." 
To: Edward Lewis , Eric Rescorla 
Date: Mon, 25 Jan 2010 14:18:37 -0500
Thread-Topic: [DNSOP] rfc4641bis: ZSK-roll-frequency
Thread-Index: Acqd59RIZgAYHk4kTWWhm9kHcOCuwwAC11uY
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: scott.rose@nist.gov
Cc: Tony Finch , Andrew Sullivan , "bmanning@vacation.karoshi.com" , "dnsop@ietf.org" , Paul Hoffman 
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 19:19:17 -0000

On 1/25/10 12:56 PM, "Edward Lewis"  wrote:
> At 21:14 -0800 1/22/10, Eric Rescorla wrote:
>=20
>> I haven't formed a useful opinion one way or the other about the operati=
onal
>> value of frequent key rollovers. However, it seems to me that the value
>> of those practices is more or less independent of key size, so we've
>> travelled fairly far afield from the original claim that we need rollove=
rs
>> to compensate for being forced to use overly-short RSA keys.
>=20
> What I've taken from this thread is that choices made for key
> management are not driven by cryptographic considerations.  What I
> wonder now is whether my choice for key size is too big - the cost of
> that is the DNS response datagram size.
>=20
> I envision monthly changes of the ZSK and annual changes of the KSK.
> I can't see any savings in extending the periodicity of this, but I
> can see savings in lowering the number of bits needed to send the
> public key and signature along.
>=20
> Last time I looked (a few months ago) most signed TLDs to use 2048
> bit KSKs and 1024 bit ZSKs.   Perhaps there is no reason to have two
> different sized keys, I would guess that since "a chain is only as
> strong as its weakest link" all keys could be dropped to 1024, or
> even less.
>=20
You can - sure.  Why not?  For a while the NIST recommendation was to have
2048 bit ZSK and KSK's.  Now that better tools are out there, no need to go
by file sizes anymore :)

> But what nags at me are the NIST recommendations that talk of a keys
> having so many bits of randomness - like a 1K or 2K key having 112
> bits.

I've been assured there is some sort of calculation involved, but I can't d=
o
it. =20

All of the NIST recommendations are really grounded in the (Fed) PKI world.
DNSSEC isn't big enough (or well known) to justify a separate set of policy
recommendations.  NIST(via the NSA) has decided that 1024 bit RSA could be
vulnerable soon, so a stake in the ground is planted to move PKI certs (and
everything else) to 2048 bit RSA.  After much debate, we (networking) got
them (Comp Security) to back down and agree that 1024 bit was still ok, as
long as the key is changed ~3 months (at max).  Otherwise it would policy t=
o
have both keys be 2048 bits.

Scott


>=20
> --
> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-
> Edward Lewis
> NeuStar                    You can leave a voice message at +1-571-434-54=
68
>=20
> As with IPv6, the problem with the deployment of frictionless surfaces is
> that they're not getting traction.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Scott Rose
NIST
scottr@nist.gov
ph: +1 301-975-8439
Google Voice: +1-571-249-3671

http://www.dnsops.gov/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



From paul.hoffman@vpnc.org  Mon Jan 25 11:25:02 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B8C3A683C for ; Mon, 25 Jan 2010 11:25:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level: 
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 HE6o-pz87FaO for ; Mon, 25 Jan 2010 11:25:02 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2936D3A67F0 for ; Mon, 25 Jan 2010 11:25:02 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0PJP1Rh006612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 12:25:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <201001251832.o0PIW4iv083151@givry.fdupont.fr>
References: <201001251832.o0PIW4iv083151@givry.fdupont.fr>
Date: Mon, 25 Jan 2010 11:24:58 -0800
To: Francis Dupont 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii"
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 19:25:02 -0000

At 6:32 PM +0000 1/25/10, Francis Dupont wrote:
> In your previous mail you wrote:
>So the real problems are:
> - a good draft
> - some consensus
> - IETF publication delays
>IMHO we should ask Russ to nominate a cryptographer (or himself)
>to re-initiate the process from the first step: a good draft
>(here good is sound from a crypto point of view, easy to implement
>(I already explained what I meant by this) and without a zillion
>different options (what I believe was the problem of previous attempts)).

That might be draft-hoffman-dnssec-ecdsa. I let it expire earlier this month because the DNSEXT WG is still not clear on the allowable statuses for crypto documents, but have today revived it based on your comment.

If you don't consider this to be "a good draft", I am quite open to suggestions for improvement!

--Paul Hoffman, Director
--VPN Consortium

From ogud@ogud.com  Mon Jan 25 18:32:14 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025313A67D8 for ; Mon, 25 Jan 2010 18:32:14 -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 mMAloaGK4R2V for ; Mon, 25 Jan 2010 18:32:13 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 0AB063A681A for ; Mon, 25 Jan 2010 18:32:12 -0800 (PST)
Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0Q2WH80073234; Mon, 25 Jan 2010 21:32:18 -0500 (EST) (envelope-from ogud@ogud.com)
Message-Id: <201001260232.o0Q2WH80073234@stora.ogud.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 25 Jan 2010 21:32:13 -0500
To: mayer@gis.net
From: Olafur Gudmundsson 
In-Reply-To: <4B5BDCCB.50504@gis.net>
References: <201001132058.VAA11959@TR-Sys.de> <4B5BDCCB.50504@gis.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] [dnsext] Re:  Priming query transport selection
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 02:32:14 -0000

At 00:38 24/01/2010, Danny Mayer wrote:

> >> Proposed replacement text:
> >>
> >> |2.1.  Parameters of a Priming Query
> >> |
> >> |  A priming query MUST use a QNAME of "." and a QTYPE of NS, QCLASS
> >> |  of IN, with RD bit set to 0, the source port of the query should
> >> |  be randomly selected [RFC5452].
> >> |
> >> |  A DNSSEC aware resolver SHOULD sent the priming query over TCP.
> >> |  If TCP is refused a different server SHOULD be tried, after 3 tries
> >> |  the resolver SHOULD fall back on UDP.
> >> |
> >> |  A DNSSEC ignorant but EDNS0 capable, resolver SHOULD issue the
> >> |  priming query over UDP, ENDS0 option MUST be included with buffer
> >> |  size of 1220 or larger.  If the UDP query times out TCP SHOULD be
> >> |  tried.
> >> |
> >> |  An EDNS0 ignorant resolver MUST issue the priming query over UDP.
> >>
> >> ...
>
>I'm not sure I understand the point to this part. Since this is a draft
>and you would be talking about the next versions of resolvers that would
>be expect to support this (as opposed to existing ones) why would you
>expect there to be any future resolver ignorant of DNSSEC? Aren't we
>trying to make DNSSEC mandatory for future resolvers?

While some of us hope all resolvers will support DNSSEC at some point 
in the future,
there are resolvers that never will.
The paragraph as I tried to frame it is to not place onerous burden 
on the system,
if a Resolver has no intention of validating anything it should 
"consider itself as
DNSSEC ignorant".

         Olafur



From mohta@necom830.hpcl.titech.ac.jp  Mon Jan 25 18:45:08 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D603A684E for ; Mon, 25 Jan 2010 18:45:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level: 
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 ZgsN-HKZZe5I for ; Mon, 25 Jan 2010 18:45:07 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 6A42B28C0CE for ; Mon, 25 Jan 2010 18:45:05 -0800 (PST)
Received: (qmail 20091 invoked from network); 26 Jan 2010 03:38:59 -0000
Received: from bmdi3079.bmobile.ne.jp (HELO necom830.hpcl.titech.ac.jp) (202.221.175.79) by necom830.hpcl.titech.ac.jp with SMTP; 26 Jan 2010 03:38:59 -0000
Message-ID: <4B5E5711.20403@necom830.hpcl.titech.ac.jp>
Date: Tue, 26 Jan 2010 11:44:33 +0900
From: Masataka Ohta 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en
MIME-Version: 1.0
To: Paul Hoffman 
References: 				<20100121202745.GZ81286@shinkuro.com>				<20100122201803.GA24117@vacation.karoshi.com.>				 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: dnsop@ietf.org, Edward Lewis 
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2010 02:45:08 -0000

Paul Hoffman wrote:

> The reason these numbers are never discussed in DNSOP is because
> no one is discussing their actual threat model and the estimated
> value of the attacks.

The practical threat model is frequent social attacks on a trusted
third party or two, which means there is no such thing as a trusted
third party.

That is, PKI, including DNSSEC, merely gives false sense of security.

						Masataka Ohta



From mehmet@icann.org  Wed Jan 27 09:31:08 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773863A6A93 for ; Wed, 27 Jan 2010 09:31:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.67
X-Spam-Level: 
X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1Yj0Tz0epKy for ; Wed, 27 Jan 2010 09:31:07 -0800 (PST)
Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id BD51F28C140 for ; Wed, 27 Jan 2010 09:31:07 -0800 (PST)
Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 27 Jan 2010 09:31:22 -0800
From: Mehmet Akcin 
To: "dnsop@ietf.org" 
Date: Wed, 27 Jan 2010 09:31:18 -0800
Thread-Topic: L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
Thread-Index: AcqfdoiWDdirDrvupkenf0z5ibplSQ==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.3.0.091002
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 17:31:08 -0000

Hello,
=20
L-Root maintenance is starting in 30 mins ( 2010-01-27 1800 UTC )

Regards

Joe Abley / Mehmet Akcin / Dave Knight
ICANN DNS Ops / L-ROOT

>> Hi
>>
>> As part of staged, incremental deployment of DNSSEC in the root
>> zone L-Root will begin serving a Deliberately Unvalidatable
>> Root Zone (DURZ) after the completion of its scheduled
>> maintenance at 2010-01-27 1800 UTC - 2000 UTC
>>
>> Please contact L-Root NOC via noc@dns.icann.org or
>> T: +1.310.301.5817 if you have any questions.
>>
>> Please contact with rootsign@icann.org if you have any
>> questions regarding DNSSEC Deployment at root zone.





From mehmet@icann.org  Wed Jan 27 10:59:32 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC303A67FF for ; Wed, 27 Jan 2010 10:59:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.134
X-Spam-Level: 
X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465,  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 U8MmT-21FOh8 for ; Wed, 27 Jan 2010 10:59:31 -0800 (PST)
Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id A8DA73A67F4 for ; Wed, 27 Jan 2010 10:59:31 -0800 (PST)
Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 27 Jan 2010 10:59:46 -0800
From: Mehmet Akcin 
To: Mehmet Akcin , "dnsop@ietf.org" 
Date: Wed, 27 Jan 2010 10:59:46 -0800
Thread-Topic: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
Thread-Index: AcqfdoiWDdirDrvupkenf0z5ibplSQADFvSz
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.3.0.091002
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 18:59:32 -0000

Hello World,

L-Root has completed it's maintenance and now serving DURZ.

You can observe L-Root DSC Stats by visiting
http://stats.l.root-servers.org

Please contact L-Root NOC via email noc@dns.icann.org or T: +1.310.301.5817
if you have any questions

Please contact rootsign@icann.org if you have any questions regarding DNSSE=
C
Deployment at root zone.

Joe Abley / Mehmet Akcin / Dave Knight
ICANN DNS Ops / L-ROOT / AS20144 / AS-LROOT
Peering info: http://as20144.peeringdb.com


On 1/27/10 12:31 PM, "Mehmet Akcin"  wrote:

> Hello,
> =20
> L-Root maintenance is starting in 30 mins ( 2010-01-27 1800 UTC )
>=20
> Regards
>=20
> Joe Abley / Mehmet Akcin / Dave Knight
> ICANN DNS Ops / L-ROOT
>=20
>>> Hi
>>>=20
>>> As part of staged, incremental deployment of DNSSEC in the root
>>> zone L-Root will begin serving a Deliberately Unvalidatable
>>> Root Zone (DURZ) after the completion of its scheduled
>>> maintenance at 2010-01-27 1800 UTC - 2000 UTC
>>>=20
>>> Please contact L-Root NOC via noc@dns.icann.org or
>>> T: +1.310.301.5817 if you have any questions.
>>>=20
>>> Please contact with rootsign@icann.org if you have any
>>> questions regarding DNSSEC Deployment at root zone.
>=20
>=20
>=20
>=20
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


From Francis.Dupont@fdupont.fr  Wed Jan 27 14:02:02 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB19F3A6882 for ; Wed, 27 Jan 2010 14:02:02 -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=[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 OVDpzhYrYAiG for ; Wed, 27 Jan 2010 14:02:02 -0800 (PST)
Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id E41D83A683E for ; Wed, 27 Jan 2010 14:02:01 -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 o0RLxCFi070720; Wed, 27 Jan 2010 21:59:13 GMT (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201001272159.o0RLxCFi070720@givry.fdupont.fr>
From: Francis Dupont 
To: Paul Hoffman 
In-reply-to: Your message of Mon, 25 Jan 2010 11:24:58 PST.  
Date: Wed, 27 Jan 2010 21:59:12 +0000
Sender: Francis.Dupont@fdupont.fr
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 22:02:03 -0000

 In your previous mail you wrote:

   That might be draft-hoffman-dnssec-ecdsa.

=> IMHO we have a problem with ECDSA (and DSA too): verify is too slow,
in particular it is slower than signature. You can expect a crypto
accelerator for a master authoritative server, but not (yet?) for
a caching server... I think this killed DSA in the real world
(no DNSSEC deployment uses it).

Thanks

Francis.Dupont@fdupont.fr

PS: I have another (very technical) concern: I deeply dislike crypto
algorithms which require a random value for signing. DSA has this
IMHO bad property and ECDSA shares it.

From marka@isc.org  Wed Jan 27 14:25:13 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99EB13A6926 for ; Wed, 27 Jan 2010 14:25:13 -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 wXuY3oHWtuHH for ; Wed, 27 Jan 2010 14:25:13 -0800 (PST)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id B43AF3A635F for ; Wed, 27 Jan 2010 14:25:12 -0800 (PST)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 7F77FE60D1 for ; Wed, 27 Jan 2010 22:25:25 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o0RMPKnA039457 for ; Thu, 28 Jan 2010 09:25:22 +1100 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <201001272225.o0RMPKnA039457@drugs.dv.isc.org>
To: "dnsop@ietf.org" 
From: Mark Andrews 
References:  
In-reply-to: Your message of "Wed, 27 Jan 2010 10:59:46 -0800."  
Date: Thu, 28 Jan 2010 09:25:20 +1100
Sender: marka@isc.org
Subject: Re: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 22:25:13 -0000

The DNSKEY RRset size seems small for testing.  We really should
be looking the biggest key set sizes that occur during rollover
simultaneous ZSK/KSK rollovers.  Hopefully that is in the planning.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From stephan.lagerholm@secure64.com  Wed Jan 27 19:09:20 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4B33A691C for ; Wed, 27 Jan 2010 19:09:20 -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 VJB50-WnNIGA for ; Wed, 27 Jan 2010 19:09:19 -0800 (PST)
Received: from mail.secure64.com (mail.secure64.com [66.37.130.20]) by core3.amsl.com (Postfix) with ESMTP id D5DF73A68B6 for ; Wed, 27 Jan 2010 19:09:19 -0800 (PST)
Received: by mail.secure64.com (Postfix, from userid 65534) id 872A8FBE9A20; Wed, 27 Jan 2010 20:09:35 -0700 (MST)
Received: from exchange.secure64.com (exchange.sec64.com [192.168.254.250]) by mail.secure64.com (Postfix) with ESMTP id 25497FBD9698; Wed, 27 Jan 2010 20:09:34 -0700 (MST)
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, 27 Jan 2010 19:58:36 -0700
Message-ID: 
In-Reply-To: <201001272225.o0RMPKnA039457@drugs.dv.isc.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
Thread-Index: Acqfnis8cC0wPXvrSMqO2mvhY65C2gAKJogg
References:  <201001272225.o0RMPKnA039457@drugs.dv.isc.org>
From: "Stephan Lagerholm" 
To: "Mark Andrews" , 
Subject: Re: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 03:09:21 -0000

And a revoked key with flag "385" as the high level design calls for RFC
5011 compatible rollovers.

/S
----------------------------------------------------------------------
Stephan Lagerholm
Senior DNS Architect, M.Sc. ,CISSP
Secure64 Software Corporation, www.secure64.com
Cell: 469-834-3940

> -----Original Message-----
> From: dnsop-bounces@ietf.org [mailto:dnsop-bounces@ietf.org] On Behalf
Of
> Mark Andrews
> Sent: Wednesday, January 27, 2010 11:25 PM
> To: dnsop@ietf.org
> Subject: Re: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
>=20
>=20
> The DNSKEY RRset size seems small for testing.  We really should
> be looking the biggest key set sizes that occur during rollover
> simultaneous ZSK/KSK rollovers.  Hopefully that is in the planning.
>=20
> Mark
>=20
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


From fanf2@hermes.cam.ac.uk  Thu Jan 28 06:26:20 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1F373A67BD for ; Thu, 28 Jan 2010 06:26:20 -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 nhiE3pUgG8Hj for ; Thu, 28 Jan 2010 06:26:19 -0800 (PST)
Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by core3.amsl.com (Postfix) with ESMTP id 229C43A672F for ; Thu, 28 Jan 2010 06:26:18 -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]:45930) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1NaVKO-0006tN-1t (Exim 4.70) (return-path ); Thu, 28 Jan 2010 14:26:36 +0000
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1NaVKO-0000tx-IH (Exim 4.67) (return-path ); Thu, 28 Jan 2010 14:26:36 +0000
Date: Thu, 28 Jan 2010 14:26:36 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Mark Andrews 
In-Reply-To: <201001272225.o0RMPKnA039457@drugs.dv.isc.org>
Message-ID: 
References:  <201001272225.o0RMPKnA039457@drugs.dv.isc.org>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
Cc: "dnsop@ietf.org" 
Subject: Re: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 14:26:20 -0000

On Thu, 28 Jan 2010, Mark Andrews wrote:
>
> The DNSKEY RRset size seems small for testing.  We really should
> be looking the biggest key set sizes that occur during rollover
> simultaneous ZSK/KSK rollovers.  Hopefully that is in the planning.

The key rollover timetable staggers ZSK and KSK rollovers. See page 5 of
http://www.root-dnssec.org/wp-content/uploads/2009/12/draft-icann-dnssec-arch-v1dot2dot1.pdf
However that document is a bit light on emergency procedures.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

From mlarson@verisign.com  Thu Jan 28 08:58:55 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E59C3A6A90 for ; Thu, 28 Jan 2010 08:58:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.587
X-Spam-Level: 
X-Spam-Status: No, score=-8.587 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012, 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 C2NrUk4n1cCE for ; Thu, 28 Jan 2010 08:58:54 -0800 (PST)
Received: from cliffie.verisignlabs.com (mail.verisignlabs.com [65.201.175.9]) by core3.amsl.com (Postfix) with ESMTP id E5C773A6A76 for ; Thu, 28 Jan 2010 08:58:53 -0800 (PST)
Received: from monsoon.verisignlabs.com (scooter.bo.labs.vrsn.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id 8F69218EE3 for ; Thu, 28 Jan 2010 11:59:11 -0500 (EST)
Received: from dul1mcmlarson-l1-2.local (dul1mcmlarson-l1.labs.vrsn.com [10.131.244.26]) by monsoon.verisignlabs.com (Postfix) with ESMTP id 87E4A24227B for ; Thu, 28 Jan 2010 11:59:11 -0500 (EST)
Date: Thu, 28 Jan 2010 11:59:11 -0500
From: Matt Larson 
To: "dnsop@ietf.org" 
Message-ID: <20100128165911.GA20811@dul1mcmlarson-l1-2.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:   <201001272225.o0RMPKnA039457@drugs.dv.isc.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 16:58:55 -0000

On Thu, 28 Jan 2010, Mark Andrews wrote:
> The DNSKEY RRset size seems small for testing.  We really should
> be looking the biggest key set sizes that occur during rollover
> simultaneous ZSK/KSK rollovers.  Hopefully that is in the planning.

The design allows for ZSK rollovers at calendar quarter boundaries and
KSK rollovers in the middle of a quarter, which are intentionally
non-overlapping so that the are never more than three keys in the root
DNSKEY RRset.  (Please see the diagram on page five of
http://www.root-dnssec.org/wp-content/uploads/2009/12/draft-icann-dnssec-arch-v1dot2dot1.pdf,
which Tony already referred to.)

There will be a ZSK rollover at the end of Q1/start of Q2 and a KSK
rollover in the middle of Q2.  But because the signed root currently
being published has deliberately obscured key material, essentially
only the key IDs will change: the DNSKEY RDATA will contain the same
human-readable base64[*], padded to produce the same key ID as the
actual, non-published key.

So there will be periods between now and the anticipated completion of
deployment on July 1 when the root key set will contain two ZSKs and
one KSK, and one ZSK and two KSKs.

On Wed, 27 Jan 2010, Stephan Lagerholm wrote:
> And a revoked key with flag "385" as the high level design calls for RFC
> 5011 compatible rollovers.

The KSK rollover in mid-Q2 will use RFC 5011 semantics, as will every
KSK rollover.  (But since the KSK is 2048 bits, I hope to not see a
rollover of the initial published KSK for a long time.)

On Thu, 28 Jan 2010, Tony Finch wrote:
> The key rollover timetable staggers ZSK and KSK rollovers. See page 5 of
> http://www.root-dnssec.org/wp-content/uploads/2009/12/draft-icann-dnssec-arch-v1dot2dot1.pdf
> However that document is a bit light on emergency procedures.

That's a high-level architecture document and intentionally doesn't
cover every detail.  There is much more detail in the policy and
practice statements (one each for VeriSign and ICANN at
http://www.root-dnssec.org/documentation), including detail about
emergency key rollovers.  Is there something missing, in your opinion?

Matt

[*] $ dig +nocmd +noquestion +nocomments +nostats @l.root-servers.net dnskey .
.                       86400   IN      DNSKEY  256 3 8 AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ +++++++8
.                       86400   IN      DNSKEY  257 3 8 AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++8=

From fanf2@hermes.cam.ac.uk  Thu Jan 28 09:37:39 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F763A6AB3 for ; Thu, 28 Jan 2010 09:37:39 -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 ZXfL7v9lvPhy for ; Thu, 28 Jan 2010 09:37:38 -0800 (PST)
Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by core3.amsl.com (Postfix) with ESMTP id 601B53A6AB0 for ; Thu, 28 Jan 2010 09:37:38 -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]:57685) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1NaYJY-0006Xt-4R (Exim 4.70) (return-path ); Thu, 28 Jan 2010 17:37:56 +0000
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1NaYJY-0006bc-Bl (Exim 4.67) (return-path ); Thu, 28 Jan 2010 17:37:56 +0000
Date: Thu, 28 Jan 2010 17:37:56 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Matt Larson 
In-Reply-To: <20100128165911.GA20811@dul1mcmlarson-l1-2.local>
Message-ID: 
References: <20100128165911.GA20811@dul1mcmlarson-l1-2.local>
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: "dnsop@ietf.org" 
Subject: Re: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 17:37:39 -0000

On Thu, 28 Jan 2010, Matt Larson wrote:
> On Thu, 28 Jan 2010, Tony Finch wrote:
> >
> > http://www.root-dnssec.org/wp-content/uploads/2009/12/draft-icann-dnssec-arch-v1dot2dot1.pdf
> > However that document is a bit light on emergency procedures.
>
> That's a high-level architecture document and intentionally doesn't
> cover every detail.  There is much more detail in the policy and
> practice statements (one each for VeriSign and ICANN at
> http://www.root-dnssec.org/documentation), including detail about
> emergency key rollovers.

Ah that's where I should have been looking, thanks.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

From nweaver@ICSI.Berkeley.EDU  Thu Jan 28 09:41:08 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0804E3A6AB1 for ; Thu, 28 Jan 2010 09:41:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hhogcAzwYqL for ; Thu, 28 Jan 2010 09:41:07 -0800 (PST)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 177A63A6AAD for ; Thu, 28 Jan 2010 09:41:07 -0800 (PST)
Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o0SHfPvC028859; Thu, 28 Jan 2010 09:41:25 -0800 (PST)
References: <20100128165911.GA20811@dul1mcmlarson-l1-2.local>
In-Reply-To: <20100128165911.GA20811@dul1mcmlarson-l1-2.local>
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
Message-Id: <6C5745D7-2529-4FD4-AB71-3A8B8E5E4483@icsi.berkeley.edu>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver 
Date: Thu, 28 Jan 2010 09:41:25 -0800
To: Matt Larson 
X-Mailer: Apple Mail (2.1077)
Cc: "dnsop@ietf.org" , Nicholas Weaver 
Subject: Re: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 17:41:08 -0000

On Jan 28, 2010, at 8:59 AM, Matt Larson wrote:

> On Thu, 28 Jan 2010, Mark Andrews wrote:
>> The DNSKEY RRset size seems small for testing.  We really should
>> be looking the biggest key set sizes that occur during rollover
>> simultaneous ZSK/KSK rollovers.  Hopefully that is in the planning.
>=20
> The design allows for ZSK rollovers at calendar quarter boundaries and
> KSK rollovers in the middle of a quarter, which are intentionally
> non-overlapping so that the are never more than three keys in the root
> DNSKEY RRset.  (Please see the diagram on page five of
> =
http://www.root-dnssec.org/wp-content/uploads/2009/12/draft-icann-dnssec-a=
rch-v1dot2dot1.pdf,
> which Tony already referred to.)
>=20


Stupid question on Figure 2:  What is the approximate size of responses =
during these different periods?  In particular, do any particular "magic =
limits" in the network (namely the 1500B ethernet MTU, the 1492 PPPoE =
MTU, the "likely to be in path MTU hole" of 1480-1500B MTU, or the =
somewhat common 1280 EDNS MTU) get hit?



From bmanning@karoshi.com  Thu Jan 28 13:36:20 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205F83A6969 for ; Thu, 28 Jan 2010 13:36:20 -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 jhLPEppDfXSy for ; Thu, 28 Jan 2010 13:36:19 -0800 (PST)
Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id AF5E43A6804 for ; Thu, 28 Jan 2010 13:36:13 -0800 (PST)
Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com. (8.12.8/8.12.8) with ESMTP id o0PJwTf9026587;  Mon, 25 Jan 2010 19:58:29 GMT
Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o0PJwO32026584; Mon, 25 Jan 2010 19:58:24 GMT
Date: Mon, 25 Jan 2010 19:58:24 +0000
From: bmanning@vacation.karoshi.com
To: Paul Hoffman 
Message-ID: <20100125195824.GA26539@vacation.karoshi.com.>
References: <201001251832.o0PIW4iv083151@givry.fdupont.fr> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.1i
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 21:36:20 -0000

	thanks paul.  

> 
> That might be draft-hoffman-dnssec-ecdsa. I let it expire earlier this month because the DNSEXT WG is still not clear on the allowable statuses for crypto documents, but have today revived it based on your comment.
> 
> If you don't consider this to be "a good draft", I am quite open to suggestions for improvement!
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

From bmanning@karoshi.com  Thu Jan 28 13:36:20 2010
Return-Path: 
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA463A6804 for ; Thu, 28 Jan 2010 13:36:20 -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 zHBBhcdUvUrt for ; Thu, 28 Jan 2010 13:36:19 -0800 (PST)
Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 91B483A68A9 for ; Thu, 28 Jan 2010 13:36:19 -0800 (PST)
Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com. (8.12.8/8.12.8) with ESMTP id o0O4UCf9010938;  Sun, 24 Jan 2010 04:30:12 GMT
Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o0O4U1bw010936; Sun, 24 Jan 2010 04:30:01 GMT
Date: Sun, 24 Jan 2010 04:30:01 +0000
From: bmanning@vacation.karoshi.com
To: Matt Larson 
Message-ID: <20100124043001.GC4231@vacation.karoshi.com.>
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl>  <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> <24C8A8E2A81760E31D4CDE4A@Ximines.local>    <20100124010017.GJ35464@sirocco.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100124010017.GJ35464@sirocco.local>
User-Agent: Mutt/1.4.1i
Cc: dnsop WG 
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 21:36:20 -0000

On Sat, Jan 23, 2010 at 08:00:17PM -0500, Matt Larson wrote:
> On Fri, 22 Jan 2010, Paul Wouters wrote:
> > On Fri, 22 Jan 2010, Alex Bligh wrote:
> >> I meant computational resource requirements resultant from crypto
> >> operations, not algorithmic complexity.
> >
> > I had no problems doing this on a 1.2M domains TLD zone, using off the
> > shelf hardware, integrating into the TLD's hourly update interval.
> > (http://www.cira.ca/dnssec/)
> 
> Try 100M delegations, updated every 15 seconds, and sending the
> resulting large non-Opt-out zone to places with poor connectivity such
> as Nairobi, Kenya.
> 
> Arguments such as "I did it on once on commodity hardware with freely
> available tools" or "you can implement that in an afternoon" do not
> transfer well to large, critically important TLDs (or any large-scale,
> critical service).
> 
> Matt

	to be honest, there are a few more delegation points that fit the
	1.xM domains using cots technology than there are delegations that
	have delegations with 100M+ entries and running dynamic udates.

	on more than one occasion (perhaps first at the IETF in SLC) I have
	heard folks who would like the business model of such a delegation 
	refer to it as "a goiter on the neck of the DNS" in envy.

--bill