Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14
Matthijs Mekking <matthijs@nlnetlabs.nl> Thu, 06 September 2012 10:29 UTC
Return-Path: <matthijs@nlnetlabs.nl>
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 3CEDB21F862B for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2012 03:29:33 -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 4RZ7C5WCWpDf for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2012 03:29:32 -0700 (PDT)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D2421F8503 for <dnsop@ietf.org>; Thu, 6 Sep 2012 03:29:31 -0700 (PDT)
Received: from [213.154.224.18] (zoidberg.nlnetlabs.nl [213.154.224.18]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q86ATOD1049619 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <dnsop@ietf.org>; Thu, 6 Sep 2012 12:29:25 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl)
X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q86ATOD1049619
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1346927366; bh=3kCHi4COj5IhlFIzcPgHe8476jb8WfiQFLozOm+1pwM=; h=Date:From:To:Subject:References:In-Reply-To; b=c54x6YipbVaLGCV3Kpq4qIG1Wt+pH/lBY+UGlleKjbFdvemj4xuavgWikM/kiBB8l RZI7DrJfNIDLypr1EPnub4pDNVxuLULZZwBfIUWOH3u4os3XTmOIn7nzfT22RdmqST 2mNuGEltXvlGMDXvybshHjgP9fH/g4AkBqcuE2N8=
Message-ID: <50487B06.3030303@nlnetlabs.nl>
Date: Thu, 06 Sep 2012 12:29:26 +0200
From: Matthijs Mekking <matthijs@nlnetlabs.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: dnsop@ietf.org
References: <20120823214924.GL30725@x28.adm.denic.de>
In-Reply-To: <20120823214924.GL30725@x28.adm.denic.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
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]); Thu, 06 Sep 2012 12:29:25 +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 <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Sep 2012 10:29:33 -0000
Hi, Here is my review. There are some small comments and some larger comments, but I decided to report them in order of appearance. * Section 1.1. Key Rolling Considerations. - Bullet point 2 takes into account DNSSEC boot-strapping. The document is mainly about key timings in a rollover event. Section 3.3.5 talks a bit about introducing a first key. I am questioning that the topic on enabling DNSSEC is so small in this document that it may be better to remove this bullet point and section 3.3.5. - A style remark. In bullet point 4: I would remove the brackets around the last sentence. - Another style remark. The last sentence talks about key-signing keys and zone signing keys. Inconsistency with the "-". * Section 1.2. Types of Keys - In the last sentence of paragraph 2, make clear that also the RRSIG of the DNSKEY RRset is important: In the case of the KSK, the information is the self-signed DNSKEY and the DS RRset... ^^^^^^^^^^^ * Section 2.1. ZSK Rollovers - Bullet point 2, second paragraph. "Once the signing process is complete and enough time has elapsed to allow all old information to expire from caches, ...". It is actually more about the new information to propagate to caches, so I would suggest to replace it with: Once the signing process is complete and enough time has elapsed to allow all new information to propagate to caches, ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - The final paragraph, which summarizes the three ZSK rollover methods, can it be removed? The section itself is already a summary of the possible ZSK rollovers, I don't see any value in this final paragraph. * Section 2.2. KSK Rollovers - Nit: Paragraph 4 starts with "Like the ZSK case, ..." which to me seems to insinuate that the number of KSK rollover methods is related to the number of ZSK rollover methods. I would like to see it removed. - Bullet point 1 says that the ZSK Double Signature rollover is also known as Double-DNSKEY. I have not heard of this term before reading this document. Is it really known as? If not, please remove it to avoid unnecessary confusion. Also, again: don't say waiting for old information to expire, but waiting for new information to propagate. * Section 2.3. Summary - KSK Double-Signature has the description "Publish the DNSKEY and RRSIGs at the same time." But actually that is true for all KSK rollovers. In fact, I think this table doesn't have much value and I argue that it can be removed. * Section 3.1. Key States - Repeating myself: These key states are not sufficient to describe the rollover time lines. See the comments below on the rollover time lines. * Section 3.2.1. (ZSK) Pre-Publication Method - Style inconsistency: The first line uses capitals for "Pre-Publication rollover", while in other sections the rollover names are completely lowercased. - A general note on the Events 1: It explains every time why there are different times for key generation and publication. This can be done only once with a note that this is also true for the other Events 1. - Event 8 talks about "an expired DNSKEY RRset in the cache". Seems a contradiction to me. * Section 3.2.2. (ZSK) Double-Signature Method - Event 3: The current key is said to be retired. However, the key state definition of "retired" is: A successor key has become active and this key is no longer being used to generated RRSIGS. But in this rollover, it is required to have the current key generate signatures, otherwise there are no double signatures and the Double-Signature rollover can make the zone go bogus. In short, the key state in this event does not match the key state description. * Section 3.2.3. (ZSK) Double-RRSIG Method - The first line mentions double-signature rollover, should be double-RRSIG. - Event 5: "The key is now said to be active". Actually, according to the key state description, the key was already active earlier: The key has started to be used to sign RRsets. With ZSK Double-RRSIG, the key has started to be used to sign RRsets in Event 2. * Section 3.3.1. (KSK) Double-Signature Method - Event 5: The time that the key becomes active, but the key state description of "active" only takes about creating signatures, not about the so-called security chain. - Event 9: Also the key state description of "retired" doesn't mention the security chain, but is only aligned for ZSK rollovers. These two comments are also for the other KSK time lines. * Section 5. Algorithm Considerations - Paragraph 1: "... using a single algorithm." -> "using the same cryptographic algorithm". * Section 7. Summary - The second paragraph says that the Double-RRset rollover is the most efficient method for KSKs. While this is true if you look at the duration of the rollover, this is not true for the number of parent interactions. In fact, in the following line, the document says that the time take to roll KSKs depends on factors related to the (signed) parent. So if the parent interaction is a slow process, the KSK Double-Signature rollover might even be faster than the Double-RRset method, since it only requires one parent interaction. That's all:) Best regards, Matthijs On 08/23/2012 11:49 PM, 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 > <http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/> > > 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 <http://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc4641bis/> > > 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 <http://tools.ietf.org/wg/dnsop/minutes?item=minutes-84-dnsop.html> > the minutes I follow the mandate to issue the WGLC. Looking forward to your > contributions. > > Best regards, > Peter (as co-chair and doc shepherd) > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
- [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-0… Peter Koch
- Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timi… Edward Lewis
- Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timi… Matthijs Mekking
- Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timi… Johan Ihrén
- Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timi… Matthijs Mekking
- Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timi… Tony Finch
- Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timi… Yuri Schaeffer
- Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timi… Matthijs Mekking
- Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timi… Andrew Sullivan
- Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timi… Matthijs Mekking
- Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timi… Olafur Gudmundsson
- Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timi… Tony Finch
- Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timi… Tony Finch
- Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timi… Peter Koch