- ksk-rollover - lists.icann.org

[ksk-change] Narrowing the objective of the workshop
by Paul Hoffman Sept. 22, 2014

Sept. 22, 2014

Greetings. RFC 5011 has very different implications for (a) a root zone with one strong and one weak key, (b) a root zone with two equivalently strong keys, (c) a root zone with multiple strong keys, and so on. Similarly, out-of-band changes to the root zone are very different if they are supposed to replace a root zone key or add a root zone key. The initial message for this list said: Objective The purpose of this workshop is to discuss the operational considerations of future root zone KSK rollovers, to inform the process of planning and executing with maximum visibility and minimum opportunity for disruption. In order to bound the discussion somewhat and make it more useful, I propose a minor modification: The purpose of this workshop is to discuss the operational considerations of KSK changes for the current root zone, to inform the process of planning and executing with maximum visibility and minimum opportunity for disruption. That is, my preference is that this discussion is focused on the current root zone (which has one RSA2048 KSK and one RSA1024 ZSK), and the changes that could be made to that specific root zone. If the root zone changes (and I certainly hope it does), a future discussion can be about that different root zone. Does this limitation on the discussion make sense? --Paul Hoffman

1 0

[ksk-change] Capabilities of validating systems we need to consider
by Paul Hoffman Sept. 22, 2014

Sept. 22, 2014

Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities: 1) Able to automatically pull and correctly use a new KSK 2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention 3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK Are there other categories that would look operationally different to either customers of the system or to operators of signed zones? We will certainly later debate how many systems are in these categories and if those systems are "important", but it would be good to start with the smallest complete set to talk about. --Paul Hoffman

5 9

[ksk-change] Not rolling over, part 2: adding another signing algorithm
by Paul Hoffman Sept. 21, 2014

Sept. 21, 2014

Greetings. Joe and David have said that the intended meeting can cover issues other than a key rollover, and the earlier thread points to something that ICANN might want to do before, after, or instead of a key rollover exercise: add a different key with a different signature algorithm, presumably an elliptic curve algorithm with 256-bit keys. This could be done with the intention of having the two signatures in parallel for a long time, or it could be done with the intention that the shorter, stronger, more reliable key replaces the current key. --Paul Hoffman

1 0

[ksk-change] Not rolling over, part 1: adding additional KSKs
by Paul Hoffman Sept. 21, 2014

Sept. 21, 2014

Greetings. Joe and David have said that the intended meeting can cover issues other than a key rollover, and this morning's thread points to something that ICANN might want to do before, after, or instead of a key rollover exercise: add one or more KSKs to the current one. --Paul Hoffman

1 0

root zone KSK rollover vendor workshop
by Joe Abley Sept. 18, 2014

Sept. 18, 2014

Hi again, Further to the message I just sent to this list, a second, related, workshop is also being planned for ICANN week in LA: the focus of that workshop is constrained to interop testing between deployed DNSSEC products in the context of a root zone KSK rollover. In keeping with most interoperability tests, that workshop will be a closed event in order to promote productivity, with a summary of results to be made public (without attribution) as input into discussions related to rolling the root zone KSK. In particular, since the vendor workshop is scheduled the day before the ops workshop, we expect to be able to bring a summary to the ops workshop on Thursday. If you are a vendor of DNSSEC validator software or operate significant DNSSEC validator infrastructure, you may well be interested in attending. Let us know. For final, ultimate clarity, and for great justice: Root Zone KSK Rollover Workshops at ICANN 51 Wednesday October 15, 2014: Vendor interop workshop (invitation only) Thursday October 16, 2014: Operations workshop (open, remote participation available) Joe

1 0

key length recomendations
by Richard Lamb Sept. 15, 2014

Sept. 15, 2014

Should anyone be considering more than a roll ;-) Tomofumi Okubo pointed this one out http://www.keylength.com/en/compare/

1 0