- ksk-rollover - lists.icann.org

[ksk-change] Excerpt from a Gemalto bulletin
by Michael StJohns Oct. 14, 2014

Oct. 14, 2014

Gemalto (smart card vendor) is picking up Safenet the HSM vendor. Mike - > > > *Gemalto to acquire SafeNet, the worldwide leader in data and > software protection* > > > > SafeNet will significantly reinforce Gemalto's Identity and Access > Management business. It will become part of Gemalto's Payment & > Identity segment, and its Platforms & Services activity, that account > respectively for 1,329 million and 715 million of the 2013 pro forma > revenue. > *Press Release* >

3 2

[ksk-change] Testing new keys added
by Paul Hoffman Oct. 13, 2014

Oct. 13, 2014

Greetings again. Pure conjecture below. Assuming that a rollover uses the Double-KSK method described previously, is there an intention to test systems for the new SEP key before removing the old one? That is, if A is the current KSK and IANA adds B, after the 30-day hold-down time, either key could be used to sign zones in the root. One thought is to sign a test TLD "dywnagrebo" with just B, have an IANA-supported server that is authoritative for dywnagrebo, and include URLs such as www.test.dywnagrebo in some environments where they might be resolved. I'm not sure how one might be able to see when a lookup fails due to validation (as compared to failing due to it being a new TLD), so this could be a useless idea. However, more creative people here might be able to design a way to actually test that the B KSK is widely loaded before A is removed. --Paul Hoffman

5 10

[ksk-change] Which style of rollover were people thinking of?
by Paul Hoffman Oct. 7, 2014

Oct. 7, 2014

Greetings again. Assuming that we are still thinking of doing a KSK rollover, what style of rollover were people thinking of? draft-ietf-dnsop-dnssec-key-timing-05 describes described three. Of course, there is no DS record here, but the DS's moral equivalent is the manually trusted key(s) in the validating resolvers. --Paul Hoffman

4 4

Re: [ksk-change] FIPS-140 levels
by S Moonesamy Oct. 7, 2014

Oct. 7, 2014

Hi Tomofumi, At 15:37 06-10-2014, Tomofumi Okubo wrote: >Yes, that's right but that is if the other security controls >successfully detects the compromise. >The mechanism on the HSM will be the last line of defense if the other >security controls fail for some reason. This is why in the ICANN >definition, HSM is labelled as Tier 7. The HSM is currently at Tier 6. If I recall correctly I commented about that previously. I suggested a change a few months ago. I am waiting for feedback about the suggestion. Regards, S. Moonesamy

2 1

[ksk-change] Keeping two KSK keys long term
by Paul Hoffman Oct. 6, 2014

Oct. 6, 2014

Greetings again. It is my impression that having two (or more) KSK keys long term makes 5011 rollovers a bit less problematic, but I could be misunderstanding some of the subtleties of 5011 when mixed with draft-ietf-dnsop-dnssec-key-timing. If it is better, I would propose that the timing of the KSK change be "add second and third key, wait a bit, remove current (first) key" over "add a second key, wait a bit, remove the current (first) key, wait a bit, add a new key (so we have two)". Thoughts? --Paul Hoffman

9 50

[ksk-change] 2 weeks until the ICANN 51 workshop - logistics?
by Dan York Oct. 6, 2014

Oct. 6, 2014

Folks, To get a wee bit tactical, I'd like to point out that the public KSK Rollover Workshop is happening 2 weeks from TODAY on Oct 16. We now have a room (Brentwood) and a page on the ICANN website: http://la51.icann.org/en/schedule/thu-dnssec-key-rollover You'll note that the page says the time is from 08:00-18:00 ... that is the time DRC says we have the room for... but even as hard-core as so many of you are, I highly doubt that many of us want to meet for *10 hours* on this topic. So... step 1... WHEN do we want to hold the workshop? If you look at the rest of the schedule for Thursday: http://la51.icann.org/en/schedule?date=2014-10-16 you will see that SSAC has its public meeting from 08:00-09:00 and then all the other meetings pretty much end by 12:00 or 13:00 so that attendees can go to the Public Forum starting at 13:30 and going until 17:00. Leaving aside the question of what we will actually be discussing (let's kick off another thread on that), from a purely logistical point of view it seems to me that given that a number of people involved with KSK Rollover work are also in SSAC, we probably can't start until 9:00am. Also, if our goal is to attract many of the other attendees, we probably need to end before the Public Forum. Which, to me, means it seems like we have 09:00-12:00 or 12:30 if we want to leave time for people to get some lunch before the Public Forum. Agree? Disagree? Think we should go longer? Really want to spend 10 hours in the same room as the people on this list? Discuss....... :-) 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/

3 2

[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