Subject: Re: [DNSOP] RFC4641bis Editing Status Report.

From: Olaf Kolkman <[email-masked]>
Date: Thu, 8 Jul 2010 14:36:45 +0200

You probably noticed I swapped in the document and tackling issues one-by-one.

On Mar 20, 2010, at 8:51 PM, Chris Thompson wrote:

> On Mar 20 2010, Paul Wouters wrote:
> 
>> On Sat, 20 Mar 2010, Olaf Kolkman wrote:
>> 
>>> - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/NSEC-NSEC3
>> 
>> That still states:
>> 
>> 	"as well as no algorithm choice for SHA-256"
>> 
>> That's been resolved now, see http://www.bind9.net/dns-sec-algorithm-numbers
>> RSASHA256 has DNSKEY algorihtm 8 and RSASHA-512 has alg 10. As far as I
>> know, these include NSEC3, though the registry contains no pointers for that.
> 
> It contains a pointer to RFC 5702, and section 5.2 of RFC5702 is completely
> clear on the subject.
> 
>> Is it noted anywhere that algorithms > 5 imply NSEC3 support? If not, should we?
> 
> I suppose it is still open to DNSEXT to submit new algorithms which imply
> NSEC only, but of course that is not expected to happen. (Anyway, 253 & 254
> are "> 5" and there it's a matter for private agreement.)

Rereading this particular issue it seems that the current text in version 02 ( http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-02#section-5.3.1 ) is convoluting DNS signing algorithms with the NSEC3 digest-algorithm field. I am not quite sure what this section tries to accomplish except for the fact that NSEC3 support is signaled in the algorithm numbers, which I don't think is in scope at this particular place (section 5.3) in the document.

I think that talking about NSEC3 hash algorithm rolover is in scope (in section 5.3) and modified the text to read:

   <t>
	At the moment of writing there is only one NSEC3 Hashing
	algorithm defined. <xref target="RFC5155"/> specifically calls
	out that when a new hash algorithm for use with NSEC3 is
	specified, a transition mechanism MUST also be
	defined. Therefore this document does not considder NSEC3 hash
	algorithm transition.

      </t>

--Olaf

________________________________________________________ 

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

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 19 Jul 2010 12:40:22 +0200

FWIW, 

This has been addressed in draft-03 although I just noticed that the last paragraph of 3.1.4.1. still needs a minor rewrite to reflect availability of SHA 256. (Now there is an inconstancy between giving references to the specs and saying one has to wait for availability).

On Mar 20, 2010, at 8:34 PM, Paul Wouters wrote:

> Paul

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 20 Jul 2010 17:31:57 +0200

Olaf,

here you have diff (against up-to-date SVN) and full text for Key 
Algorithm Rollover.  The attached text was created as joint effort by me 
and Olafur.

Ondrej.

On 20.3.2010 17:10, Olaf Kolkman wrote:
>
>
>
> Colleagues
>
> This is a status update on RFC4641bis. Please refer to links provided for more details on the issues. I have no particular issues I need to discuss in the face to face meeting and will present what is written below in a somewhat condensed form. If folk have something they would like to discuss it is probably best to give a heads-up here.
>
>
> High level summary:
>
> Most changes in the document are with respect to the description about keys and key maintenance (section 3). I've tried to stress the operational tradeoffs and make those the basis of the cryptographic considerations. The idea is that the tradeoff between costs and threats set the operational handling of the keys. Once you know how you want to handle the keys operationally set the appropriate crypto parameters.
>
> Also there is a completely new section on the Next Record types (section 5) and there are considerations added about the changing ones dns operator (section 4.4.5)
>
>
>
>
>
> In detail
> - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/HSMs
> Addressed in a section 3.1.4.3  "Private Key Storage"
> I believe this issue to be resolved.
>
> Complete new section 5.
> There is one remaining point there brought up in
> 	From: 	Florian Weimer<[email-masked]>
> 	Subject: 	Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
> 	Date: 	February 22, 2010 11:20:16 PM PST
> 	To: 	Olaf Kolkman<[email-masked]>
> 	Cc: 	Alex Bligh<[email-masked]>, Paul Wouters<[email-masked]>, dnsop WG<[email-masked]>
>
> NSEC making the packet too big base on the argument that " However, NSEC records are sometimes returned in response to
> DO=0 queries"
>
> I believe there is consensus that that is caused by an implementation bug. Therefore the issue can be closed.
>
>
> - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Review-NIST
>
> Scott reported that this issue can be closed.
>
> - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency
> - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/cryptography_flawed
> - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/discussion_of_timescales
> - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/rollover_assumptions
>
> I believe these issues where addressed by reordering and rewriting parts of section 3. But this section may need a little more work to clarify that the approach is from operational perspective rather than a highest achievable crypto perspective.
>
> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/non-cooperative-registrars
> Added as:
> 4.4.5.2.  Non Cooperationg DNS Operators
>
> This issue is resolved although a review of the supporting figure is needed.
>
>
>
> The following issues have not yet been addressed and the issue needs to be reviewed on relevance against the current version
>
> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_and_parent_keys
> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent
> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration
> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/timing_terminology
>
>
> I've added
> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Signature_validity
>  From the recent mail from Sebastian where he asks for guidance on signature validity intervals
>
> that is an issue that is probably closely related to
>
> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/timing_terminology
>
> which I will address in the next version.

-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------
Index: Key_algorithm_roll
===================================================================
--- Key_algorithm_roll	(revision 63)
+++ Key_algorithm_roll	(working copy)
@@ -55,55 +55,104 @@
 
    Because of the algorithm downgrade protection in RFC4035 section 2.2,
    you may not have a key of an algorithm for which you do not have
-   signatures.
+   signatures, and you may not have a DS record in the parent zone of an
+   algorithm for which you don't have a corresponding key in the zone
+   apex.
 
    When adding a new algorithm, the signatures should be added first.
-   After the TTL has expired, and caches have dropped the old data
-   covered by those signatures, the DNSKEY with the new algorithm can be
-   added.  When removing an old algorithm, the DNSKEY should be removed
-   first.
+   After the TTL of RRSIGS has expired, and caches have dropped the
+   old data covered by those signatures, the DNSKEY with the new
+   algorithm can be added.
 
-   To do both, the following steps can be used.  For simplicity, we use
-   a zone that is only signed by one zone signing key.
+   After the new algorithm has been added, the DS record can be
+   exchanged using Double Signature Key Rollover.  You cannot use
+   Pre-publish key rollover method when you do key algorithm rollover.
 
+   When removing an old algorithm, the DNSKEY should be removed first,
+   but only after the DS for the old algorithm was removed from the
+   parent zone.
+
+   To do both, the following steps can be used.  For clarity, we use one
+   key signing key and one zone signing key for each algorithm.  In
+   following table, we assume that DNSKEY_KSK_1 and DNSKEY_ZSK_1 are
+   DNSKEYS with the old algorithm and DNSKEY_KSK_2 and DNSKEY_ZSK_2 are
+   DNSKEYS with the new algorithm.
+
    ----------------------------------------------------------------
-   1 Initial           2 New RRSIGS       3 New DNSKEY
+   1 Initial            2 New RRSIGS         3 New DNSKEY
    ----------------------------------------------------------------
-   SOA0                SOA1               SOA2
-   RRSIG1(SOA0)        RRSIG1(SOA1)       RRSIG1(SOA2)
-                       RRSIG2(SOA1)       RRSIG2(SOA2)
+ Child:
+   SOA0                 SOA1                 SOA2
+   RRSIG_ZSK_1(SOA0)    RRSIG_ZSK_1(SOA1)    RRSIG_ZSK_1(SOA2)
+                        RRSIG_ZSK_2(SOA1)    RRSIG_ZSK_2(SOA2)
 
-   DNSKEY1             DNSKEY1            DNSKEY1
-   RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     DNSKEY2
-                       RRSIG2(DNSKEY)     RRSIG1(DNSKEY)
-                                          RRSIG2(DNSKEY)
+   DNSKEY_KSK_1         DNSKEY_KSK_1         DNSKEY_KSK_1
+   DNSKEY_ZSK_1         DNSKEY_ZSK_1         DNSKEY_ZSK_1
+   RRSIG_KSK_1(DNSKEY)  RRSIG_KSK_1(DNSKEY)  DNSKEY_KSK_2
+                        RRSIG_KSK_2(DNSKEY)  DNSKEY_ZSK_2
+                                             RRSIG_KSK_1(DNSKEY)
+                                             RRSIG_KSK_2(DNSKEY)
+
+   RRSIG_ZSK_1(*)       RRSIG_ZSK_1(*)       RRSIG_ZSK_1(*)
+                        RRSIG_ZSK_2(*)       RRSIG_ZSK_2(*)
+
+
+ Parent:
+   SOA0                 SOA0                 SOA0
+   RRSIGpar(SOA0)       RRSIGpar(SOA0)       RRSIGpar(SOA0)
+   DS_KSK_1             DS_KSK_1             DS_KSK_1
+   RRSIGpar(DS_KSK_1)   RRSIGpar(DS_KSK_1)   RRSIGpar(DS_KSK_1)
+
    ----------------------------------------------------------------
-   4 Remove DNSKEY     5 Remove RRSIGS
+   4 Exchange DS        5 Remove DNSKEY      6 Remove RRSIGS
    ----------------------------------------------------------------
-   SOA3                SOA4
-   RRSIG1(SOA3)        RRSIG2(SOA4)
-   RRSIG2(SOA3)
+   SOA2                 SOA3                 SOA4
+   RRSIG_ZSK_1(SOA3)    RRSIG_ZSK_1(SOA3)    RRSIG_ZSK_2(SOA4)
+   RRSIG_ZSK_2(SOA3)    RRSIG_ZSK_2(SOA3)
 
-   DNSKEY2             DNSKEY2
-   RRSIG1(DNSKEY)      RRSIG2(DNSKEY)
-   RRSIG2(DNSKEY)
+   DNSKEY_KSK_1         DNSKEY_KSK_2         DNSKEY_KSK_2
+   DNSKEY_ZSK_1         DNSKEY_ZSK_2         DNSKEY_ZSK_2
+   DNSKEY_KSK_2         RRSIG_KSK_1(DNSKEY)  RRSIG_KSK_2(DNSKEY)
+   DNSKEY_ZSK_2         RRSIG_KSK_2(DNSKEY)
+   RRSIG_KSK_1(DNSKEY)
+   RRSIG_KSK_2(DNSKEY)
+
+   RRSIG_ZSK_1(*)       RRSIG_ZSK_1(*)       RRSIG_ZSK_2(*)
+   RRSIG_ZSK_2(*)       RRSIG_ZSK_2(*)
+
+ Parent:
+   SOA1                 SOA1                 SOA1
+   RRSIGpar(SOA1)       RRSIGpar(SOA1)       RRSIGpar(SOA1)
+   DS_KSK_2             DS_KSK_2             DS_KSK_2
+   RRSIGpar(DS_KSK_2)   RRSIGpar(DS_KSK_2)   RRSIGpar(DS_KSK_2)
+
    ----------------------------------------------------------------
 
    Stages of Deployment during an Algorithm Rollover.
 
-   In step 2, the signatures for the new key are added, but the key
-   itself is not.  While in theory, the signatures of the keyset should
-   always be synchronized with the keyset itself, it can be possible
-   that RRSIGS are requested separately, so it might be prudent to also
-   sign the DNSKEY set with the new signature.
+   Step 1 describes state of the zone before any transition is done.
+   Number of the keys may vary, but the algorithm of keys in the zone is
+   same for all DNSKEY records.
 
-   After the cache data has expired, the new key can be added to the
-   zone, as done in step 3.
+   In step 2, the signatures for the new key for all records in the zone
+   are added, but the key itself is not.  This includes the signature
+   for the DNSKEY rrset.  While in theory, the signatures of the keyset
+   should always be synchronized with the keyset itself, it can be
+   possible that RRSIGS are requested separately, so it might be prudent
+   to also sign the DNSKEY set with the new signature.
 
-   The next step is to remove the old algorithm.  This time the key
-   needs to be removed first, before removing the signatures.  The key
-   is removed in step 4, and after the cache data has expired, the
-   signatures can be removed in step 5.
+   After the cached data for all RRSIGS in the zone has expired, the new
+   key can be added to the zone, as done in step 3.
 
+   After the cache data for the DNSKEY has expired, the DS record for
+   the new key can be added to the parent zone and the DS record for the
+   old key can be removed in the same step.
+
+   After the cache data for the DS has expired, the old algorithm can
+   be removed.  This time the key needs to be removed first, before
+   removing the signatures.  The key is removed in step 5, and after
+   the cache data for the DNSKEY has expired, the signatures can be
+   removed in step 5.
+
    The above steps ensure that during the rollover to a new algorithm,
    the integrity of the zone is never broken.

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 21 Jul 2010 15:07:06 +0200

On Jul 20, 2010, at 5:31 PM, Ondřej Surý wrote:

> Olaf,
> 
> here you have diff (against up-to-date SVN) and full text for Key Algorithm Rollover.  The attached text was created as joint effort by me and Olafur.
> 
> Ondrej.
> 

Thanks Ondrej and Olafur,

Turns out that you pulled the text from the SVN just a little early and that I had already modified the table in a way similar to how you modified the table.. :-). Besides the text had changed slightly so the diff did apply cleanly.

Anyway, I did copy most of your suggestions. Except that I did not want to clutter the table with RRSIG_ZSK_1(*) since the SOA signature already represents that. I did make a note about that representation in the text leading to the table. Adding the parent is off value, but I choose to follow the representation as in 4.1.2. 

Also version 3 of the draft had a paragraph about introducing NSEC3, I believe you have special experience in that field, and that paragraph needs careful review.

In any case the section now reads as below. I would appreciate a review to see if this is according to your liking.
Also see http://tinyurl.com/27odxco for the diffs abains I-D-03 and http://www.secret-wg.org/draft-ietf-dnsop-rfc4641bis.txt for the version on the trunk.

--Olaf

4.1.5.  Key algorithm rollover

   A special class of key rollover is the one needed for a change of key
   algorithms (either adding a new algorithm, removing an old algorithm,
   or both).  Additional steps are needed to retain integrity during
   this rollover.

   Because of the algorithm downgrade protection in RFC4035 section 2.2,
   you may not have a key of an algorithm for which you do not have
   signatures, and you may not have a DS record in the parent zone of an
   algorithm for which you don't have a corresponding key in the zone
   apex.

   When adding a new algorithm, the signatures should be added first.
   After the TTL of RRSIGS has expired, and caches have dropped the old
   data covered by those signatures, the DNSKEY with the new algorithm
   can be added.

   After the new algorithm has been added, the DS record can be
   exchanged using Double Signature Key Rollover.  You cannot use Pre-
   publish key rollover method when you do key algorithm rollover.

   When removing an old algorithm, the DNSKEY should be removed first,
   but only after the DS for the old algorithm was removed from the
   parent zone.

   The following figure describes the steps.  Whereby the trailing
   underscored number indicates the algorithm and ZSK and KSK indicate
   the obvious difference in key use.  For example DNSKEY_KSK_1 is a the
   DNSKEY RR representing the public part of the old key signing key of
   algorithm type 1 while RRSIG_ZSK_2(SOA3) is the RRSIG RR made with
   the private part of the new zone signing key of algorithm type 2 over
   a SOA RR (that has serial number 3).  It is assumed that the key that
   signes the SOA RR also signes all other non-DNSKEY RRset data.

Kolkman                 Expires January 13, 2011               [Page 26]
Internet-Draft   DNSSEC Operational Practices, Version 2       July 2010

   ----------------------------------------------------------------
   1 Initial            2 New RRSIGS         3 New DNSKEY
   ----------------------------------------------------------------
   Parent:
    SOA0                 -------------- ( SOA0 )-------------->
    RRSIGpar(SOA0)       ------------------------------------->
    DS_KSK_1             ------------------------------------->
    RRSIGpar(DS_KSK_1)   ------------------------------------->

   Child:
    SOA0                 SOA1                 SOA2
    RRSIG_ZSK_1(SOA0)    RRSIG_ZSK_1(SOA1)    RRSIG_ZSK_1(SOA2)
                         RRSIG_ZSK_2(SOA1)    RRSIG_ZSK_2(SOA2)

    DNSKEY_KSK_1         DNSKEY_KSK_1         DNSKEY_KSK_1
    DNSKEY_ZSK_1         DNSKEY_ZSK_1         DNSKEY_ZSK_1
    RRSIG_KSK_1(DNSKEY)  RRSIG_KSK_1(DNSKEY)  DNSKEY_KSK_2
                         RRSIG_KSK_2(DNSKEY)  DNSKEY_ZKS_2
                                              RRSIG_KSK_1(DNSKEY)
                                              RRSIG_KSK_2(DNSKEY)
   ----------------------------------------------------------------
   4 Exchange DS         5 Remove DNSKEY      6 Remove RRSIGS
   ----------------------------------------------------------------
   Parent:
    SOA1                 -------------( SOA1 )---------------->
    RRSIGpar(SOA1)       ------------------------------------->
    DS_KSK_2             ------------------------------------->
    RRSIGpar(DS_KSK_2)   ------------------------------------->

   Child:
    ---- (SOA2 ) --->    SOA3                 SOA4
    ---------------->    RRSIG_ZSK_1(SOA3)    RRSIG_ZSK_2(SOA4)
    ---------------->    RRSIG_ZSK_2(SOA3)

    ---------------->    DNSKEY_KSK_2         DNSKEY_KSK_2
    ---------------->    DNSKEY_ZSK_2         DNSKEY_ZSK_2
    ---------------->    RRSIG_KSK_1(DNSKEY)  RRSIG_KSK_2(DNSKEY)
    ---------------->    RRSIG_KSK_2(DNSKEY)
   ----------------------------------------------------------------

   Step 1 describes state of the zone before any transition is done.
   Number of the keys may vary, but the algorithm of keys in the zone is
   same for all DNSKEY records.

   Step 2: the signatures made with the new key over all records in the

Kolkman                 Expires January 13, 2011               [Page 27]
Internet-Draft   DNSSEC Operational Practices, Version 2       July 2010

   zone are added, but the key itself is not.  This includes the
   signature for the DNSKEY rrset.  While in theory, the signatures of
   the keyset should always be synchronized with the keyset itself, it
   can be possible that RRSIGS are requested separately, so it is
   prudent to also sign the DNSKEY set with the new signature.

   Step 3: After the cache data has expired, the new key can be added to
   the zone.

   Step 4: After the cache data for the DNSKEY has expired, the DS
   record for the new key can be added to the parent zone and the DS
   record for the old key can be removed in the same step.

   Step 5: After the cache data for the DS has expired, the old
   algorithm can be removed.  This time the key needs to be removed
   first, before removing the signatures.  The key is removed in this
   step , and after the cache data for the DNSKEY has expired, the
   signatures can also be removed during this step.

   [OK:The following paragrapgh is provisional and needs careful
   review.]

   A special case is the rollover from an NSEC signed zone to an NSEC3
   signed zone.  In this case algorithm numbers are used to signal
   support for NSEC3 but they do not mandate the use of NSEC3.
   Therefore NSEC records should remain in the zone until the rollover
   to a new algorithm has completed and the new DNSKEY RR set has
   populated distant caches(at least one TTL into stage 4, or at any
   time during stage 5).  At that point the validators that have not
   implemented NSEC3 will treat the zone as unsecured as soon as they
   follow the chain of trust to DS that points to a DNSKEY of the new
   algorithm while validators that support NSEC3 will happily validate
   using NSEC.  Turning on NSEC3 can then be done when changing from
   zone serial number, realizing that that involves a resigning of the
   zone and the introduction of the NSECPARAM record in order to signal
   authoritative servers to start serving NSEC3 authenticated denial of
   existence.