Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14

Olafur Gudmundsson <ogud@ogud.com> Mon, 10 September 2012 15:19 UTC

Return-Path: <ogud@ogud.com>
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 C721321F86F7 for <dnsop@ietfa.amsl.com>; Mon, 10 Sep 2012 08:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 leaFckXAchDz for <dnsop@ietfa.amsl.com>; Mon, 10 Sep 2012 08:19:51 -0700 (PDT)
Received: from smtp195.iad.emailsrvr.com (smtp195.iad.emailsrvr.com [207.97.245.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1E12C21E803C for <dnsop@ietf.org>; Mon, 10 Sep 2012 08:19:50 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp29.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 922B31483FC; Mon, 10 Sep 2012 11:19:49 -0400 (EDT)
X-Virus-Scanned: OK
Received: by smtp29.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 367211483BA; Mon, 10 Sep 2012 11:19:47 -0400 (EDT)
Message-ID: <504E050E.7070002@ogud.com>
Date: Mon, 10 Sep 2012 11:19:42 -0400
From: Olafur Gudmundsson <ogud@ogud.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Peter Koch <pk@DENIC.DE>
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
Cc: IETF DNSOP WG <dnsop@ietf.org>
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: Mon, 10 Sep 2012 15:19:51 -0000

On 23/08/2012 17:49, 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.
>

General comments:
The document in introduction indicates that its target audience is
"zone manager". I think the main audience are:
       DNS zone tool developers,
       zone operator/manager
       domain policy specifier.
Each one has its own "desires" from the document, the document does a 
decent job of offering guidance to all.
I would like to see a short addition to the introduction addressing
this.

The document has fair amount of repeated text and definitions and his
makes it harder to read the whole document but on the other hand it
makes it easy to read a single section w/o having to make many lookups
to more definitions. The way the document is written it makes it
easy to make to just go into the relevant section. Introduction
should mention that the goal of the document is allow easy
use of "single method" w/o having to read the whole document.

I'm not sure that I agree that the definitions used in the document are 
in appendix rather than in an early section.

Overall I like the document and support its publication.
Few minor nits below:

Section 2.2 and 2.3.
The document says that Pre-Publication is not applicable to KSK
rollover, this is wrong as new KSK can be added to the childs DNSKEY
RRset without signing the DNSKEY RRset, there is nothing in the
protocol specifcation that prevents this.
I agree using this methold results in a more complicated rollover
than any of the others as the signature by the new key needs to be
added before the DS is changed.
In effect the result is overly complicated
NEW DNSKEY --> NEW RRSIG --> NEW DS --> del Old DNSKEY --> del OLD DS
or
NEW DNSKEY --> NEW DS --> NEW RRSIG --> del old DS --> del OLD DNSKEY
NEW DNSKEY --> NEW DS --> NEW RRSIG --> del old DNSKEY --> del old DS

So for accuracy I think the document should say "overly complicated
with no addvantages thus not recommended"

Section 4
The description of Double-DS method is a little be short, and does
not explicitly point out the main advantage of the method, i.e.
no parental involvment is required to start using a the new key.


	Olafur