[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)
- [DNSOP] draft-ietf-dnsop-dnssec-key-timing-06 - K… Matthijs Mekking
- Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-06… Tim Wicinski