[DNSOP] Timing of key changes (some things that hit me right away)
Edward Lewis <Ed.Lewis@neustar.biz> Wed, 11 November 2009 02:14 UTC
Return-Path: <Ed.Lewis@neustar.biz>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8F03A6BEA for <dnsop@core3.amsl.com>; Tue, 10 Nov 2009 18:14:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.751
X-Spam-Level:
X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B49tLpc-XkK for <dnsop@core3.amsl.com>; Tue, 10 Nov 2009 18:14:48 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 2F7533A69C1 for <dnsop@ietf.org>; Tue, 10 Nov 2009 18:14:46 -0800 (PST)
Received: from [133.93.114.63] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id nAB2F0GQ008131; Tue, 10 Nov 2009 21:15:03 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: <a06240801c71fc3a37c12@[133.93.114.63]>
Date: Wed, 11 Nov 2009 11:09:43 +0900
To: jad@jadickinson.co.uk, johani@autonomica.se, stephen@nominet.org.uk, dnsop@ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20
Cc: dnsop@ietf.org, ed.lewis@neustar.biz
Subject: [DNSOP] Timing of key changes (some things that hit me right away)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 11 Nov 2009 02:14:50 -0000
http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-01 I really wish that the ZSK/KSK division in terminology was replaced by SEP and non-SEP. That is the "real difference" (based on there being an SEP bit in the key flags, not a KSK/ZSK bit). It's possible that a ZSK is also an SEP, the rules for SEP change then apply to the ZSK. >2.3. Comparison of Rollover Methods > ... > > Pre-publication is more complex - introduce the new key, one TTL > later sign the records, and one TTL after that remove the old key. > However, the amount of DNSSEC data is kept to a minimum, hence > reducing the impact on performance. This above paragraph is missing something. "and one TTL after that" should be replaced with "and one TTL after replacing all of the old signatures with new signatures". (To make this a bit more clearer:) From and one TTL after that To and one TTL after replacing all of the old signatures with new signatures ------------------------------------------------------- The time to replace all of the old signatures with new signatures grows with the size and churn of a zone. It some cases it will be done in a flash, in some on the order of a week. 2.3's second paragraph should read Pre-publication is more complex - introduce the new key, one TTL later sign the records, and one TTL after replacing all of the old signatures with new signatures remove the old key. However, the amount of DNSSEC data is kept to a minimum, hence reducing the impact on performance. Later on, >3. Zone-Signing Keys > >3.1. Key Timeline ... > Event 6: while the current ZSK is still active, its successor becomes > ready. From this time onwards, it could be used to sign the zone. From this time onwards, signatures generated by the predecessor are replaced with newly generated signatures with the successor until all of the predecessor signatures are removed. In addition, any new signatures required as a change to the zone contents are generated with the successor. (The span of time from Event 6 to Event 7 might not be "trivially small.") One general thought, IMHO, reducing the number of flash-cut events in favor of gradual changes is desirable for stability and scalability reasons. In a way, a zone could be seen in a state of continual key change. >3.2. Key States > > An alternative way of considering the key timeline is to regard the > key as moving through a set of states, the state transitions being > determined by time. The state transition diagram is linear and is > shown in Figure 2: > > > > +-----------+ +-----------+ +-----------+ > Start ---->| Generated |----->| Published |----->| Ready | > Tgen +-----------+ Tpub +-----------+ Trdy +-----------+ > | > +-----------+ | > +------------| Active |<-----------+ > | Tret +-----------+ Tact > V > +-----------+ +-----------+ +-----------+ > | Retired |----->| Dead |----->| Removed | > +-----------+ Tdea +-----------+ Trem +-----------+ > > > Figure 2: ZSK State Diagram. The state diagram omits "Exposed" and "Lost". By "exposed" I include a few failure states: 1) The key is witnessed by an unauthorized entity (i.e., exposed) 2) The key is reverse engineered via crypto-analysis (by James Bond maybe) 3) The key is found in a dictionary attack (I generate key pairs and match the public one) 4) etc. By "lost" I mean: 1) The (lone) disk is it on crashed (or all disks it was on crashed). 2) Someone left the laptop in the airport lounge and it was destroyed by the authorities. 3) Olafur's daughter did a "sudo rm -fr /" to revenge Dad's trip to the IETF some years back. (No, she just tripped the power cord at home - but it could have been worse!) I would draw lines from Published, Ready, Active, and even Retired to Exposed and Lost. Then from Exposed to Retired and from Lost to Dead. Just because a key is compromised (exposed) doesn't mean all uses of it is bad. Don't screw over 95% of the population that the attack isn't directed at to save the 5% that is hit. >4.5. Key States > > The key states for a KSK during the rollover are identical to those > in Figure 2. I disagree with that. You need a state that represents "I asked the parent to change but they haven't responded" and a state "I told a gaggle of TARs I am changing and am waiting for them to catch up." The states for SEP differ because you are waiting on external entities to react to events you generate. For SEP and RFC 5011, the difference between "Exposed" and "Lost" is profound - you can't "sign the revoked key" if you have lost the private key. >5. Algorithm Considerations > > The preceding sections have implicitly assumed that all keys and > signatures are created using a single algorithm. However, [RFC4035] > (section 2.4) states that "There MUST be an RRSIG for each RRset > using at least one DNSKEY of each algorithm in the zone apex DNSKEY > RRset". The "however" is an incorrect linkage... The first sentence has no bearing on the second. ;) Perhaps the second sentence ought to be "Nevertheless, a zone may use multiple algorithms for DNSSEC, or even be in transition from one algorithm to another over time." (The latter is where I thought you were going - algorithm change.) > Except in the case of an algorithm rollover - where the algorithms > used to create the signatures are being changes - there is no > relationship between the keys of different algorithms. This means > that they can be rolled independently of one another. (Indeed, the > keys for each algorithm could, if desired, have different TTLs.) In... Keys are all in the DNSKEY RRset, regardless of algorithm - they have to have the same TTL. RRSIGs are supposed (as in SHOULD) to be the same as the data they cover. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.
- [DNSOP] Timing of key changes (some things that h… Edward Lewis