[DNSOP] draft-ietf-dnsop-dnssec-key-timing-06 - KSK Double RRset issue

Matthijs Mekking <matthijs@pletterpet.nl> Thu, 05 March 2015 13:33 UTC

Return-Path: <matthijs@pletterpet.nl>
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 5FD8B1B2C8B for <dnsop@ietfa.amsl.com>; Thu, 5 Mar 2015 05:33:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level:
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LITTLE=1.555, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5] 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 A2GhmDjOGzE1 for <dnsop@ietfa.amsl.com>; Thu, 5 Mar 2015 05:33:25 -0800 (PST)
Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 B24531B2C7C for <dnsop@ietf.org>; Thu, 5 Mar 2015 05:33:24 -0800 (PST)
Received: from [IPv6:2001:981:19be:1:bc92:6708:5ff3:ffda] (unknown [IPv6:2001:981:19be:1:bc92:6708:5ff3:ffda]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 302AFBFE; Thu, 5 Mar 2015 14:33:23 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl
Message-ID: <54F85B22.4080603@pletterpet.nl>
Date: Thu, 05 Mar 2015 14:33:22 +0100
From: Matthijs Mekking <matthijs@pletterpet.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: 'IETF DNSOP WG' <dnsop@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/yyhyiA8vsyAgQCu6kKAMHwjCdKw>
Cc: draft-ietf-dnsop-dnssec-key-timing.chairs@tools.ietf.org, draft-ietf-dnsop-dnssec-key-timing.authors@tools.ietf.org
Subject: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-06 - KSK Double RRset issue
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, 05 Mar 2015 13:33:28 -0000

Dear WG,

tl;dr: We found an issue and requires changes in the final rollover
diagram text and would like your feedback on it.

draft-ietf-dnsop-dnssec-key-timing-06.txt has gone through IETF Last
Call and IESG and minor, non-blocking issues were raised, resulting in
minor corrections and additions of clarifying text. See the differences
here:

    https://github.com/DNSOP/dnssec-key-timing/compare/v06-corrections

However, the authors feel that one minor issue raised by Joel during the
GenArt review should be resolved with some non-trivial changes. This
review was sent to the list on 28 Nov 2014:

Joel Halpern wrote:
> Minor issues:
> It is unclear to this reader why in 3.2.1, 3.3.1, and 3.3.2 Iret is
> after Lzsk/Lksk ends, while in 3.2.2 Iret is before Lzsk, so as to
> ensure that Iret completes before Lksk retires.  I suspect that this
> is a reader issue rather than a correctness issue.

This is indeed a reader issue, IMHO. To clarify:

Iret is the interval that the key needs to remain in the zone before it
is considered dead, after the successor key has become active. Thus, the
retire interval (Iret) always starts when the new key becomes active:
when Lzsk/Lksk of the new key starts.

Usually this interval occurs after the lifetime of the outgoing key.

In 3.2.2, ZSK Double-Signature Method, it is required that both keys are
actively signing RRsets for a small period, both keys are active for a
small amount of time. Hence, the retire interval Iret overlaps with the
lifetime of the ZSK, Lzsk.

This is also true for 3.3.3, KSK Double-RRSet Method.

Now for the real issue:

We noticed that 3.3.3, KSK Double-RRset Method has no retire interval,
it is hidden in the publication interval. Note that this rollover method
is quite similar to the ZSK Double-Signature Method (3.2.2): In both
cases, all the information needed for Key N+1 is published and, once
that has reached downstream validators, the information for key N can be
removed.

In the ZSK rollover, we call that time the retire interval of Key N.
In the KSK rollover we call it the publication interval of Key N+1.

We think it is best to change the KSK Double-RRset section so that it is
truly more similar to the ZSK Double-Signature Method. Also, the new
text and diagram (see below) represent the rollover more accurate.

The proposed changes are:
* Adding Dreg and Iret to the diagram for more clarity.
* Adding an equation for Tpub(N+1)
* Adapted the equations to the new terms.

We appreciate your feedback!

Old diagram:

                      |1|      |2|     |3|      |4|      |5|
                       |        |       |        |        |
        Key N          |<-Ipub->|<-----Lksk----->|<------>|
                       |        |       |        |        |
        Key N+1        |        |       |<-Ipub->|<------Lksk--- - -
                       |        |       |        |        |
        Key N         Tpub     Tact             Tret     Trem
        Key N+1                        Tpub     Tact

                         ---- Time ---->

            Figure 5: Timeline for a Double-RRset KSK rollover.

Proposed new diagram and text:


                       |1|       |2|      |3|      |4|    |5|
                        |         |        |        |      |
          Key N         |<-----------Lksk---------->|<---->|
                        |         |        |        |      |
                        |         |<------Ipub----->|      |
                        |         |        |        |      |
                        |         |<-Dreg->|<-Iret->|      |
                        |         |        |        |      |
          Key N+1       |         |        |<----Lksk-------- - -
                        |         |        |        |      |
          Key N        Tact               Tret     Tdea   Trem
          Key N+1                Tpub     Tact


                       ---- Time ---->

             Figure 5: Timeline for a Double-RRset KSK rollover.

   Event 1: The DS and DNSKEY records have appeared in their respective
   zones and the latter has been used to sign the DNSKEY RRset.   The
   key is published and active: this is key N's activation  time (Tact).

   Event 2: As the current key (key N) approaches the end of its
   actual lifetime (Lksk), the successor key (key N+1) is introduced
   into the zone and is used to sign the DNSKEY RRset.  At the same
   same time, the successor DS record is submitted to the parent zone.
   This is the publication time of the successor key (Tpub):

            Tpub(N+1) = Tact(N) + Lksk - Ipub

   ... where Ipub is defined below.

   Event 3: After the registration delay (Dreg), the DS record appears
   in the parent zone.  The DNSKEY record is already in the child zone,
   so with both the new key and its associated data now visible, this is
   the key's activation time (Tact) and the key is now said to be
   active.

             Tact(N+1) = Tpub(N+1) + Dreg

   Event 4: Before key N and its associated data can be withdrawn, all
   RRsets in the caches of validating resolvers must contain the new DS
   and/or DNSKEY.  The time at which this occurs is the dead time of
   key N (Tdea), given by:

             Tdea(N) = Tpub(N+1) + Ipub

   Ipub is the time it takes to guarantee that any prior cached
   information about the DNSKEY and the DS RRsets have expired. For the
   DNSKEY, this is the publication interval of the child (IpubC). For
   the DS, the publication interval (IpubP) starts once the record
   appears in the parent zone, which is Dreg after it has been
   submitted.  Hence:

             Ipub = max(Dreg + IpubP, IpubC)

   The parent zone's publication interval is given by:

             IpubP = DprpP + TTLds

   where DprpP is the parent zone's propagation delay and TTLds is the
   TTL of the DS record in that zone.

   The child zone's publication interval is given by a similar equation:

             IpubC = DprpC + TTLkey

   where DprpC is the propagation delay in the child zone and TTLkey
   the TTL of a DNSKEY record.

   In analogy with other rollovers, we can also define a retire
   interval - the interval between a key becoming active and the time
   at which its predecessor is considered dead.  In this case, Iret is
   given by:

             Iret = Ipub - Dreg

   In other words, the retire interval of the predecessor key is the
   greater of the publication interval of the parent, or the publication
   interval of the child minus the registration delay.

   Event 5: At some later time, the key N's DS and DNSKEY records are
   removed from their respective zones.  In analogy with other rollover
   methods, this is the removal time (Trem), given by:

             Trem(N) >= Tdea(N)