From ogud@ogud.com Wed Aug 1 15:51:15 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC50411E811E for ; Wed, 1 Aug 2012 15:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0HS8BCEZgzi for ; Wed, 1 Aug 2012 15:51:15 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9EA11E80FD for ; Wed, 1 Aug 2012 15:51:14 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q71MpBd4075922; Wed, 1 Aug 2012 18:51:11 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <5019B2DC.1090806@ogud.com> Date: Wed, 01 Aug 2012 18:51:08 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Matthijs Mekking References: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> <500E8CAC.6080206@nlnetlabs.nl> In-Reply-To: <500E8CAC.6080206@nlnetlabs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:51:16 -0000 On 24/07/2012 07:53, Matthijs Mekking wrote: General comment: this is an improvement. some comments and suggestions below The "state" of the key frequently depends on the viewpoint, for example zone may have key in active state but due to propagation delay some validators may think the key is Published state. During transition there different "participants" are in different states. (I will ignore the case that a validator may have RRsets from different versions of a zone and thus for RRset A and RRset B the key states may be different). The goal of the document is to document this and tell people how long it takes until all "participants" consider the key to be in the same state. > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Stephen asked me to send this suggestion we had (surfaced from > discussions) to the list. We would like to have input before the > upcoming IETF meeting. > > Modification to the key states > ============================== > > As you might know, I had this idea of unraveling key states. Instead > of having states that describe the overall state of the key, we would > have states for components of the key. How to divide the key into > components is based on the parts that can be published: > > - - DNSKEY > - - DS > - - RRSIG Is this "RRSIG" in zone generated by the key ? > - - RRSIG DNSKEY Why is this needed ? Key has either RRSIG or not there, the role of the KEY dictates what it signs. > > We can call this the representation of the key (which components are > visible in the zone and/or caches). The RRSIG for zone contents and > for the DNSKEY RRset need specifically be split to support a Single > Type Singing Key in a later stadium. > > Each component follows a certain publication path. Initially it is > Hidden, it will be Introduced into the zone, it is long enough in the > zone to be Propagated to all caches, it will be Withdrawn from the > zone and it will become Hidden again (as it has expired from caches): > > Hidden --> Introduced --> Propagated --> Withdrawn --> Hidden. (this is I think we should include paths for Revoked keys (RFC5011) H --> I --> P --> W --> H | | ^ V V | + --> + --------> R Or the three different paths: H --> I --> P --> W --> H H --> I --> R --> H H --> I --> P --> R --> H > > (Note: a component could be removed from the zone before it was > propagated, so a transition between Introduced and Withdrawn. The > other way around is also true: A record can be reintroduced before it > had expired from all the caches. The idea is to consider full > rollovers only, so these transitions will be out of scope.) > > The overall key states from draft-ietf-dnsop-dnssec-key-timing-03.txt > map (but not one-to-one) to the unraveled key states: > > For example, for ZSK Rollovers: > > Generated -> (DNSKEY Hidden, RRSIG Hidden) > Published -> (DNSKEY Published, RRSIG Hidden) [Pre-publish] > -> (DNSKEY Hidden, RRSIG Published) [Double-RRSIG] > Ready -> (DNSKEY Propagated, RRSIG Hidden) [Pre-publish] > -> (DNSKEY Hidden, RRSIG Propagated) [Double-RRSIG] > Active -> (DNSKEY Propagated, RRSIG Introduced) [Pre-publish] > -> (DNSKEY Introduced, RRSIG Propagated) [Double-RRSIG] > -> (DNSKEY Introduced, RRSIG Introduced) [Double-Signature] > Retired -> (DNSKEY Propagated, RRSIG Withdrawn) [Pre-publish] > -> (DNSKEY Withdrawn, RRSIG Propagated) [Double-RRSIG] > -> (DNSKEY Propagated, RRSIG Propagated) [Double-Signature] > Dead -> (DNSKEY Propagated, RRSIG Hidden) [Pre-publish] > -> (DNSKEY Hidden, RRSIG Propagated) [Double-RRSIG] > -> (DNSKEY Propagated, RRSIG Propagated) [Double-Signature] > Removed -> (DNSKEY Withdrawn, RRSIG Hidden) [Pre-Publish] > -> (DNSKEY Hidden, RRSIG Withdrawn) [Double-RRSIG] > -> (DNSKEY Withdrawn, RRSIG Withdrawn) [Double-Signature] > An alternative way to present this to include the delay until next state can be entered. Below I have rewritten part of the representation above to include the precondition for entering the next state - Delay: how long to wait for the data to propagate - Action needed be taken to move to the next state. DNSKEY --- RRSIG ---- Delay/Action - APPROACH Published --> Introduced - Hidden - DNSKEY TTL = [Pre-Publish] --> Hidden - Introduced - MAX TTL = [Double-RRSIG] Ready --> Propagated - Hidden - Action X = [Pre-Publish] --> Hidden - Propagated - Action Y = [Double-RRSIG] Action X = Sign zone with key Action Y = replace the old key with the new one. Rather than have a table like this I would prefer to have the state machine for each approach. > (I leave the KSK rollovers as an exercise to the reader ;-) ) > > So you see, the key states as they are now do not map uniquely to how > the key is presented in the zone. I want to propose that either the > document uses the unraveled key states, or otherwise defines a unique > mapping between the overall key states and the representation of the key. > > Also, we should not limit to one key state at a time. For example, a > key can be Published and Active at the same time in my opinion. > - From -03: > > Published The DNSKEY record - or information associated with it - > is published in the zone, but predecessors of the key (or > associated information) may be held in caches. > > Active The key has started to be used to sign RRsets. Note that > when this state is entered, it may not be possible for > validating resolvers to use the key for validation in all > cases: the zone signing may not have finished, or the > data might not have reached the resolver because of > propagation delays and/or caching issues. If this is the > case, the resolver will have to rely on the key's > predecessor instead. > > But both descriptions may be valid at the same point in time. So I > would like to say the key can be Published and Active at the same time. > > Finally, I would like to drop "associated information". To keep a > clear definition, a key state should only say something about one key > component. So, the definition for Published would become: > > Published The DNSKEY record is published in the zone, but > predecessors of the key (or associated information) may > be held in caches. > > or even more simpler: > > Published The DNSKEY record is published in the zone. > > So, you would get more states, but with simpler descriptions. > > > To summarize: > > 1. Use unraveled key states or define a unique mapping between the > overall key states and the representation of the key. > > 2. A key can have more than one state at a time. > > 3. Drop "associated information", a key state only says something > about one key component. > > > Thoughts? > I like this and think the document should adopt this notation as it is much easier to express and understand. Olafur > Best regards, > Matthijs > > > On 07/09/2012 07:13 PM, Stephen Morris wrote: >> After much delay, the -03 version of the key timing draft has been >> submitted. It incorporates a number of comments made on-list and >> privately: many thanks to Mark Lampo, Matthijs Mekking and Alfred >> Hoenes. >> >> Perhaps the most significant change concerns the timing >> considerations related to the introduction of a new KSK (section >> 3.3.4.1). >> >> Stephen >> >> From sa.morris7@googlemail.com Thu Aug 9 04:17:48 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665AF21F86CA for ; Thu, 9 Aug 2012 04:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNpeDMQr8afG for ; Thu, 9 Aug 2012 04:17:46 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED3D21F86C9 for ; Thu, 9 Aug 2012 04:17:46 -0700 (PDT) Received: by eekb45 with SMTP id b45so109889eek.31 for ; Thu, 09 Aug 2012 04:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer; bh=q4+/CDI1wXeA1391gkB/fZQsGtm/4j4Og7zw1BIedYM=; b=x6NuGzu9THlpRrkWL08zBd4ydS0qvaY8FubUBjsLXYRzxCnkeA3vqlFxVIdFdIFIX/ NVgiw191x5yRkhdl9PAlaDMAlz+u7sMWIoNbv1ARAN5i0iWWpZS7XA0qPa9WhrGOyNcH iOPwnItNHgN+NvDefISedbpuxllPXGB3+zGYhj92bIiSDP5ZfE/fqUVlLBb1AXrzAUxl cKoKM+6DGtDLMq1NnZBu5vjLMmGbM7yeFKXHwsrEguLYnjdu8ol9eBHPfpOSxhUQcUC1 0MeMfbJfjQohd1+nAbo/ww9Go8tzYV2YKiwv7ZNTXcCzyq2Pu8L6rErg1m6f1aBo+hSw y91w== Received: by 10.14.210.194 with SMTP id u42mr27185685eeo.11.1344511065642; Thu, 09 Aug 2012 04:17:45 -0700 (PDT) Received: from [192.168.1.101] ([217.155.47.50]) by mx.google.com with ESMTPS id g46sm2609437eep.15.2012.08.09.04.17.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Aug 2012 04:17:44 -0700 (PDT) From: Stephen Morris Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Aug 2012 12:17:41 +0100 To: dnsop@ietf.org Message-Id: <7C82E526-2A7D-466D-B2C1-49AB350FBCE7@googlemail.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [DNSOP] Minutes from IETF 84 DNSOP Meeting X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 11:17:48 -0000 The minutes from the WG meeting last week in Vancouver are here for review; they have also been uploaded to the meeting materials page. Please advise the chairs of any errors or omissions. Stephen =3D=3D=3D=3D WG: DNS Operations (dnsop) Meeting: IETF 84, Vancouver Location: Hyatt Regency Vancouver, Georgia B Date: Thursday, 02 August 2012 Time: 17:30 - 18:30 (UTC-07:00) Chairs: Peter Koch Stephen Morris Jabber Log: (Times in brackets are times on the audio record: http://www.ietf.org/audio/ietf84/ietf84-georgiab-20120802-1730-pm3.mp3) 0) Introduction [0:00] 1) Administrivia [0:40] Minute Taker: Alexander Mayerhofer Jabber Scribes: Andy Newton, Patrik Wallstrom 2) Status Update (drafts not mentioned in "Active Drafts") [3:20] draft-ietf-dnsop-respsize: This should go to the IESG really soon. It has already had several last calls, so another nits review will be done, then the proto write-up created and posted to the list for a week or two (instead of doing another last call). After this it will be sent to the AD. 3) Active Drafts 3.1) [5:00] This is finally off the chairs' plate - there have been a couple of revisions since WG last call. It is currently awaiting AD evaluation and IETF last call (the chairs are expecting comments from broader community). Some typos have already been found, and these will be corrected after IETF last call. 3.2) [5:40] IETF last call finished on 17 July, and was discussed at IESG meeting on 18 July. There were three DISCUSSes: one concerned copyright permission and has been cleared. The second concerns communication of a change of DNSSEC policy (with a related comment about PKI comparison): the intention is to make some changes to clear this. The third comprises three questions about: agreements with relying parties, trust anchor distribution, and description of algorithm rollovers: it is hoped these can be cleared in discussion with the relevant AD. The chairs are in discussion with the editors on these and hope to clear them with the ADs. Significant changes will be posted to list: if no objections, a -09 version will be submitted. 3.3) Next steps in Key Timing (Stephen Morris) [8:00] = The document got resurrected after about a year. KSK timings (related to RFC 5011) were modified and a minor change made to the section on first keys in a zone. A number of other nits were corrected. In Quebec = (IETF-81) there was a feeling that the document should be published. In light of the long delay between versions, and that the -bis version of Matthijs has found some favour on the list, is that still the feeling of the WG? About 15 people have read the document. Matthijs Mekking: Important to continue the work on the base document, but do that quickly. Don't want to wait another year. John Dickinson: As one of the authors of the original draft, please get it published. Andrew Sullivan: Remembers we said quick decision at last meeting. Ship it or kill it, but make a decision. Paul Hoffman: Kill it. Will be the wrong message to the community = sending out two documents. Operators will implement this, and later be surprised by the change. Kill it and have the -bis document include everything. Matthijs Mekking: Yep, agree, same question again. Stephen Morris: Is the -bis document based on your experience of implementation? Matthijs Mekking: This document is not flexible enough, this is the experience, eg. when going from signed to unsigned. To sum up, yes. Andrew Sullivan: Don't personally care whether we ship it or not, but make a decision! People out there are waiting for information, and we will give out information that changes, but this is better than nothing. Bill Manning: Perfect is the enemy of the good. Ship it now, at least we have some information out. By the time -bis is ready, something will have changed. If not, kill it. Ship it, but do not stop work on the -bis. If we can get it out quickly, do it. Peter Koch: Heard interesting different things. Are there strong issues with the *current* document? No hands. Putting the question in another way: how many think it is ready for last call? About ten-ish. Who thinks it is not? No-one. Conclusion: WGLC will be issued soon. Question from Jabber: When issued? Definitely before Atlanta! 4) Other (non WG) Internet-Drafts 4.1) Omniscient AS112 Servers (Warren Kumari) [19:35] = Warren Kumari described what AS112 is for - a distributed sink of = Anycast servers to answer e.g. RFC 1918 space PTR queries. How will new space be added to AS112? Just send AS112 operators new zone file. However, the AS112 project is really a loose collaboration, many operators unknown. Some enterprises have local AS112 nodes not announced externally. Also cases where contact information is out of = date. Omniscient AS112 servers - are authoritative for everything ("."), but know nothing. They comprise an empty zone with SOA and NS records shown. Will authoritatively answer "does not exist" for everything. To add new space to AS112, just delegate the space to them. Main question: should the server be authoritative for "." or ".arpa"? [27:43] Mark Andrews: Examples have AA flag set. Please re-check through recursive servers with local zones turned off - will not work. named does sanity checks on SOA record. Warren Kumari: Original propose was to synthesise answers on the file. Will recheck with BIND. George Michaelson: This is not the last AS112 draft, just the last draft about how to do it. Delegating and undelegating requires a formalism. This proposal makes a lot of sense. Peter Koch: Do you have an opinion on the "." SOA record? George Michelson: Am confused about what happens if someone is directed to one of these servers. Absolutely sure there are no side effects? Warren Kumari: Absolutely sure there are side effects. Bill Manning: Looks hauntingly familiar. It might also work if doing a wildcard in the existing root (laughter) Serious question: If you are authoritative for the root, two questions: how is this different from people running their own root, and are you going to sign it? Warren Kumari: Not going to sign it. For other question, not hugely different, but different motivation. Ondrej Sury: Different, because there are delegations to those servers. Not pretending you are root. Lars Johan Liman: If you are going to be authoritative for the root, why lie? Why not put the true root zone there? Warren Kumari: Because you are just trying to serve an NXDOMAIN. Lars Johan Liman: Problem is that NS records could be cached. Respond with the real root zone instead! Also, this plays into hands of people who want to fiddle with domain names, e.g. requests from law enforcement who want names removed: perfect infrastructure for it. Warren Kumari: Answer to second point is that if you can delegate to these, you can remove the zone. Questions: a) is it worh progressing, possibly synthesising responses b) adopt this document? Peter Koch: Significant issues raised, please continue the discussion, adoption would be premature. 4.2) Child-Parent DNSSEC Key Exchange (Paul Wouters) [38:00] = (Peter Koch: Introduction - Paul Wouters volunteered to write use cases following a couple of rounds on this and other mailing list where people came up with ideas for substituting/exectinging provisioning stream for key material.) Use cases. Can we use DNSSEC to solve problems we had before but could not address because we did not have authentication? This is not about replacing dynamic updates in any way. Have assumed that the target RRTYpes are DS/NS/glue. Trying to take into account various = relationships between parent and child. Hope that we can parallelize use cases and specification at the same time. Peter Koch: How many read the draft? 10-15? Andrew Sullivan: Have read, appreciate the work, perfectly good as a starting point for WG. Support adopting it. Parallelizing the work (doing requirements and implementation) is a bad idea. We should try to get this done pretty quickly, would like to see the WG working on this. Mark Andrews: DNSSEC is a catalyst, definitely work we need to do. Johan Ihren: Have implemented this sort of thing before, and it works. Not clear this is a DNS issue: although data goes in-band, need = triggering mechanism outside of DNS. Antoin Verschuren: Remember starting this, was enthusiastic back then. Needs and external authentication mechanism to bootstrap, therefore always two mechanisms in place - needs to be clear in the document. Question about adoption, especially by ICANN and registrars. Paul Wouters: Further down the tree there is no registry etc. involved, and we want to automate things there. Paul Hoffman: Johan - are you OK with limiting the use cases to = *finding* the trigger in the DNS? If use case is everthing in DNS, is that OK? Johan Ihren: Seeing problems, but very much in favor of progressing = this! Question of automating *lots* of delegations further down the tree - costs can be minimised. Paul Hoffman: Very much in favour of work being done. Patrik Wallstrom: We are so bound by policies, we cannot possibly bypass the registrars, cannot see how registrars will be involved in this WG. Registrars need encouragement to do it. Olafur Gudmunsson: Nothing to stop registrars vetting data. Patrik Wallstrom: Problem with separation of registries and registrant. Olafur Gudmunsson: But data is in the DNS, added by registrar, this is just another mechanism to passing it through. Johan Ihren: Nothing to prevent parent discovery, very difficult to work out how do that notification in-band. Peter Koch: Devoting time and energy of WG participants means there = needs to be chance of deployment. Need to discuss this further on the list. Can we frame the problem such that any solution is used beyond "DNS geeks"? How big is the target audience? Andrew Sullivan: People who paid for me to come here want this, not only for registry/registrar operations. Peter Koch: Conclusion: Take this to list, please. Seriously. Have to continue framing discussion there and collect input, then make a determination - *before* Atlanta. Matthijs Mekking: If people in the room want to adopt the document, why do we have the question? Peter Koch: "Price Tag" is in the commitment for the document. Even though we adopt documents, we have a hard time getting input and quality reviews. Wes Hardaker: "I use the Internet" - What's frequently broken is the parent/child relationship, worse with DNSSEC. This will be a god-send in synchronizing the data! Promise to read and review the document. Problem is there and needs to be fixed. 6) A.O.B. DNS operational/counter data collection (Simon Perreault) [57:35] DNS statistics collection: TLD operator who has third-party anycasts and wants per-node statistics. Proposed is MIBs - simple read-only counters based on BIND9 statistics (that's what's in the draft). Simple goal - expose usage statistics over SMTP - don't want to configure or control = it. MIB was simple to write. John Dickinson: Never heard anyone say MIBs are easy to write. Are alternative ways, e.g. NETCONF, which has advantages such as role-based access control. Peter Koch: How many people have read this? Five-ish. Two questions: a) = is the problem worth exploring and then b) are MIBs the right way? = Recommend abstract the problem from the MIB solution. Lars Johan Liman: Idea of a DNS MIB is not new, it's been around at = least once (or twice?). Compare with previous attempts? Should not preclude other access methods to access the data. 5) I/O with other WGs [1:04:35] Peter Koch: Please look at the other WGs eg. HOMENET. Actions =3D=3D=3D=3D=3D=3D=3D 1) [ALL] Respond to change suggestions for the DPS framework once they = hit the list. IESG comments can be found at: = 2) [Peter] NITS review and PROTO writeup for 3) [Peter] Issue WGLC for 4) [Chairs] Frame discussion around the child/parent interaction on mailing list 5) [Chairs] Stipulate discussion on the issue of stats collection (problem vs MIB or other solution) (Version: 2012-08-09 09:23) From matthijs@nlnetlabs.nl Thu Aug 9 05:02:47 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F129321F8634 for ; Thu, 9 Aug 2012 05:02:46 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmeN2PDijZIE for ; Thu, 9 Aug 2012 05:02:46 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C132D21F8628 for ; Thu, 9 Aug 2012 05:02:45 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:78ea:e8b0:9eb5:2ce8] ([IPv6:2001:7b8:206:1:78ea:e8b0:9eb5:2ce8]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q79C2erp062143 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 14:02:41 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.5.2 open.nlnetlabs.nl q79C2erp062143 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1344513761; bh=s/NZ4d0SiXgIDBTGVyZWyVsO5r7wI2ICcQ35tkHzJZk=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=HCyIz+O48TGqgufEuI4uSHC3Ta2nR+qekX2ylrmEcZQxJYdSx7zKXg5jVjRFODEni zerhiYyyJY6TBtSwnsARlfPnvQtIHAx9r8SXDF9HH83xoWRpjjSDBIWhg/9IBT6kBN OcTRYi/uubWKrdnnDtfuNVo7mf9+h5XmsuoQgPG0= Message-ID: <5023A6E1.50403@nlnetlabs.nl> Date: Thu, 09 Aug 2012 14:02:41 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Stephen Morris References: <7C82E526-2A7D-466D-B2C1-49AB350FBCE7@googlemail.com> In-Reply-To: <7C82E526-2A7D-466D-B2C1-49AB350FBCE7@googlemail.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 09 Aug 2012 14:02:41 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Minutes from IETF 84 DNSOP Meeting X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 12:02:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/09/2012 01:17 PM, Stephen Morris wrote: > Paul Hoffman: Kill it. Will be the wrong message to the community > sending out two documents. Operators will implement this, and later > be surprised by the change. Kill it and have the -bis document > include everything. > > Matthijs Mekking: Yep, agree, same question again. That was not what I was trying to say. I was neither in favor nor against killing it. I just want to prevent another long delay with regard to the topic on key timing. > > Stephen Morris: Is the -bis document based on your experience of > implementation? > > Matthijs Mekking: This document is not flexible enough, this is > the experience, eg. when going from signed to unsigned. To sum up, > yes. And more importantly: algorithm rollover and rollovers in single type signing scheme. > Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQI6bhAAoJEA8yVCPsQCW5R24H+wcxndie3Wm/NPbx08NESwim ai9sxRVJIXv2/4cjcj0vxHt3f4AJy759W1yeN6ENMVFy3H1YK2tnZGtWjV35WyG0 PccrnXPosbxOjpjX1nkfAef0IEV/96yxP3JvOgwPc4Z1dW+61uptPA5/4RPuTmxg YA8TUxL+3S4aCjRI0y8XPZKDyac683ghsvQsCtalZUh40ku/zVxkx+M++6CR6+ba tpnAvrEH6o0AszU6P2nVre2I2zQI/2Cm3d3IolqjuO7uXBrWhcy2laBLvRT+0yxO LfeEeEWCXRJAiKZrXU6eVq1pMuGM3AVt9wCfr9rE+VYdIZaKeoI04xq0kaN76QM= =cNyO -----END PGP SIGNATURE----- From iesg-secretary@ietf.org Fri Aug 10 08:00:05 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BFF21F867F; Fri, 10 Aug 2012 08:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjU4z5TSUVeB; Fri, 10 Aug 2012 08:00:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7405D21F861D; Fri, 10 Aug 2012 08:00:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120810150004.26411.79261.idtracker@ietfa.amsl.com> Date: Fri, 10 Aug 2012 08:00:04 -0700 Cc: dnsop@ietf.org Subject: [DNSOP] Last Call: (DNSSEC Operational Practices, Version 2) to Informational RFC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 15:00:05 -0000 The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNSSEC Operational Practices, Version 2' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc4641bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc4641bis/ballot/ No IPR declarations have been submitted directly on this I-D. From yuri@nlnetlabs.nl Tue Aug 14 01:54:38 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD59121F861E for ; Tue, 14 Aug 2012 01:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.741 X-Spam-Level: X-Spam-Status: No, score=-100.741 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26gwTEOPW4ib for ; Tue, 14 Aug 2012 01:54:38 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B00A921F861D for ; Tue, 14 Aug 2012 01:54:37 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:21c:c0ff:fe11:b9b8] (pan.nlnetlabs.nl [IPv6:2001:7b8:206:1:21c:c0ff:fe11:b9b8]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q7E8sXXE079886 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 14 Aug 2012 10:54:34 +0200 (CEST) (envelope-from yuri@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.5.2 open.nlnetlabs.nl q7E8sXXE079886 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1344934474; bh=hDakzNbH9DTNaPcAuxRskNymw+7ShvTP2x49t1LDFns=; h=Date:From:To:Subject:References:In-Reply-To; b=IsK+5rRyu/BTgL+dKLR4DdZTkax+qIFn+3PGwzdi4OTpGS2NV7QTnm0EmtCRoc/q6 n4KhscHnu0e7tlozYVfPSGgZmCW3SiuxhFixuCXby3nYnbg3bx1bOGAqSiwKUe8GCb +dF2Lzgt3p8TPUenZjMu28mqIGWTLdvOu+Ibvv9Q= Message-ID: <502A124B.8070003@nlnetlabs.nl> Date: Tue, 14 Aug 2012 10:54:35 +0200 From: Yuri Schaeffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: dnsop@ietf.org References: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> In-Reply-To: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 14 Aug 2012 10:54:34 +0200 (CEST) Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 08:54:38 -0000 I reviewed the "DNSSEC Key Timing Considerations draft-ietf-dnsop-dnssec-key-timing-03.txt" document rather extensively with emphasis on verifying correctness of the rollover timelines. I believe these are correct. A remark: 4. Standby Keys, paragraph 6: "Finally, in the Double-DS method of rolling a KSK, it is not a standby key that is present, it is a standby DS record in the parent zone." Saying this does not count as a 'standby key' is confusing in the light that the term key is used rather loosely. Also this text insinuates that it is somehow worse than having a "Double-Signature standby key" but fails to mention why. Another remark. I guess this is not up for debate at this point but it really bothers me: 2.3: Table 1. I don't like the names at all. It is confusing and inconsistent. KSK Double-Signature would in my opinion be better of called Double-DNSKEY. ZSK Double-Signature means: "do everything at once" whilst KSK Double-Signature means "do it staged". Similar to make it make consistent I would either cal ZSK Pre-Publication Double-DNSKEY or KSK Double-DS Pre-Publication. Perhaps: +------------------+------------------+-----------------------------+ | ZSK Method | KSK Method | Description | +------------------+------------------+-----------------------------+ | Double-DNSKEY | - | Publish the DNSKEY before | | | | the RRSIGs. | | Double-RRSIG | - | Publish RRSIGs before the | | | | DNSKEY. | | Double-ZSK | - | Publish the DNSKEY and | | | | RRSIGs at same time. | | - | Double-DNSKEY | Publish the DNSKEY before | | | | The DS. | | - | Double-DS | Publish DS before the | | | | DNSKEY. | | - | Double-KSK | Publish DNSKEY and DS in | | | | parallel. | +------------------+------------------+-----------------------------+ Regards, Yuri Schaeffer From ajs@anvilwalrusden.com Wed Aug 15 18:53:05 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7FC11E80DB for ; Wed, 15 Aug 2012 18:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpV+PewS4y6f for ; Wed, 15 Aug 2012 18:53:04 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id A316821F84F5 for ; Wed, 15 Aug 2012 18:53:04 -0700 (PDT) Received: from mx1.yitter.info (ip-64-134-67-129.public.wayport.net [64.134.67.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 91D2E8A031 for ; Thu, 16 Aug 2012 01:53:02 +0000 (UTC) Date: Wed, 15 Aug 2012 21:53:00 -0400 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20120816015259.GB18687@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [DNSOP] draft-ietf-dnsop-dnssec-key-timing X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 01:53:05 -0000 Dear colleagues, In Vancouver, according to the DNSOP minutes, participants were to expect a WGLC "soon" on the subject Internet Draft. In the archives since the meeting, I observe some comments at http://www.ietf.org/mail-archive/web/dnsop/current/msg09783.html. But I do not observe the announcement of a WGLC. I am wondering when we might expect that call. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From jad@sinodun.com Mon Aug 20 04:51:07 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B01A21F85A3 for ; Mon, 20 Aug 2012 04:51:07 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osgYi-BvQKXg for ; Mon, 20 Aug 2012 04:51:05 -0700 (PDT) Received: from cpanelsmarthost1.zen.co.uk (cpanelsmarthost1.zen.co.uk [82.71.204.225]) by ietfa.amsl.com (Postfix) with ESMTP id A20B721F862B for ; Mon, 20 Aug 2012 04:50:59 -0700 (PDT) Received: from [88.98.24.67] (helo=shcp01.hosting.zen.net.uk) by cpanelsmarthost1.zen.co.uk with esmtp (Exim 4.72) (envelope-from ) id 1T3QVQ-0005CU-1m for dnsop@ietf.org; Mon, 20 Aug 2012 11:50:52 +0000 Received: from [86.12.159.228] (port=1609 helo=[192.168.1.23]) by shcp01.hosting.zen.net.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1T3QVG-0006T7-1V; Mon, 20 Aug 2012 12:50:42 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: John Dickinson In-Reply-To: <502A124B.8070003@nlnetlabs.nl> Date: Mon, 20 Aug 2012 12:50:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> <502A124B.8070003@nlnetlabs.nl> To: Yuri Schaeffer X-Mailer: Apple Mail (2.1485) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sinodun.com Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 11:51:07 -0000 Yuri, Thanks for the feedback. On 14 Aug 2012, at 09:54, Yuri Schaeffer wrote: > I reviewed the "DNSSEC Key Timing Considerations > draft-ietf-dnsop-dnssec-key-timing-03.txt" document rather extensively > with emphasis on verifying correctness of the rollover timelines. I > believe these are correct. >=20 > A remark: >=20 > 4. Standby Keys, paragraph 6: "Finally, in the Double-DS method of > rolling a KSK, it is not a standby key that is present, it is a = standby > DS record in the parent zone." >=20 > Saying this does not count as a 'standby key' is confusing in the > light that the term key is used rather loosely. Also this text > insinuates that it is somehow worse than having a "Double-Signature > standby key" but fails to mention why. I am reluctant to make changes to the wording at this stage. However, if = the WG feel strongly enough then I suggest that we could either remove = the words "it is not a standby key that is present," or change the = wording to say "the standby key is not published in the zone, rather it = is the DS RR derived from the standby key that is published in the = parent zone.". I do not see how the wording insinuates that it is somehow worse than = having a "Double-Signature standby key". >=20 > Another remark. I guess this is not up for debate at this point but it > really bothers me: >=20 > 2.3: Table 1. I don't like the names at all. It is confusing and > inconsistent. KSK Double-Signature would in my opinion be better of > called Double-DNSKEY. ZSK Double-Signature means: "do everything at > once" whilst KSK Double-Signature means "do it staged". Similar to = make > it make consistent I would either cal ZSK Pre-Publication = Double-DNSKEY > or KSK Double-DS Pre-Publication. Perhaps: >=20 > +------------------+------------------+-----------------------------+ > | ZSK Method | KSK Method | Description | > +------------------+------------------+-----------------------------+ > | Double-DNSKEY | - | Publish the DNSKEY before | > | | | the RRSIGs. | > | Double-RRSIG | - | Publish RRSIGs before the | > | | | DNSKEY. | > | Double-ZSK | - | Publish the DNSKEY and | > | | | RRSIGs at same time. | > | - | Double-DNSKEY | Publish the DNSKEY before | > | | | The DS. | > | - | Double-DS | Publish DS before the | > | | | DNSKEY. | > | - | Double-KSK | Publish DNSKEY and DS in | > | | | parallel. | > +------------------+------------------+-----------------------------+ Yes, I guess this table could be clarified, but again I am reluctant to = make changes to the naming at this stage, especially as this would = require changing the names throughout the document. We could rearrange = the table to tidy up the description of the Double-Signature method but = keep the existing names. Would that help? regards John --- jad@sinodun.com http://sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From peter@denic.de Mon Aug 20 05:46:12 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F6A21F862A for ; Mon, 20 Aug 2012 05:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiIT58Z1XE51 for ; Mon, 20 Aug 2012 05:46:12 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id D89B621F8618 for ; Mon, 20 Aug 2012 05:46:11 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1T3RMv-00043o-MQ; Mon, 20 Aug 2012 14:46:09 +0200 Received: from localhost by x27.adm.denic.de with local id 1T3RMv-0003EF-IY; Mon, 20 Aug 2012 14:46:09 +0200 Date: Mon, 20 Aug 2012 14:46:09 +0200 From: Peter Koch To: dnsop@ietf.org Message-ID: <20120820124609.GB19035@x28.adm.denic.de> References: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> <502A124B.8070003@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 12:46:12 -0000 John, all, On Mon, Aug 20, 2012 at 12:50:55PM +0100, John Dickinson wrote: > > Saying this does not count as a 'standby key' is confusing in the > > light that the term key is used rather loosely. Also this text > > insinuates that it is somehow worse than having a "Double-Signature > > standby key" but fails to mention why. > > I am reluctant to make changes to the wording at this stage. with co-chair and shepherd hat on I must say there is no 'stage' of the document that would discourage or prevent clarifications if members of the WG feel the need. Personally (i.e., no hats) I must say I am not sure I understand what message this paragraph is trying to convey: if it is that the key cannot be used right away because it needs to become active first, then maybe that could or should be made more explicit. > > +------------------+------------------+-----------------------------+ > > | ZSK Method | KSK Method | Description | > > +------------------+------------------+-----------------------------+ > > | Double-DNSKEY | - | Publish the DNSKEY before | > > | | | the RRSIGs. | > > | Double-RRSIG | - | Publish RRSIGs before the | > > | | | DNSKEY. | > > | Double-ZSK | - | Publish the DNSKEY and | > > | | | RRSIGs at same time. | > > | - | Double-DNSKEY | Publish the DNSKEY before | > > | | | The DS. | > > | - | Double-DS | Publish DS before the | > > | | | DNSKEY. | > > | - | Double-KSK | Publish DNSKEY and DS in | > > | | | parallel. | > > +------------------+------------------+-----------------------------+ > > Yes, I guess this table could be clarified, but again I am reluctant to make changes to the naming at this stage, especially as this would require changing the names throughout the document. We could rearrange the table to tidy up the description of the Double-Signature method but keep the existing names. Would that help? And again (hat++), the stage is not a reason to refuse change, especially given that this has not been discussed before as far as I remember. However, this is a WG document and apart from editorial changes and obvious errors, (significant) changes do need WG consensus - and i have seen no support so far. What we need to keep in mind here, though, is internal document consistency as well as consistency with other WG documents, nost notably RFC 4641 and 4641bis as well as established operational convention (as opposed to, just for completeness sake, sloppy language or marketing blurb). -Peter From yuri@nlnetlabs.nl Mon Aug 20 06:03:46 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9796221F861C for ; Mon, 20 Aug 2012 06:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.671 X-Spam-Level: X-Spam-Status: No, score=-101.671 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qbv6Uf7jgkmU for ; Mon, 20 Aug 2012 06:03:46 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EBF21F8613 for ; Mon, 20 Aug 2012 06:03:45 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:21c:c0ff:fe11:b9b8] (pan.nlnetlabs.nl [IPv6:2001:7b8:206:1:21c:c0ff:fe11:b9b8]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q7KD3e6D070073 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 Aug 2012 15:03:41 +0200 (CEST) (envelope-from yuri@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q7KD3e6D070073 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1345467821; bh=sZw7FCvcEVWxoWYA1OLs063ewlKx/tUwPXdsmfizKp8=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Kh9BD57rtePEPjVbNVl54LXphUHUb3iXWh/pDdoK5A8WA5j6QcBah/jDfTmrrrNCF ZWLkk2N/7TAYr9b5rP7iIN8L4H/4XpVEVUU1kZ5GWtco3wr+4oUoQRH12+lP4nrg3j XaKYNpM6KvDsr6fTLsL7fYFt8bT5e2RtaHr99dWI= Message-ID: <503235AD.8030500@nlnetlabs.nl> Date: Mon, 20 Aug 2012 15:03:41 +0200 From: Yuri Schaeffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: John Dickinson References: <20120709162939.24274.77597.idtracker@ietfa.amsl.com> <502A124B.8070003@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 20 Aug 2012 15:03:41 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 13:03:46 -0000 On 08/20/2012 01:50 PM, John Dickinson wrote: > We could rearrange the table to tidy up the description of the > Double-Signature method but keep the existing names. Would that > help? Yes, making a clearer distinction between ZSK Double-Signature and KSK Double-Signature would help a bit. //yuri From peter@denic.de Mon Aug 20 06:19:08 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8DE21F860D for ; Mon, 20 Aug 2012 06:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sdo6qR18Tzec for ; Mon, 20 Aug 2012 06:19:07 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8B921F85BB for ; Mon, 20 Aug 2012 06:19:07 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1T3Rso-0004Gq-QH; Mon, 20 Aug 2012 15:19:06 +0200 Received: from localhost by x27.adm.denic.de with local id 1T3Rso-0003kD-MP; Mon, 20 Aug 2012 15:19:06 +0200 Date: Mon, 20 Aug 2012 15:19:06 +0200 From: Peter Koch To: dnsop@ietf.org Message-ID: <20120820131906.GD19035@x28.adm.denic.de> References: <20120816015259.GB18687@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120816015259.GB18687@mx1.yitter.info> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 13:19:08 -0000 Andrew, > In the archives since the meeting, I observe some comments at > http://www.ietf.org/mail-archive/web/dnsop/current/msg09783.html. But > I do not observe the announcement of a WGLC. I am wondering when we > might expect that call. both chairs have taken advantage of the season at least a bit. One of the chairs has recused himself being a co-editor, so this is the document shepherd. Issuing the WGLC involves reviewing the draft as well as the recent discussion to generate framing questions. In this particular case, several members of the WG, some of which I remember having been in favour of WGLC during the Vancouver meeting, had expressed support for a major change to the draft suggested by Matthijs Mekking on July 24 That would basically mean folding significant parts of 'keytiming bis' into the current 'key timing' draft. My current reading of the sense of the WG is that we move to WGLC with -03, declaring the July 24 suggestion out of scope for this document and keep momentum for 'dnssec bis'. Unless I hear objections, I'll issue a WGLC no later than Thursday this week. Opinions, please. -Peter PS: That said, documents can be reviewed any time by anyone, with or without last call inprogress. From paul.hoffman@vpnc.org Mon Aug 20 08:33:40 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799FD21F8618 for ; Mon, 20 Aug 2012 08:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7kc-bTyr9RV for ; Mon, 20 Aug 2012 08:33:38 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BD17921F8629 for ; Mon, 20 Aug 2012 08:33:37 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7KFXVUs079707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Aug 2012 08:33:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Paul Hoffman In-Reply-To: <20120820131906.GD19035@x28.adm.denic.de> Date: Mon, 20 Aug 2012 08:33:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <84240DA3-C287-43D1-9E04-D7BF8DA8CDFC@vpnc.org> References: <20120816015259.GB18687@mx1.yitter.info> <20120820131906.GD19035@x28.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1485) Cc: dnsop@ietf.org Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 15:33:40 -0000 On Aug 20, 2012, at 6:19 AM, Peter Koch wrote: > Andrew, >=20 >> In the archives since the meeting, I observe some comments at >> http://www.ietf.org/mail-archive/web/dnsop/current/msg09783.html. = But >> I do not observe the announcement of a WGLC. I am wondering when we >> might expect that call. >=20 > both chairs have taken advantage of the season at least a bit. One > of the chairs has recused himself being a co-editor, so this is > the document shepherd. Issuing the WGLC involves reviewing the > draft as well as the recent discussion to generate framing questions. >=20 > In this particular case, several members of the WG, some of which > I remember having been in favour of WGLC during the Vancouver > meeting, had expressed support for a major change to the draft > suggested by Matthijs Mekking on July 24 > > That would basically mean folding significant parts of 'keytiming bis' > into the current 'key timing' draft. That was my (probably biased) memory as well. > My current reading of the sense of the WG is that we move to > WGLC with -03, declaring the July 24 suggestion out of scope > for this document and keep momentum for 'dnssec bis'. That's one way to do it. A better one would be to start WG LC on = key-timing with an explicit question to the WG about folding in the = keytiming-bis changes. That way, the WG would know the status of both, = and we would would possibly produce just one document. The operations = community would be better off with just one document, if this WG can do = that. --Paul Hoffman= From matthijs@nlnetlabs.nl Tue Aug 21 00:13:08 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DEE21F8554 for ; Tue, 21 Aug 2012 00:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGmHck46KjRO for ; Tue, 21 Aug 2012 00:13:07 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD56E21F8555 for ; Tue, 21 Aug 2012 00:13:03 -0700 (PDT) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q7L7Ctcq087928 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 21 Aug 2012 09:12:57 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q7L7Ctcq087928 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1345533179; bh=lDvFga4/uhe46BOG+NwcmYtC1K08JT/edZJBmrrUg40=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=IfHYozL6RurwMw1oyYPkoO6P0XGHzUva7LpitQ2ZawA6/GZGQ6vLx5iuhEjZlKxK+ rsh1lx+a5HKZDTLqyBDJKcHC+o5MVEBfY6fmGN1cD+zGav9etZr7OdbNqQoEdrvLor O09Cu7BbsDY1CyXO0HaFg5oNiiWQxwAj+oaIUM7s= Message-ID: <503334F9.90608@nlnetlabs.nl> Date: Tue, 21 Aug 2012 09:12:57 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <20120816015259.GB18687@mx1.yitter.info> <20120820131906.GD19035@x28.adm.denic.de> <84240DA3-C287-43D1-9E04-D7BF8DA8CDFC@vpnc.org> In-Reply-To: <84240DA3-C287-43D1-9E04-D7BF8DA8CDFC@vpnc.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Tue, 21 Aug 2012 09:12:57 +0200 (CEST) Cc: Peter Koch , dnsop@ietf.org Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 07:13:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/20/2012 05:33 PM, Paul Hoffman wrote: > On Aug 20, 2012, at 6:19 AM, Peter Koch wrote: > >> Andrew, >> >>> In the archives since the meeting, I observe some comments at >>> http://www.ietf.org/mail-archive/web/dnsop/current/msg09783.html. >>> >>> But I do not observe the announcement of a WGLC. I am wondering >>> when we might expect that call. >> >> both chairs have taken advantage of the season at least a bit. >> One of the chairs has recused himself being a co-editor, so this >> is the document shepherd. Issuing the WGLC involves reviewing >> the draft as well as the recent discussion to generate framing >> questions. >> >> In this particular case, several members of the WG, some of which >> I remember having been in favour of WGLC during the Vancouver >> meeting, had expressed support for a major change to the draft >> suggested by Matthijs Mekking on July 24 >> >> That would basically mean folding significant parts of >> 'keytiming bis' into the current 'key timing' draft. > > That was my (probably biased) memory as well. Yes, me too. > >> My current reading of the sense of the WG is that we move to >> WGLC with -03, declaring the July 24 suggestion out of scope for >> this document and keep momentum for 'dnssec bis'. > > That's one way to do it. A better one would be to start WG LC on > key-timing with an explicit question to the WG about folding in > the keytiming-bis changes. That way, the WG would know the status > of both, and we would would possibly produce just one document. > The operations community would be better off with just one > document, if this WG can do that. I am afraid that one document just isn't sufficient. Adding a rollover time line requires a fair amount of pages to cover the timing details (at least with the current approach). The current document now covers six time lines. When we want to add time lines for Single Type Signing Scheme, Algorithm Rollover and Policy Rollover, we can come up with about ten more time lines. It would become a very lengthy document, arguably even longer than 4641bis ;). In my opinion, it would be better to categorize them and deal with them over multiple documents (one document per category). We then could use one document which has the base terminology, so we can refer to, for example, the key state definitions in future documents. However, then we have to make sure that the key state definitions are flexible enough to be able to describe these other rollovers (and I am afraid that the current key state definitions are not). Best regards, Matthijs > > --Paul Hoffman _______________________________________________ > DNSOP mailing list DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQMzT4AAoJEA8yVCPsQCW5RrcH/jYzbcEkaSCJdBUCJ4Ju9C6u P7EBEKxiL6mSPXcXPX6i9dZ8ZEnOJF3HX+1CYizLAtKHWiiUTiTduegnbCLwkn3s HvqzEE6h4izwvRZtbKRqTT05DAZGoL61/M/lhVA74z6OiP99D1BX6I9qFjxZCYeY mtOVGuaOtOcofcEf/loKCgDfy9hOzJ2HVZeptmWiTYLp/fBhYrzE3YHBePJqbQHM tTAKbgQc2whhKtCnxsKeo80Rland/F1XGb44sApijnZFsFIAEvorfdmQCQ6qsCRS PzIwTuUdYNFTiy7Bj8tT2NMAr9wfYHKvjQ6aZKKW9cTBw4ICTdedP91MPLK1Fw4= =MDnw -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Tue Aug 21 08:53:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB79421F84FE for ; Tue, 21 Aug 2012 08:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egWNMQQx6M4D for ; Tue, 21 Aug 2012 08:53:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 486C521F84D2 for ; Tue, 21 Aug 2012 08:53:06 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7LFr4E3058335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Aug 2012 08:53:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Paul Hoffman In-Reply-To: <503334F9.90608@nlnetlabs.nl> Date: Tue, 21 Aug 2012 08:53:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120816015259.GB18687@mx1.yitter.info> <20120820131906.GD19035@x28.adm.denic.de> <84240DA3-C287-43D1-9E04-D7BF8DA8CDFC@vpnc.org> <503334F9.90608@nlnetlabs.nl> To: Matthijs Mekking X-Mailer: Apple Mail (2.1485) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:53:09 -0000 On Aug 21, 2012, at 12:12 AM, Matthijs Mekking = wrote: > I am afraid that one document just isn't sufficient. Adding a rollover > time line requires a fair amount of pages to cover the timing details > (at least with the current approach). The current document now covers > six time lines. When we want to add time lines for Single Type Signing > Scheme, Algorithm Rollover and Policy Rollover, we can come up with > about ten more time lines. It would become a very lengthy document, > arguably even longer than 4641bis ;). In my opinion, it would be > better to categorize them and deal with them over multiple documents > (one document per category). >=20 > We then could use one document which has the base terminology, so we > can refer to, for example, the key state definitions in future > documents. However, then we have to make sure that the key state > definitions are flexible enough to be able to describe these other > rollovers (and I am afraid that the current key state definitions are > not). I disagree that seven or eleven documents would be best for operators. = Having more than one requires them to know the RFC numbers for all the = documents for which they are possibly interested. Other WGs have = problems with developers having to know about three RFCs for a protocol; = it seems odd to think that us having a dozen documents for operators is = a good idea. Long documents are not a problem if they are reasonably well organized = with truly parallel sections. --Paul Hoffman= From matthijs@nlnetlabs.nl Tue Aug 21 22:56:51 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628A511E80DE for ; Tue, 21 Aug 2012 22:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCiH9-j+ei2j for ; Tue, 21 Aug 2012 22:56:47 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA0911E80D5 for ; Tue, 21 Aug 2012 22:56:46 -0700 (PDT) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q7M5uauU038805 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2012 07:56:37 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q7M5uauU038805 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1345615002; bh=kewr0BUsnHuRcicA/kDSWDzyLNgvprLkn72WGZ/lpns=; h=Date:From:To:Subject:References:In-Reply-To; b=rEAbaum1OCAD+OCvI4yHOWZALE0fODDDoOZg/TO2a3RlYl+in3afIu/07rhmO/5kd zF0GKnVP9SGk1SJXDHIDu2WhpICOfZxxVdChVzU+G9cPpKHAgGJqlRLsDi6n5ruD56 i6XLNywPxSmspTBTnmGnrxobAEnua1mKZWLBgz1I= Message-ID: <50347496.7020507@nlnetlabs.nl> Date: Wed, 22 Aug 2012 07:56:38 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <20120816015259.GB18687@mx1.yitter.info> <20120820131906.GD19035@x28.adm.denic.de> <84240DA3-C287-43D1-9E04-D7BF8DA8CDFC@vpnc.org> <503334F9.90608@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 22 Aug 2012 07:56:38 +0200 (CEST) Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 05:56:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/21/2012 05:53 PM, Paul Hoffman wrote: > On Aug 21, 2012, at 12:12 AM, Matthijs Mekking > wrote: > >> I am afraid that one document just isn't sufficient. Adding a >> rollover time line requires a fair amount of pages to cover the >> timing details (at least with the current approach). The current >> document now covers six time lines. When we want to add time >> lines for Single Type Signing Scheme, Algorithm Rollover and >> Policy Rollover, we can come up with about ten more time lines. >> It would become a very lengthy document, arguably even longer >> than 4641bis ;). In my opinion, it would be better to categorize >> them and deal with them over multiple documents (one document per >> category). >> >> We then could use one document which has the base terminology, so >> we can refer to, for example, the key state definitions in >> future documents. However, then we have to make sure that the key >> state definitions are flexible enough to be able to describe >> these other rollovers (and I am afraid that the current key state >> definitions are not). > > I disagree that seven or eleven documents would be best for > operators. Having more than one requires them to know the RFC > numbers for all the documents for which they are possibly > interested. Other WGs have problems with developers having to know > about three RFCs for a protocol; it seems odd to think that us > having a dozen documents for operators is a good idea. I am not talking about seven or eleven. Although I did not wrote down an actual number, I could foresee three: One for KSK and ZSK rollovers, one for so called CSK rollovers and one for key timings with respect to policy rollovers (including algorithm rollover). Seven or eleven are indeed somewhat ridiculous numbers. Three is okay imho, especially if you put in the base document references to the other ones. Best regards, Matthijs > > Long documents are not a problem if they are reasonably well > organized with truly parallel sections. > > --Paul Hoffman _______________________________________________ > DNSOP mailing list DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQNHSSAAoJEA8yVCPsQCW5f8gH/1JXSWDKr7ZCADlYYP89VlC4 JNmjutD1yXM7k21A34ZJtgyxnXjXhqVwMpJOSZhmtJhaHaDwI86gw5e+teC+xx3a TUmrC2s95FmcY00V8oZx7JjyHLLBmLhVaqUL6QNr/QuSYDPD5afWvQyVdfDMhygY oMuIDla1CXmkZE/ZKTn8eaGmloSCoeYa+xnR9WROTbp3En8NByTcSjwahPtxBHVK vhTlzrBVMk9wdZpzZQJikqaIiWG4UXa7GAG+dZ94ha7prt6unIfeEFA3Z0oIkTXZ tgOCM7OfpLIJ5cInTPl62CP/gTul8zLYVQfKrAGFBPN81BXGresXCBvtcYCCL5g= =Wgsz -----END PGP SIGNATURE----- From peter@denic.de Thu Aug 23 14:49:28 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1803221F8606 for ; Thu, 23 Aug 2012 14:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmIOcASyNCzX for ; Thu, 23 Aug 2012 14:49:27 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 5D89321F85C0 for ; Thu, 23 Aug 2012 14:49:26 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1T4fHI-0006do-P2; Thu, 23 Aug 2012 23:49:24 +0200 Received: from localhost by x27.adm.denic.de with local id 1T4fHI-00024C-LN; Thu, 23 Aug 2012 23:49:24 +0200 Date: Thu, 23 Aug 2012 23:49:24 +0200 From: Peter Koch To: IETF DNSOP WG Message-ID: <20120823214924.GL30725@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 21:49:28 -0000 Dear DNSOP WG, this is to initiate a working group last call (WGLC) for "DNSSEC Key Timing Considerations" draft-ietf-dnsop-dnssec-key-timing-03.txt The WGLC will last until Friday, 14 September 2012 owed to return-to-desk season and the length of the draft. The intent is to request publication of the document as an Informational RFC. Please review the draft and send comments to this list (pls keep the full file name of the draft in the "Subject:"). A little guidance for what to look at: o appropriateness for the target audience o technical correctness and internal consistency o consistency with and/or relation to RFC 4641 and its designated successor In line with our custom the draft will only progress if it receives five or more significant(*) reviews and the (rough) consensus is in favour. (*) Please review thoroughly. While "yeah, ship it" might be perceived better than silence, it is not always helpful to determine consensus. In this particular case, I might take it as an indicator that the draft has received a cursory read. That is not to express an opinion on the quality of the draft, just a hint that there should be one bite for everybody. (For completeness sake, the remark applies to "nay" contributions respectively.) Finally I would like to confirm that I saw Paul and Matthijs reinforce their concerns raised in Vancouver in response to my mail earlier this week. Looking at the minutes I follow the mandate to issue the WGLC. Looking forward to your contributions. Best regards, Peter (as co-chair and doc shepherd) From Ed.Lewis@neustar.biz Fri Aug 24 10:55:08 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C00721F85AF for ; Fri, 24 Aug 2012 10:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.916 X-Spam-Level: X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ-70uaNlYx5 for ; Fri, 24 Aug 2012 10:55:07 -0700 (PDT) Received: from smtp125.dfw.emailsrvr.com (smtp125.dfw.emailsrvr.com [67.192.241.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7D08921F85A8 for ; Fri, 24 Aug 2012 10:55:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 001513C03A3; Fri, 24 Aug 2012 13:55:06 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp12.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 64A2B3C0201; Fri, 24 Aug 2012 13:55:06 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20120823214924.GL30725@x28.adm.denic.de> References: <20120823214924.GL30725@x28.adm.denic.de> Date: Fri, 24 Aug 2012 13:54:54 -0400 To: IETF DNSOP WG From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ed.lewis@neustar.biz Subject: Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:55:08 -0000 At 23:49 +0200 8/23/12, Peter Koch wrote: >Dear DNSOP WG, > >this is to initiate a working group last call (WGLC) for > > "DNSSEC Key Timing Considerations" > draft-ietf-dnsop-dnssec-key-timing-03.txt > First, my blanket objection to the draft, which isn't meant to be an insult to the effort that has gone into it. The draft is too detailed. Ok, I get that that is the purpose. And it achieves that, and probably should be lauded for that and be published for that. But, as an operator/implementor, the draft doesn't cut to the chase. I first mentioned this a long time ago, and usually would just let it drop. But in the last few weeks a senior developer said the same to me - it's really well detailed, but very complex. He also added that our design complied with it in a very simplified form. I replied that that was no accident. ;) So - I admire this draft, but wish there was a Gerber-ized version. (Gerber being a brand of baby food.) To give a concrete example of what I mean by too detailed - Dprp (propagation delay) is something that can be ignored with the advent of NOTIFY and IXFR. Theoretically it is there, practically it isn't there. Some specific comments: Section 2.1 # Of three methods, Double-Signature is conceptually the simplest - # introduce the new key and new signatures, then approximately one TTL # later remove the old key and old signatures. Pre-Publication is more Which TTL? The TTL of the DNSKEY set, the TTL that is the largest value of all the TTLs in the zone, etc.? Because of that question, I disagree that double signature is the simplest. (I'm just sayin', that's my opinion.) I think pre-pub is simpler because I know what TTL is involved (DNSEKEY). For signatures, the TTL might vary through the set. Section 2.3 # +------------------+------------------+-----------------------------+ # | ZSK Method | KSK Method | Description | # +------------------+------------------+-----------------------------+ # | Pre-Publication | (not applicable) | Publish the DNSKEY before | # | | | the RRSIGs. | Why is this "not applicable" for KSK? A KSK can be listed before it is used as one. Perhaps it isn't "not applicable" but "not realistic/sensible/practical". # | (not applicable) | Double-DS | Publish DS before the | # | | | DNSKEY. | This one is non-sensical for KSK. As an operator, I'd want to test locally before involving another party. I guess my notes here reflect that I see this document as helping operations as opposed to being an analysis of the protocol engineering. Section 4. # The aim of the emergency rollover is to allow the zone to be re- # signed with a new key as soon as possible. As a key must be in the # ready state to sign the zone, having at least one additional key (a # standby key) in this state at all times will minimise delay. I disagree with that goal. In designing emergency key changes, we realized the goal is to minimize operational disruption, not minimize time until a new key is "in place." In some cases, a key "break" might be a local event, local in the sense of the target name or the target of the poisoning. With this in mind, the only difference between a scheduled key change and an emergency key change is whether it is planned or not (;)) and how much more you pester the parent for the DS change (if needed). And the latter sentence might be countered with - having a standby key is a tradeoff against having smaller responses. (The same old "time vs. space" tradeoff.) Here, it's a matter of optimizing for the sunny day or the cloudy day. Section 6 # The reader is therefore reminded that DNSSEC is, as of date of # publication, in the early stages of deployment, and best practices # may further develop over time. This is true. I wish this would be emphasized in the earlier parts of the document. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From matthijs@nlnetlabs.nl Mon Aug 27 05:48:18 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F1521F861C for ; Mon, 27 Aug 2012 05:48:17 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY-pltE9pZmh for ; Mon, 27 Aug 2012 05:48:16 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5268421F852E for ; Mon, 27 Aug 2012 05:48:16 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:a992:57d9:b1a7:b609] ([IPv6:2001:7b8:206:1:a992:57d9:b1a7:b609]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q7RCmAWh018730 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 27 Aug 2012 14:48:11 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q7RCmAWh018730 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1346071692; bh=UqKpyam2nFTcf6r2WfD3hpO1FgwVVIRTS1xVRjeZfxE=; h=Date:From:To:Subject:References:In-Reply-To; b=HjJ7F5WgQf+eqdj2qx2Of6Nc1Vo0hJKP1cZVjHZlO2VEPvaNb+Z+a8IUW/V08qfxl hZ21OjFLevyKT5UQv9GtxdTs92kBymw4aBJu5L/G90Q5GPdIDP6uF4YR+dBRXC4bMN hOh+fB5j15y9+dzGsyouPIyqetl6yz4diCIh/BdM= Message-ID: <503B6C8C.30600@nlnetlabs.nl> Date: Mon, 27 Aug 2012 14:48:12 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <20120823214924.GL30725@x28.adm.denic.de> In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 27 Aug 2012 14:48:12 +0200 (CEST) Subject: Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 12:48:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 08/24/2012 07:54 PM, Edward Lewis wrote: > At 23:49 +0200 8/23/12, Peter Koch wrote: >> Dear DNSOP WG, >> >> this is to initiate a working group last call (WGLC) for >> >> "DNSSEC Key Timing Considerations" >> draft-ietf-dnsop-dnssec-key-timing-03.txt >> >> > >> > First, my blanket objection to the draft, which isn't meant to be > an insult to the effort that has gone into it. > > The draft is too detailed. > > Ok, I get that that is the purpose. And it achieves that, and > probably should be lauded for that and be published for that. But, > as an operator/implementor, the draft doesn't cut to the chase. > > I first mentioned this a long time ago, and usually would just let > it drop. But in the last few weeks a senior developer said the > same to me - it's really well detailed, but very complex. He also > added that our design complied with it in a very simplified form. > I replied that that was no accident. ;) > > So - I admire this draft, but wish there was a Gerber-ized > version. (Gerber being a brand of baby food.) Talking about complexity, finding the most Gerber-ized version of this document might be a NP-complete problem ;) > > To give a concrete example of what I mean by too detailed - Dprp > (propagation delay) is something that can be ignored with the > advent of NOTIFY and IXFR. Theoretically it is there, practically > it isn't there. > > Some specific comments: > > Section 2.1 > > # Of three methods, Double-Signature is conceptually the simplest > - # introduce the new key and new signatures, then approximately > one TTL # later remove the old key and old signatures. > Pre-Publication is more > > Which TTL? The TTL of the DNSKEY set, the TTL that is the largest > value of all the TTLs in the zone, etc.? I'll make it worse. In this case it's the largest value of all TTLs in a range of *previous versions* of the zones. Suppose that largest value has been lowered in the latest version of the zone, we still need to take into account that the predecessor data is cached for that large amount of time. > > Because of that question, I disagree that double signature is the > simplest. (I'm just sayin', that's my opinion.) I think pre-pub > is simpler because I know what TTL is involved (DNSEKEY). For > signatures, the TTL might vary through the set. Simplest here I guess refers to shortest, or, the least steps involved. > > Section 2.3 > > # > +------------------+------------------+-----------------------------+ > > # | ZSK Method | KSK Method | Description | > # > +------------------+------------------+-----------------------------+ > > # | Pre-Publication | (not applicable) | Publish the DNSKEY before | > # | | | the RRSIGs. > | > > Why is this "not applicable" for KSK? A KSK can be listed before > it is used as one. But it has no use to publish a KSK DNSKEY before its accompanying signature: When there is a DS record, the KSK that is referred to should also sign the DNSKEY RRset. When there is not yet a DS record, it should not be introduced until the KSK and its accompanying signature have been propagated to the caches. > > Perhaps it isn't "not applicable" but "not > realistic/sensible/practical". Not sensible would be the most sensible here :). Best regards, Matthijs > > # | (not applicable) | Double-DS | Publish DS before the > | # | | | DNSKEY. > | > > This one is non-sensical for KSK. As an operator, I'd want to > test locally before involving another party. > > I guess my notes here reflect that I see this document as helping > operations as opposed to being an analysis of the protocol > engineering. > > Section 4. > > # The aim of the emergency rollover is to allow the zone to be > re- # signed with a new key as soon as possible. As a key must > be in the # ready state to sign the zone, having at least one > additional key (a # standby key) in this state at all times will > minimise delay. > > I disagree with that goal. In designing emergency key changes, we > realized the goal is to minimize operational disruption, not > minimize time until a new key is "in place." In some cases, a key > "break" might be a local event, local in the sense of the target > name or the target of the poisoning. With this in mind, the only > difference between a scheduled key change and an emergency key > change is whether it is planned or not (;)) and how much more you > pester the parent for the DS change (if needed). > > And the latter sentence might be countered with - having a standby > key is a tradeoff against having smaller responses. (The same old > "time vs. space" tradeoff.) Here, it's a matter of optimizing for > the sunny day or the cloudy day. > > Section 6 > > # The reader is therefore reminded that DNSSEC is, as of date of > # publication, in the early stages of deployment, and best > practices # may further develop over time. > > This is true. I wish this would be emphasized in the earlier parts > of the document. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQO2yMAAoJEA8yVCPsQCW5KWYIAIp4ehruQAQAEFZ1bMaEMem5 CbJRLmJ7SZyQwhj8YiI9OUKY9uEvlvSyL9WhovlUyutQZJVqMQ/MKvFilJQ6vk1w PBtnbPxODqIDNPbiV9/r6/2dBHSNgMTzo1wBvtMZ9dEuY6lWdl+t4yd71Wm/C8LH xmSYmeMSE6+EnKx4hE15MO0DB3nDmDaFZ0GscUVMxtbQFT0v9njSy7AV/BUn0nqX E2mZ+n4KMaV5+kjgdFnJ9rXm1ozx6hXibtYCqAEHVHEWT9CuEqc/z7nMqiZYZbqR ujGJeSdg6Ll87Z6kiPScIK2Kjl6fe0LdydtSHQJiFirA7erc7WTPi9V1LbJx6Uw= =XTeC -----END PGP SIGNATURE----- From warren@kumari.net Wed Aug 29 14:59:22 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEC021F845D for ; Wed, 29 Aug 2012 14:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXADayNn+P2s for ; Wed, 29 Aug 2012 14:59:21 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id A484321F845C for ; Wed, 29 Aug 2012 14:59:21 -0700 (PDT) Received: from [192.168.1.87] (host86-179-59-20.range86-179.btcentralplus.com [86.179.59.20]) by vimes.kumari.net (Postfix) with ESMTPSA id 5A17A1B4065C; Wed, 29 Aug 2012 17:59:20 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1278) From: Warren Kumari Date: Wed, 29 Aug 2012 17:59:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120829214708.18987.89924.idtracker@ietfa.amsl.com> To: dnsop X-Mailer: Apple Mail (2.1278) Subject: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-omniscient-as112-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:59:22 -0000 Hi there dnsopers, We have updated this draft with the feedback from the fact to face = meeting in Vancouver, and made some other changes and readability = improvements. We would really appreciate any feedback and review. The primary change was to replace the "empty root zone file" (which = didn't work properly as recursive resolvers wouldn't cache it, defeating = most of the purpose!) with instructions on how to generate answers. = There is also a pointer to some running code created by Ray that does = this.=20 We really would have preferred a solution that didn't require custom = code, but=85 A number of additional changes (including some text, thanks) were = suggested by S. Moonesamy. Many of the changes are listed in "Appendix B.4 - Change History". W Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-wkumari-dnsop-omniscient-as112-01.txt > Date: August 29, 2012 5:47:08 PM EDT > To: warren@kumari.net > Cc: ray.bellis@nominet.org.uk, wfms@ryouko.imsb.nrc.ca, = joe.abley@icann.org >=20 >=20 > A new version of I-D, draft-wkumari-dnsop-omniscient-as112-01.txt > has been successfully submitted by Warren Kumari and posted to the > IETF repository. >=20 > Filename: draft-wkumari-dnsop-omniscient-as112 > Revision: 01 > Title: Omniscient AS112 Servers > Creation date: 2012-08-29 > WG ID: Individual Submission > Number of pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-wkumari-dnsop-omniscient-as112-0= 1.txt > Status: = http://datatracker.ietf.org/doc/draft-wkumari-dnsop-omniscient-as112 > Htmlized: = http://tools.ietf.org/html/draft-wkumari-dnsop-omniscient-as112-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-wkumari-dnsop-omniscient-as112-01= >=20 > Abstract: > The AS112 Project loosely coordinates Domain Name System (DNS) > servers to which DNS zones corresponding to private use addresses = are > delegated. Queries for names within those zones have no useful > responses in a global context. The purpose of this project is to > reduce the load of such junk queries on the authoritative name > servers that would otherwise receive them, and instead direct the > load to name servers operated within the AS112 project. >=20 > Adding and dropping zones from the AS112 servers is difficult, due = to > the loosely-coordinated nature of the project. This document > proposes a mechanism by which AS112 name servers could answer > authoritatively for all possible zones. This eliminates the = add/drop > problem, changing it to a matter of delegation within the DNS and > requiring no operational changes on the servers themselves. >=20 > This document updates RFC 6304. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 -- Credo quia absurdum est. From johani@autonomica.se Thu Aug 30 02:24:01 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699B321F8550 for ; Thu, 30 Aug 2012 02:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i1bCwYExVb2 for ; Thu, 30 Aug 2012 02:24:00 -0700 (PDT) Received: from mail.netnod.se (mail.netnod.se [192.71.80.100]) by ietfa.amsl.com (Postfix) with ESMTP id 179F121F851B for ; Thu, 30 Aug 2012 02:23:59 -0700 (PDT) Received: from [IPv6:2a01:3f0:1::5a55:caff:fef0:8bdb] (unknown [IPv6:2a01:3f0:1:0:5a55:caff:fef0:8bdb]) (Authenticated sender: johani) by mail.netnod.se (Postfix) with ESMTPSA id 7F25F7C0E6; Thu, 30 Aug 2012 11:23:27 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Johan_Ihr=E9n?= In-Reply-To: Date: Thu, 30 Aug 2012 11:23:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A7AAF8E-44C7-479A-8AC5-2695AA533139@autonomica.se> References: <20120823214924.GL30725@x28.adm.denic.de> To: Edward Lewis X-Mailer: Apple Mail (2.1084) Cc: IETF DNSOP WG Subject: Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 09:24:01 -0000 Hi Ed, On Aug 24, 2012, at 19:54 , Edward Lewis wrote: > At 23:49 +0200 8/23/12, Peter Koch wrote: >> Dear DNSOP WG, >>=20 >> this is to initiate a working group last call (WGLC) for >>=20 >> "DNSSEC Key Timing Considerations" >> draft-ietf-dnsop-dnssec-key-timing-03.txt >> = >=20 > First, my blanket objection to the draft, which isn't meant to be an = insult to the effort that has gone into it. >=20 > The draft is too detailed. I agree. > Ok, I get that that is the purpose. And it achieves that, and = probably should be lauded for that and be published for that. But, as = an operator/implementor, the draft doesn't cut to the chase. >=20 > I first mentioned this a long time ago, and usually would just let it = drop. But in the last few weeks a senior developer said the same to me = - it's really well detailed, but very complex. He also added that our = design complied with it in a very simplified form. I replied that that = was no accident. ;) >=20 > So - I admire this draft, but wish there was a Gerber-ized version. = (Gerber being a brand of baby food.) >=20 > To give a concrete example of what I mean by too detailed - Dprp = (propagation delay) is something that can be ignored with the advent of = NOTIFY and IXFR. Theoretically it is there, practically it isn't there. While I mostly have to agree I also have to point out that with today's = anycast clouds it is more likely than before that one actually may lose = contact with a remote site for a while. I know that it happens to us, = and while we obviously immediately attempt to rectify the situation the = fact remains that our slave server on the dark side of the Moon is not = just a NOTIFY+IXFR delayed. Furthermore, the TTL is also part of the = propagation delay, and that obviously always remains. So your claim of "practically it isn't there" is, unfortunately, too = strong for me. > Some specific comments: >=20 > Section 2.1 >=20 > # Of three methods, Double-Signature is conceptually the simplest - > # introduce the new key and new signatures, then approximately one = TTL > # later remove the old key and old signatures. Pre-Publication is = more >=20 > Which TTL? The TTL of the DNSKEY set, the TTL that is the largest = value of all the TTLs in the zone, etc.? >=20 > Because of that question, I disagree that double signature is the = simplest. (I'm just sayin', that's my opinion.) I think pre-pub is = simpler because I know what TTL is involved (DNSEKEY). For signatures, = the TTL might vary through the set. While I do see your point, I still think it is fair to claim that = Double-Signature is CONCEPTUALLY the simplest. I.e. it is simpler to = explain Double-Signature to a noob than to explain the other = alternatives. But let's not quibble about language at this stage, you do have a point = and we could have been clearer here. Sorry. > Section 2.3 >=20 > # = +------------------+------------------+-----------------------------+ > # | ZSK Method | KSK Method | Description = | > # = +------------------+------------------+-----------------------------+ > # | Pre-Publication | (not applicable) | Publish the DNSKEY before = | > # | | | the RRSIGs. = | >=20 > Why is this "not applicable" for KSK? A KSK can be listed before it = is used as one. The entire raison d'etre for pre-publication that for a ZSK the RRSIGs = (that ZSKs generate) and the DNSKEYs (of which the ZSK is a part) don't = travel together, and hence may or may not be in the same cache at the = same time.=20 This, however, does not hold true for KSKs, because the RRSIG generated = by the KSK *must* travel together with the KSK and hence pre-publication = is meaningless. You just publish the new KSK at the same time that you = start using it for generating RRSIGs. > Perhaps it isn't "not applicable" but "not = realistic/sensible/practical". Or "pointless". > # | (not applicable) | Double-DS | Publish DS before the = | > # | | | DNSKEY. = | >=20 > This one is non-sensical for KSK. As an operator, I'd want to test = locally before involving another party. You're assuming that the other party (i.e. the parent) is someone else = than yourself. That is not necessarily correct. Another reason may be = that while you know that you will be able to publish your new KSK almost = instantly, you also know that that lazy-bones of a parent will take a = random time between 1h and 2 weeks to add the new DS. So you start with = the request to the parent... I have to disagree that Double-DS is non-sensicalf for a KSK. It is not, = although in the common use case of the parent being a well-run TLD then = I can see the *parent* being against this method. But that's not the = only case I care about. > I guess my notes here reflect that I see this document as helping = operations as opposed to being an analysis of the protocol engineering. >=20 > Section 4. >=20 > # The aim of the emergency rollover is to allow the zone to be re- > # signed with a new key as soon as possible. As a key must be in = the > # ready state to sign the zone, having at least one additional key = (a > # standby key) in this state at all times will minimise delay. >=20 > I disagree with that goal. In designing emergency key changes, we = realized the goal is to minimize operational disruption, not minimize = time until a new key is "in place." In some cases, a key "break" might = be a local event, local in the sense of the target name or the target of = the poisoning. =20 I disagree with your disagreement ;-) I do agree with the goal of minimizing operational disruption. That's = the correct goal. In some cases it may be that the consequence is to = basically ignore the problem and just stay with the normal rollover = schedule.=20 Also, one has to ask whose operations we're talking about ... i.e. = there's a difference between minimizing your operational disruption (as = the zone owner) and the operational disruption for an ISP doing = validation of your data (see nasa.gov vs Comcast). However, IF you've made the decision not to stay with the schedule, but = actually cause an operational disruption and do an emergency rollover = THEN you want it to complete as quickly as possible. > With this in mind, the only difference between a scheduled key change = and an emergency key change is whether it is planned or not (;)) and how = much more you pester the parent for the DS change (if needed). This is exactly my view also. > And the latter sentence might be countered with - having a standby key = is a tradeoff against having smaller responses. (The same old "time vs. = space" tradeoff.) Here, it's a matter of optimizing for the sunny day = or the cloudy day. Sure. > Section 6 >=20 > # The reader is therefore reminded that DNSSEC is, as of date of > # publication, in the early stages of deployment, and best practices > # may further develop over time. >=20 > This is true. I wish this would be emphasized in the earlier parts of = the document. I agree. Regards, Johan From johani@autonomica.se Thu Aug 30 02:41:02 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1621521F8646 for ; Thu, 30 Aug 2012 02:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsFjT82MlHoz for ; Thu, 30 Aug 2012 02:41:01 -0700 (PDT) Received: from mail.netnod.se (mail.netnod.se [192.71.80.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1F821F8645 for ; Thu, 30 Aug 2012 02:41:01 -0700 (PDT) Received: from [IPv6:2a01:3f0:1::5a55:caff:fef0:8bdb] (unknown [IPv6:2a01:3f0:1:0:5a55:caff:fef0:8bdb]) (Authenticated sender: johani) by mail.netnod.se (Postfix) with ESMTPSA id 705097C0E6; Thu, 30 Aug 2012 11:40:30 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Johan_Ihr=E9n?= In-Reply-To: <84240DA3-C287-43D1-9E04-D7BF8DA8CDFC@vpnc.org> Date: Thu, 30 Aug 2012 11:40:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <803A6352-5247-431E-AB7A-9CEBACF9790C@autonomica.se> References: <20120816015259.GB18687@mx1.yitter.info> <20120820131906.GD19035@x28.adm.denic.de> <84240DA3-C287-43D1-9E04-D7BF8DA8CDFC@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: Peter Koch , dnsop@ietf.org Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 09:41:02 -0000 On Aug 20, 2012, at 17:33 , Paul Hoffman wrote: > On Aug 20, 2012, at 6:19 AM, Peter Koch wrote: >=20 >> Andrew, >>=20 >>> In the archives since the meeting, I observe some comments at >>> http://www.ietf.org/mail-archive/web/dnsop/current/msg09783.html. = But >>> I do not observe the announcement of a WGLC. I am wondering when we >>> might expect that call. >>=20 >> both chairs have taken advantage of the season at least a bit. One >> of the chairs has recused himself being a co-editor, so this is >> the document shepherd. Issuing the WGLC involves reviewing the >> draft as well as the recent discussion to generate framing questions. >>=20 >> In this particular case, several members of the WG, some of which >> I remember having been in favour of WGLC during the Vancouver >> meeting, had expressed support for a major change to the draft >> suggested by Matthijs Mekking on July 24 >> >> That would basically mean folding significant parts of 'keytiming = bis' >> into the current 'key timing' draft. >=20 > That was my (probably biased) memory as well. >=20 >> My current reading of the sense of the WG is that we move to >> WGLC with -03, declaring the July 24 suggestion out of scope >> for this document and keep momentum for 'dnssec bis'. >=20 > That's one way to do it. A better one would be to start WG LC on = key-timing with an explicit question to the WG about folding in the = keytiming-bis changes. That way, the WG would know the status of both, = and we would would possibly produce just one document. The operations = community would be better off with just one document, if this WG can do = that. Not to question the abilities of the WG, but I still have to ask whether = (in your opinion) the operations community would be better off with a = single document that may be finished around Christmas Eve 2020 or rather = live with multiple docs that are published somewhat sooner than that. > Having more than one requires them to know the RFC numbers for all the = documents for which they are possibly interested. Other WGs have = problems with developers having to know about three RFCs for a protocol; = it seems odd to think that us having a dozen documents for operators is = a good idea. > Long documents are not a problem if they are reasonably well organized = with truly parallel sections. So, on principle I have to disagree with this. Multiple documents are a = method of abstraction and organization, just like directories, or, for = that matter, dividing your source into multiple files. If it is really a problem to have to refer to more than on RFC, then I = think we made a huge error many years ago when we gave RFCs a number. We = should have gone for=20 "The RFC For The Internet" (yet to be published) and meanwhile kept the Internet running on various versions of expired = drafts. Tongue-in-cheek and no offence intended ;-) Regards, Johan From paul@redbarn.org Thu Aug 30 09:45:25 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C1C21F8557 for ; Thu, 30 Aug 2012 09:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xA-o6F4CRUG for ; Thu, 30 Aug 2012 09:45:25 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 68E5421F854D for ; Thu, 30 Aug 2012 09:45:25 -0700 (PDT) Received: from [IPv6:2001:559:8000:cb:c88d:23c8:e796:2268] (unknown [IPv6:2001:559:8000:cb:c88d:23c8:e796:2268]) by ss.vix.com (Postfix) with ESMTP id 86091EE0C0; Thu, 30 Aug 2012 16:45:23 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <503F9899.6020604@redbarn.org> Date: Thu, 30 Aug 2012 16:45:13 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Johan_Ihr=E9n?= References: <20120816015259.GB18687@mx1.yitter.info> <20120820131906.GD19035@x28.adm.denic.de> <84240DA3-C287-43D1-9E04-D7BF8DA8CDFC@vpnc.org> <803A6352-5247-431E-AB7A-9CEBACF9790C@autonomica.se> In-Reply-To: <803A6352-5247-431E-AB7A-9CEBACF9790C@autonomica.se> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dnsop@ietf.org, Peter Koch , Paul Hoffman Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 16:45:25 -0000 On 2012-08-30 9:40 AM, Johan Ihrén wrote: > On Aug 20, 2012, at 17:33 , Paul Hoffman wrote: > >> On Aug 20, 2012, at 6:19 AM, Peter Koch wrote: >> >>> My current reading of the sense of the WG is that we move to >>> WGLC with -03, declaring the July 24 suggestion out of scope >>> for this document and keep momentum for 'dnssec bis'. dnssec-bis was delegated signer. dnssec-ter was type code roll. we're on dnssec-nextgen now. >> That's one way to do it. A better one would be to start WG LC on key-timing with an explicit question to the WG about folding in the keytiming-bis changes. That way, the WG would know the status of both, and we would would possibly produce just one document. The operations community would be better off with just one document, if this WG can do that. > Not to question the abilities of the WG, but I still have to ask whether (in your opinion) the operations community would be better off with a single document that may be finished around Christmas Eve 2020 or rather live with multiple docs that are published somewhat sooner than that. while i agree with these sentiments i have a broader concern. ietf's mantra is good engineering. if we know now that keytiming has flaws, and we are only considering publishing it because we know our own record shows that reaching consensus for keytiming-bis will take a long time, then it's an implicit indictment (by us) of our own record and habits. we should have a better reason for publishing two documents, like new ideas occurred to us after the first one was beyond reach of our pen, or they have different topics. paul From paul.hoffman@vpnc.org Thu Aug 30 10:11:25 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699CD21F851A for ; Thu, 30 Aug 2012 10:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEJ0khy1wc0I for ; Thu, 30 Aug 2012 10:11:24 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFBE21F8518 for ; Thu, 30 Aug 2012 10:11:24 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7UHBMGI039116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 30 Aug 2012 10:11:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Paul Hoffman In-Reply-To: <503F9899.6020604@redbarn.org> Date: Thu, 30 Aug 2012 10:11:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <976C3731-677B-482F-87A0-51777BA51E6C@vpnc.org> References: <20120816015259.GB18687@mx1.yitter.info> <20120820131906.GD19035@x28.adm.denic.de> <84240DA3-C287-43D1-9E04-D7BF8DA8CDFC@vpnc.org> <803A6352-5247-431E-AB7A-9CEBACF9790C@autonomica.se> <503F9899.6020604@redbarn.org> To: "dnsop@ietf.org WG" X-Mailer: Apple Mail (2.1486) Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 17:11:25 -0000 On Aug 30, 2012, at 9:45 AM, Paul Vixie wrote: > On 2012-08-30 9:40 AM, Johan Ihr=E9n wrote: >> Not to question the abilities of the WG, but I still have to ask = whether (in your opinion) the operations community would be better off = with a single document that may be finished around Christmas Eve 2020 or = rather live with multiple docs that are published somewhat sooner than = that. >=20 > while i agree with these sentiments i have a broader concern. ietf's > mantra is good engineering. if we know now that keytiming has flaws, = and > we are only considering publishing it because we know our own record > shows that reaching consensus for keytiming-bis will take a long time, > then it's an implicit indictment (by us) of our own record and habits. >=20 > we should have a better reason for publishing two documents, like new > ideas occurred to us after the first one was beyond reach of our pen, = or > they have different topics. A big +1. An operator who wants to know how to do rollovers will not = know *or care* why they followed IETF guidance that was overturned or = even clarified soon after. The reasons that the base document got delayed so horribly do not matter = any more: what matters is what the WG and its leadership are willing to = do today to help operators in the near future. --Paul Hoffman= From joe.abley@icann.org Thu Aug 30 10:57:50 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3B221F8475 for ; Thu, 30 Aug 2012 10:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyFm0O2e3AfM for ; Thu, 30 Aug 2012 10:57:49 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE0C21F846E for ; Thu, 30 Aug 2012 10:57:49 -0700 (PDT) Received: from [199.212.90.41] (199.212.90.41) by smtpx.exc.icann.org (64.78.22.243) with Microsoft SMTP Server (TLS) id 8.3.245.1; Thu, 30 Aug 2012 10:57:48 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_C7AC567F-3A70-4566-8A74-A74E1BCC48F7"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Joe Abley In-Reply-To: <976C3731-677B-482F-87A0-51777BA51E6C@vpnc.org> Date: Thu, 30 Aug 2012 13:57:46 -0400 Message-ID: <5C230CCB-B931-4D7D-9B10-DAF647A54485@icann.org> References: <20120816015259.GB18687@mx1.yitter.info> <20120820131906.GD19035@x28.adm.denic.de> <84240DA3-C287-43D1-9E04-D7BF8DA8CDFC@vpnc.org> <803A6352-5247-431E-AB7A-9CEBACF9790C@autonomica.se> <503F9899.6020604@redbarn.org> <976C3731-677B-482F-87A0-51777BA51E6C@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1486) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 17:57:50 -0000 --Apple-Mail=_C7AC567F-3A70-4566-8A74-A74E1BCC48F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 2012-08-30, at 13:11, Paul Hoffman wrote: > On Aug 30, 2012, at 9:45 AM, Paul Vixie wrote: >=20 >> On 2012-08-30 9:40 AM, Johan Ihr=E9n wrote: >>> Not to question the abilities of the WG, but I still have to ask = whether (in your opinion) the operations community would be better off = with a single document that may be finished around Christmas Eve 2020 or = rather live with multiple docs that are published somewhat sooner than = that. >>=20 >> while i agree with these sentiments i have a broader concern. ietf's >> mantra is good engineering. if we know now that keytiming has flaws, = and >> we are only considering publishing it because we know our own record >> shows that reaching consensus for keytiming-bis will take a long = time, >> then it's an implicit indictment (by us) of our own record and = habits. >>=20 >> we should have a better reason for publishing two documents, like new >> ideas occurred to us after the first one was beyond reach of our pen, = or >> they have different topics. >=20 > A big +1. An operator who wants to know how to do rollovers will not = know *or care* why they followed IETF guidance that was overturned or = even clarified soon after. I suspect an increasing proportion of operators doing DNSSEC do not care = how to do rollovers, in fact. They care that the software they're using = to manage keys and sign things is doing the right thing. The pragmatic = long-term view is, I think, that this document doesn't give advice to = operators so much as advice for those implementing DNSSEC signers. I am not suggesting that operators don't care what happens under the = hood, or that vendors don't care about operators. But I think the = inference that this is advice to heed before you dive in and perform = rollovers by hand is short-sighted. The focus ought to be advice that = can be converted easily into good code. I am not a developer of DNS software, and hence don't feel well-placed = to review the draft from that perspective. However, my feeling (based on = words absorbed inadvertently from people who are developers) is that the = document would better serve that perspective if it presented robust = state machines and algorithms for arbitrary rollovers. As an operator I would very much like trustworthy tools that could take = my desire (say) to roll a KSK from an N-bit alg-A key to an M-bit alg-B = key and show me the timing constraints for that rollover to be = completed, so I can plan the exercise, accommodate any expected delay in = DS publication in parent zones, keep my relying parties informed, and = hopefully have robots execute the actual zone changes for me. Working = all that out by hand (and making the zone changes manually) based on the = advice in dnssec-key-timing is error-prone. Joe --Apple-Mail=_C7AC567F-3A70-4566-8A74-A74E1BCC48F7 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINwTCCBsIw ggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyB n+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cx SIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPt P77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2 zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYI KwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9 bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJl cG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAA dABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAg AGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMA UAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkA dAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBp AG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUH AQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNV HSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQq tbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F 2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqg qKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMr lSBOKs+WYHr4LIDwlVLOKZaBYjCCBvcwggXfoAMCAQICEAPfgdmmiPyfC1aLEU/4udowDQYJKoZI hvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMB4XDTEy MDQxMDAwMDAwMFoXDTE1MDMyNzEyMDAwMFowgaYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRcwFQYDVQQHEw5NYXJpbmEgZGVsIFJleTE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9y YXRpb24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBOdW1iZXJzMRcwFQYDVQQLEw5ETlMgT3BlcmF0 aW9uczESMBAGA1UEAxMJSm9lIEFibGV5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA x4LpgTuNwYrQ6up4l/bQszwAXqpPpYaiWFSBo8p9sFJM1gRtT33Yv+IRpi+2eHpyJTdd/ECCGTL3 7ig/SBpgvCquV/wLW0go48x7ZSUa0QNgCEnpAFGOmDpYietFYZIMwTUmLNqTksB9VjMRb7i7IOp7 aYidL6gPkIEOPaB2NggiypmiePfHXZ5Fiy2wrcZ6LpDm/f+me5XfWc31MrgwV9/2sWTAa7vBPCd+ 576spsXAL6LepBy0q69rzyPBtF02ve+ZYpWwRu018JZqE/N1rdW7BWKjzL2c45s0KmwIN1QCxMbp 5ldbdtd9UELWI/475mnR5iIhIJuNwp+s9DsrnQIDAQABo4IDYjCCA14wHwYDVR0jBBgwFoAUFQAS KxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFPfglsX6YK0WUka9fWfEx78ZEbLGMB4GA1UdEQQX MBWBE2pvZS5hYmxleUBpY2Fubi5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDA4oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwE AQIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9z aXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0cy5kaWdp Y2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4IBAQAiQol79jbbcuM4zgC/3QpxLvGBEl5HQQfcGVGi3I/KWPMHxUOcKhoit0fATvuB nb/qLCfvOLYzKavBs3XiB8oK57NDJTtxxOt2JBoWIoP/FDdeFcxrRZoUaKYSCopWvxHZKHqIsXhR N2ePtxklW84yQws3hm+9I87IEUAzgOjTQWYflZyw5S8eWoaEhF2M1qVbHhurkk082rxZCopADsV2 H++UYkYNEy26ublCOVFFuyfYYUbxOwUmhM74UM8iyScS3+qeCw52DE9bTArQ9fjfMYKo6nCTRxWL sOxpYiJdCsKWWDPvHvSCBYDuASiIOIA+wJrBanYwt0wpK/+OaREFMYIDEDCCAwwCAQEwdjBiMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTECEAPfgdmmiPyfC1aLEU/4udow CQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIwODMwMTc1NzQ2WjAjBgkqhkiG9w0BCQQxFgQUF42av5Hf+WI8Th/HP3svYJA+RccwgYUGCSsG AQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UE CxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD 34HZpoj8nwtWixFP+LnaMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGln aUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD34HZpoj8nwtWixFP+LnaMA0GCSqGSIb3DQEBAQUABIIB AFIWg+lNTTA56gGNiEtKt4m/GZ1INqp4p5JXLUCiQP2/iO1me1ew3O22+ovOAHwzg6A2viN+sY5H qCKMi1eZonU3KIW4MJ+k4/EjsusFLyNaSKtMI0AxF/L0bgXX4tMAFAvkyEJrlApgHYTG9zmOaQmS fls4tgUaupZt01DVfNf2cvEEuv0CSHxiVL32PW2xKM1P2Lwm2F/2uGf26r/PeD+6EyvQsnVdfiFu f0QjvsT+POHNMA09XfoTWsk+UZFs5hcF2ikxFsMOR4qDW7qzdrmBCdcLhfkYI9AwfeRtaxXKca52 s5j463kzUZet5Xj0+UJl29spdwar/HHJeuPur2YAAAAAAAA= --Apple-Mail=_C7AC567F-3A70-4566-8A74-A74E1BCC48F7-- From paul.hoffman@vpnc.org Thu Aug 30 11:21:33 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A06821F85A0 for ; Thu, 30 Aug 2012 11:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHOKE+0q9vwC for ; Thu, 30 Aug 2012 11:21:32 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A393A21F8585 for ; Thu, 30 Aug 2012 11:21:32 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7UIL9kR065086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Aug 2012 11:21:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Paul Hoffman In-Reply-To: <5C230CCB-B931-4D7D-9B10-DAF647A54485@icann.org> Date: Thu, 30 Aug 2012 11:21:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120816015259.GB18687@mx1.yitter.info> <20120820131906.GD19035@x28.adm.denic.de> <84240DA3-C287-43D1-9E04-D7BF8DA8CDFC@vpnc.org> <803A6352-5247-431E-AB7A-9CEBACF9790C@autonomica.se> <503F9899.6020604@redbarn.org> <976C3731-677B-482F-87A0-51777BA51E6C@vpnc.org> <5C230CCB-B931-4D7D-9B10-DAF647A54485@icann.org> To: Joe Abley X-Mailer: Apple Mail (2.1486) Cc: "dnsop@ietf.org WG" , Paul Hoffman Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 18:21:33 -0000 On Aug 30, 2012, at 10:57 AM, Joe Abley wrote: > I suspect an increasing proportion of operators doing DNSSEC do not = care how to do rollovers, in fact. They care that the software they're = using to manage keys and sign things is doing the right thing. Good point, yes. > The pragmatic long-term view is, I think, that this document doesn't = give advice to operators so much as advice for those implementing DNSSEC = signers. Yes and no. Many of the aforementioned operators are probably going to = be asked "are you sure that the software you are using follows the = specifications" and those operators are going to look for the vendor's = checkmark next to "the right" RFC number. If so, this argues strongly for fewer RFCs for the checkmarks to match = to. > I am not suggesting that operators don't care what happens under the = hood, or that vendors don't care about operators. But I think the = inference that this is advice to heed before you dive in and perform = rollovers by hand is short-sighted. The focus ought to be advice that = can be converted easily into good code. Yes. Here, "good" should also mean "code whose logs can be followed by = someone who hasn't read the RFC, if needed". > I am not a developer of DNS software, and hence don't feel well-placed = to review the draft from that perspective. However, my feeling (based on = words absorbed inadvertently from people who are developers) is that the = document would better serve that perspective if it presented robust = state machines and algorithms for arbitrary rollovers. >=20 > As an operator I would very much like trustworthy tools that could = take my desire (say) to roll a KSK from an N-bit alg-A key to an M-bit = alg-B key and show me the timing constraints for that rollover to be = completed, so I can plan the exercise, accommodate any expected delay in = DS publication in parent zones, keep my relying parties informed, and = hopefully have robots execute the actual zone changes for me. Working = all that out by hand (and making the zone changes manually) based on the = advice in dnssec-key-timing is error-prone. Yes. --Paul Hoffman= From fanf2@hermes.cam.ac.uk Thu Aug 30 11:24:15 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441BD21F8540 for ; Thu, 30 Aug 2012 11:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UL4ya8DR4Wv for ; Thu, 30 Aug 2012 11:24:14 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 7E76A21F853C for ; Thu, 30 Aug 2012 11:24:14 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:44870) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1T79PR-0001iJ-qg (Exim 4.72) (return-path ); Thu, 30 Aug 2012 19:24:05 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1T79PR-0000db-A9 (Exim 4.72) (return-path ); Thu, 30 Aug 2012 19:24:05 +0100 Date: Thu, 30 Aug 2012 19:24:05 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Paul Vixie In-Reply-To: <503F9899.6020604@redbarn.org> Message-ID: References: <20120816015259.GB18687@mx1.yitter.info> <20120820131906.GD19035@x28.adm.denic.de> <84240DA3-C287-43D1-9E04-D7BF8DA8CDFC@vpnc.org> <803A6352-5247-431E-AB7A-9CEBACF9790C@autonomica.se> <503F9899.6020604@redbarn.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, Peter Koch , Paul Hoffman Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 18:24:15 -0000 Paul Vixie wrote: > > while i agree with these sentiments i have a broader concern. ietf's > mantra is good engineering. if we know now that keytiming has flaws, and > we are only considering publishing it because we know our own record > shows that reaching consensus for keytiming-bis will take a long time, > then it's an implicit indictment (by us) of our own record and habits. But I thought the flaws discussed in this thread were in terms of presentation rather than engineering. (I haven't reviewed the document yet.) As far as I can tell DNSSEC implementations and deployment are still in a somewhat exploratory phase wrt key management, so it is reasonable to expect it to take a long time to work out how to simplify the document in a sensible way. I expect it to go along with good implementations of canned rollover procedures. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.