September 2014 - ksk-rollover

[ksk-change] Background Info: Public comments on KSK rollover from early 2013, also SSAC report
by Dan York Sept. 25, 2014

Sept. 25, 2014

A question was raised back in the early threads about the perceived operational reasons to roll the KSK. I think for some of that we can go back to the public consultation ICANN performed about the KSK rollover back in early 2013: https://www.icann.org/public-comments/root-zone-consultation-2013-03-08-en A report summarizing the public comments is available here: https://www.icann.org/en/system/files/files/report-comments-root-zone-consu… That document also contains the list of "ICANN Recommendations" that were given to the ICANN Board. The public comments themselves, many submitted by people on this list including myself, are available individually here: http://forum.icann.org/lists/comments-root-zone-consultation-08mar13/ Additionally, SSAC released SAC063 with their advice on DNSSEC Key Rollover in November 2013: https://www.icann.org/en/system/files/files/sac-063-en.pdf All of those documents do provide some background information into the views of various people and organizations into the implications of a KSK rollover and also motivation for the views of most that we need to roll the KSK sooner rather than later. I would also note that on November 21, 2013, the ICANN Board adopted a resolution directing ICANN's President and CEO to evaluate the SSAC advice and provide a recommendation to the board regarding the acceptance of that advice within 90 days: https://features.icann.org/board-advice#advice-to-board_f=dnssec%20key%20ro… ... which would have been back in March 2014. As Joe Abley mentioned in another thread, the subsequent IANA Transition issue seems to have taken priority over this (and most other actions). Regards, Dan -- Dan York Senior Content Strategist, Internet Society york(a)isoc.org<mailto:york@isoc.org> +1-802-735-1624 Jabber: york(a)jabber.isoc.org<mailto:york@jabber.isoc.org> Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/

1 0

root zone KSK rollover operations workshop planning
by Joe Abley Sept. 25, 2014

Sept. 25, 2014

Greetings, Some notes about our upcoming operational discussions regarding future root zone KSK rollover follow, including a heartfelt request for input on the agenda. 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. Logistics Attendance: Open, remote participation available Location: Brentwood Room Hyatt Regency Century Plaza, LA (ICANN 51 meeting venue) Date: Thursday, October 16, 2014 Time: TBA (will pass on details as soon as we have them) Remote Participation: TBA (same with this) Agenda Your input and guidance is humbly requested to flesh out a high-level agenda. Possible topics include, in no particular order: - operational gaps in existing validator infrastructure - public communications (who needs to know, how should they be told) - usefulness of a public testbed (what could it tell us, who might use it) - other opportunities for testing prior to a KSK roll - timing and mechanics of the actual KSK roll - how to tell if things Start Going Badly Wrong - opportunities for rollback if Things Go Badly Wrong - factors related to future KSK roll schedules - opportunities for measurement before, during and after a KSK roll - future venues for similar or related discussion Please feel free to add to this list, or to add meat to any of these high-level topics. Once we have the final details of the start and end times, we can prioritise and tetris topics into the available window. The format of the workshop is intended to be that of a guided discussion, rather than a set of canned presentations. Notes will be taken and published after the workshop, without attribution. Go. :-) Joe

15 59

Re: [ksk-change] planned vs. emergency (was Re: [ksk-rollover] root zone KSK ...)
by S Moonesamy Sept. 23, 2014

Sept. 23, 2014

Hi Tomofumi, At 21:41 21-09-2014, Tomofumi Okubo wrote: >CAs deal with these risks by establishing and implementing rigorous >security controls around key management and undergo third party audits >to verify that the controls remain effective and are actually >followed. This is kind of funny but they also transfer this risk by >buying insurance but I'm not sure this helps. Certainly not applicable >to us. > >I think the huge difference between the CA business and Root DNSSEC is >that there is no going out-of-business for Root DNSSEC. It doesn't >matter how ugly it gets, we have no option but to recover and keep on >providing the service at all costs. Thanks for the above explanation. It seems that the CA business is being conflated with Root DNSSEC. There is supposed to be redundancy as part of the DNSSEC practice to reduce the risks. The HSMs are offline. The risk there is physical access [1]. An emergency roll-over could, in simple terms, be when a private key is lost or compromised. A planned roll-over reduces the likelihood of that happening. The reluctance to do that planned roll-over is probably because: (a) It has never been done before. (b) There will be an operational impact. It is difficult to assess (b) because of (a). What there is now is "the root key" [2]. It is not a good idea, in my opinion, to have "the root key"[3]. Regards, S. Moonesamy 1. I'll skip a discussion of that. 2. Credits to Michael StJohns 3. I am aware that it is a shared key.

8 18

Re: [ksk-change] planned vs. emergency (was Re: [ksk-rollover] root zone KSK ...)
by S Moonesamy Sept. 22, 2014

Sept. 22, 2014

Hi Tomofumi, At 11:40 22-09-2014, Tomofumi Okubo wrote: >I like the idea of assessing the risks of doing the KSK rollover. > >Do you think it will help to facilitate this discussion if we perform >a high-level risk assessment for the KSK rollover in this group so we >can form a rough consensus around what exactly the risks are and how >they should be treated? I suggest getting rough consensus on the interpretation of the following sentence: "Each RZ KSK will be scheduled to be rolled over through a key ceremony as required, or after 5 years of operation." The reason I chose that sentence is because a discussion of a high-level risk assessment (ICANN document) for the KSK roll-over might not be that productive as a first step. >Risks could actually be dealt in four ways; mitigate, accept, transfer >or avoid. Avoiding (not doing it) is one way but not the only way. Agreed. >Also, I'd like to stress that we are not just talking about present >but the future. The day the algorithm (or key length) is going be >obsolete is coming no matter what. Sometimes, not taking precaution >could be seen as lack of due diligence. I believe if we don't take >action now, the issue is going to get bigger in the future. Agreed. Regards, S. Moonesamy

1 0

[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