Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-05.txt

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 25 September 2014 17:05 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3D91A8730 for <dnsop@ietfa.amsl.com>; Thu, 25 Sep 2014 10:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level:
X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9fDiS9_nXF7 for <dnsop@ietfa.amsl.com>; Thu, 25 Sep 2014 10:05:08 -0700 (PDT)
Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627AF1A872C for <dnsop@ietf.org>; Thu, 25 Sep 2014 10:05:08 -0700 (PDT)
Received: from [10.20.30.90] (142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s8PH53oh034071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Sep 2014 10:05:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87] claimed to be [10.20.30.90]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <54240CD0.7060101@gmail.com>
Date: Thu, 25 Sep 2014 10:05:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4965E4F2-DA65-4594-AF2F-14112F91C530@vpnc.org>
References: <20140917121858.30503.75097.idtracker@ietfa.amsl.com> <541B29CE.5040908@gmail.com> <C3C8B727-1B0C-4DA2-9885-B4AFEC9F3580@vpnc.org> <54240CD0.7060101@gmail.com>
To: Stephen Morris <sa.morris8@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/zouTf-Ffga1uOqfoAXNUwZiSNrs
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-05.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Sep 2014 17:05:10 -0000

On Sep 25, 2014, at 5:38 AM, Stephen Morris <sa.morris8@gmail.com> wrote:

>> In 2.2, it says "It is important to note that this does not 
>> preclude the development of key rollover logic"; I can't figure
>> out what "this" refers to. There are a bunch of things in the two 
>> preceding paragraphs that it might mean.
> 
> How about:
> 
> "It is important to note that the need to interact with the parent
> does not preclude the development of key rollover logic;"

Yes, great. (That was not my first expansion of "this", FWIW.)

>> The introduction to 3.1 caught me, and I can't figure out whether 
>> or not it is right. A DNSSEC key contributes two pieces of 
>> information to the validation process: the DNSKEY itself and the 
>> data created from it.  In the case of the validation of an RR, the 
>> data created from the DNSKEY is the RRSIG.  Where there is a need 
>> to validate a chain or trust, the data created from the DNSKEY is 
>> the DS.  In this section, the term "associated data" refers to the 
>> RRSIGs created from a DNSKEY when discussing a ZSK, or to the 
>> DNSKEY's corresponding DS record when referring to a KSK. Is the 
>> "associated data" for a KSK really just the DS? Shouldn't any
>> RRSIG over the ZSK that was created by the DSKEY also be
>> "associated data"?
> 
> I'm not clear what you mean by "any RRSIG over the ZSK that was
> created by the DSKEY". Do you mean the RRSIG over the DNSKEY RRset
> created by the KSK in question? If so, I take the point that the KSK's
> associated data can be regarded as both a DS record and the RRSIG over
> the DNSKEY RRset and so as written, it is not completely clear.

Yes, exactly that. "or to the DNSKEY's corresponding DS record when referring to a KSK" actually limits it to the DS record.

> I think there are two things relevant for this paragraph:
> 
> * The draft doesn't concern itself with the validation of the DNSKEY
> RRset (i.e. that it is signed by a valid KSK).  So when talking about
> the ZSK, it is taken as read the ZSK has been validated by a KSK.  In
> the case of a KSK, the assumption is that the KSK comes from a DNSKEY
> RRset signed by itself, and so the draft only concerns itself with the
> validation of the KSK against the DS.
> 
> * In virtually all cases, the KSK and the DNSKEY signature created by
> it are added to and removed from the zone together.  They also travel
> together - you always get the RRSIG when you retrieve the DNSKEY. The
> term "associated data" is really trying to capture the idea that in
> some cases the pieces of data required for a validation are obtained
> separately, perhaps at different times.
> 
> I'm not sure whether the above two points need to be clearly spelt out
> in the draft or whether they are clear from the context of the
> discussion.

They were not clear to me.

> If the latter, modifying the paragraph to:
> 
> "A DNSSEC key requires two pieces of information to perform
> validation: the DNSKEY itself and associated data created from it.  In
> the case of the validation of an RR, the data associated with the ZSK
> is the RRSIG.  Where there is a need to validate a chain or trust, the
> associated data is the DS."
> 
> ... may address your point.  If not, an additional subsection in
> section 3 will be required to make the points listed above.

The stuff above makes it clearer, but readers will will still need to do some logic in their heads with it. However, given that this is more of an operational document, you don't really need to lay everything out. The modification is probably fine on its own.


>> Also in 3.1: Ready       The DNSKEY or its associated data have 
>> been published for long enough to guarantee that any previous 
>> versions of the DNSKEY and/or associated data have expired from 
>> caches. This is discussing a new key. What is the "previous 
>> version"?
> 
> How about rewording it as:
> 
> "The DNSKEY or its associated data have been published for long enough
> to guarantee that copies of the key(s) it is replacing (or associated
> data related to that key) have expired from caches."

Yep, fine.

Thanks!

--Paul Hoffman