- Comments-proposal-future-rz-ksk-rollovers-01nov19

NCSG Comment
by Rafik Dammak Feb. 7, 2020

Feb. 7, 2020

Hi, Please find attached NCSG comment. Best regards, Rafik

1 0

RSSAC046: RSSAC Statement on IANA’s Proposal for Future Root Zone KSK Rollovers
by Andrew McConachie Jan. 31, 2020

Jan. 31, 2020

On behalf of the Root Server System Advisory Committee (RSSAC) please find RSSAC046: RSSAC Statement on IANA’s Proposal for Future Root Zone KSK Rollovers attached. Sincerely, Andrew McConachie ICANN Policy Support for the RSSAC

1 0

Comments to "Future Root Zone KSK Rollovers Plan"
by Satsuki Hori Jan. 31, 2020

Jan. 31, 2020

Comments to "Future Root Zone KSK Rollovers Plan" 31 Jan 2020, Satsuki HORI and Yoshiro YONEYA (JPRS) Preamble ======== Basically, we support this plan. Our comments below are intended to point out places to be more understandalbe, and give suggestions to make the concept of the plan more clear. Comment 1 ========= We understood that the targeted readers of this plan are: (a) Internet Users (mainly full service resolvers' operators) (b) DNS product (software, appliance, etc.) developers (c) Root zone management partners and TCRs Under this understanding, we suggest that Section 2.1 should be broken down from the perspective of these three (a, b and c) readers. That is, what kind of impacts/influences will each target reader suffer from each phase, and what kind of preparation should be taken by them. For example, add information like below: (Please note that this example is not exhaustive and comprehensive.) Phase Target Impacts/Preparations A a No impacts b No impacts c New KSK generation (Key Ceremony) B a No impacts b Append new TA to TA file, update product package c Publish new TA, KSK delivery to another KMF (Key Ceremony) C a No impacts b (the same with Phase B) c Prepare new DNSKEY including new KSK (Key Ceremony) D a Monitor changes regarding to RFC 8145,8509 Update TA file and/or DNS software package if not using RFC 5011 b (the same with Phase B) c Publish new DNSKEY (Zone update) E a Confirm successful RFC 5011 behaviour b No impacts c Change DS to new KSK's (Zone update) F a Monitor changes regarding to RFC 8145,8509 b No impacts c Publish old KSK for revocation (Zone update) G a Update TA and/or DNS software if not using RFC 5011 b Remove old KSK from TA file, update product package c Delete old KSK from KMF (Key Ceremony) H a No impact b No impact c Delete old KSK from KMF (Key Ceremony) Timeline chart in Section 2.1 should be broken down as well from the perspective of three readers. Especially, for the reader (a), please remark that the important date is 11th day of the first month of Phase E and F (DS/DNSKEY publish date). Comment 2 ========= Given that new KSK has a role of standby key, start timing of new KSK's Phase D should be just after old KSK's Phase F. By doing so, non-existence period of standby key can be minimised without increasing DNSKEY size. More precisely, (1) non-existence period of standby key could be limited during old KSK's Phase F, and (2) KSK in published DNSKEY could be always 2 (DNSKEY size could be stable). Comment 3 ========= The meaning of dash line just after the start of Phase D and F in timeline chart at Section 2.1 is unclear. If it has meaning, it should be described clearly, otherwise, the dash line should be removed. Best regards, Satsuki and Yoshiro

1 0

SAC108: SSAC Comments on the IANA Proposal for Future Root Zone KSK Rollovers
by Andrew McConachie Jan. 31, 2020

Jan. 31, 2020

On behalf of the Security and Stability Advisory Committee (SSAC) please find SAC108: SSAC Comments on the IANA Proposal for Future Root Zone KSK Rollovers attached. Sincerely, Andrew McConachie ICANN Policy Support for the SSAC

1 0

Business Constituency (BC) comment on the Proposal for Future Root Zone KSK Rollovers
by Steve DelBianco Jan. 29, 2020

Jan. 29, 2020

Below (and attached) is the comment of ICANN’s Business Constituency (BC), on the Proposal for Future Root Zone KSK Rollovers. Understandably, the Root Zone KSK serves as the trust anchor for DNSSEC and is managed as part of the IANA functions, performed by ICANN through its affiliate, the Public Technical Identifiers (PTI). Having commented on 2-Apr-2018 on the need for a comprehensive KSK Rollover Plan, the BC is pleased with the detailed plan outlined in the Proposal, noting that: 1. A three-year rollover interval strikes a responsible balance between ensuring that procedures and software remain sufficiently agile to adopt new keys as they are commissioned. 2. A three-year rollover interval will also assist in developing institutional memory of all participants in the process. 3. A new KSK should be generated well before it signs the zone and is published. We have some concern with risk associated with publication of the new KSK algorithm, which is 2-years before it is used. In this regard, we recommend that the recipients of the publication should be those that are most concerned with the KSK process and that a Memorandum of Understanding (MOU) be signed in this respect. On the KSK lifecycle, we observed that a fourth cycle might be missing and that is the Key Replication process after the Key has been Created. We note that if the Key is Created and it is not Replicated, there can be no Signing, hence a proposed improvement in the lifecycle as follows: Creation Replication Signing Destruction Endorsement of the 8 Distinct KSK Phases KSK rollover refers to the process of switching the active KSK from one key to another, and includes pre-publication of the new key in a manner that allows it to be trusted, processing updates to the root zone trust anchor, introducing a new KSK in the root zone, and retiring the previous KSK. As such, the BC endorses the retention of the eight distinct phases (A-H) which constitute the current approach. We further recommend that the need to keep to the phased timelines be a subject of the MOU earlier proposed for signature of concerned parties. Finally, the BC appreciates the high level of transparency embedded in the process which includes third party audit; notes as currently safe the 2048-bit RSA keys that are used; and anticipates the continuation of the periodic community engagement process associated with the KSK Signing process. -- This comment was drafted by Jimson Olufuye and was approved in accord with our charter. -- Steve DelBianco Vice Chair for Policy Coordination ICANN Business Constituency (BC)

1 0

Feedback on the proposal for root zone KSK changes
by Erwin Lansing Jan. 29, 2020

Jan. 29, 2020

Thank you for this concise and considered proposal. I support its adoption. As stated on previous occasions, to me the most important requirements of a rollover plan for the root zone KSK is for it to be periodic and predictable. The proposal delivers on both accounts. I also agree that a 3 year period strikes the right balance between being regular enough, while not adding too much strain on affected parties, from DNS operators to software vendors and integrators. Others have commented on not including an algorithm rollover. I would rather agree that algorithm rollover not be part of the current document, but would suggest ICANN to start working on a plan, with the community, for rolling the root zone KSK algorithm once the proposed plan is adopted, and not delay adoption of the rollover plan. Med venlig hilsen / Best regards Erwin Lansing Head of Security & Chief Technologist DK Hostmaster A/S . Ørestads Boulevard 108, 11. sal . 2300 København S +45 3364 6058 . erwin(a)dk-hostmaster.dk . www.dk-hostmaster.dk This is an email from DK Hostmaster A/S. This message may contain confidential information and is intended solely for the use of the intended addressee. If you are not the intended addressee, please notify the sender immediately and delete this e-mail from your system.

1 0

Feedback on proposal for Future Root Zone KSK Rollovers
by Roland van Rijswijk-Deij Jan. 28, 2020

Jan. 28, 2020

Thank you for this proposal that takes some of the community's feedback on the past KSK rollover process into consideration. Please find my feedback on the proposal below: My first point concerns the proposal's stance on algorithm rollover. You write that the current signing infrastructure is capable of transitioning the signing algorithm for the root zone from RSA/SHA256 (algorithm 8) to an ECDSA-based algorithm (13 or 14). You then go on to argue that such a rollover is not on the table in this proposal, citing that "[...] a comprehensive approach needs to consider the readiness and effects on all the other components in the ecosystem, including global resolver behavior". You also state that that current setup that uses 2048-bit RSA keys is not known to have exploitable vulnerabilities. I see issues with both statements that lead me to urge you to reconsider explicitly including an ambition to change the root's signing algorithm in the next or possibly subsequent rollover. My reasons for suggesting this are as follows: - RSA 2048, which currently indeed has no known weaknesses that will allow it to be broken at short notice, has been listed for sunsetting in NIST SP800-57 part 1 by the year 2031 (as Michael StJohns also pointed out). That is within the proposed scope of this document. - Choosing to keep RSA 2048 restricts some of the other choices made in the proposal. It effectively, for example, limits the number of keys in a standby state to a single key, as the combined DNSKEY set would otherwise exceed the desired maximum datagram size. This is further exacerbated by plans from the DNS software implementers community to restrict DNS UDP datagram sizes to around 1232 bytes [1]. - The proposal's stance on algorithm rollover appears to hinge on the assumption that support for ECDSA is not as widespread or "good" as for RSA 2048. I would argue that this is an outdated premise; freely accessible measurements [2,3,4] show that support for ECDSA P256 and P384 is on par (within margin of error) with support for RSA/SHA256. Indeed, even support for EdDSA 25519 is rapidly rising [5]. I would argue that the community is already performing the due diligence of testing support for ECDSA in resolvers and is demonstrating that ECC algorithms in general, and ECDSA in particular, are well-supported. Equally, multiple TLD operators (e.g. [6,7] have already switched to signing with ECDSA without problems. Note that this also implicitly means that these TLDs have shown resolvers can deal with an algorithm rollover successfully. Finally, e.g., Cloudflare has been signing domains for its customers using ECDSA for well over 4 years [8] (and there are many other examples of second-level domains signed with ECDSA). There is another argument for performing an algorithm rollover sooner rather than later, which is the transition to post-quantum cryptography (PQC) algorithms. While it is as yet uncertain if, and if so, when there will be a need to make this transition, performing an algorithm rollover now creates experience in a controlled manner with an algorithm (ECDSA) that is well-understood and well-supported. It is as yet unclear which PQC algorithms are suited for use in DNSSEC, and transitioning may require additional protocol changes. Nevertheless, gaining experience with algorithm rollovers is an important step toward facilitating such a transition. On that note, I believe it would be prudent to mention a potential future transition of the root to PQC algorithms, but to place it firmly out of scope for this proposal. My second point concerns the timing choices in the proposal. While I have no quarrel per se with the timing choices, I do think some of the argumentation to justify the choices is weak. Specifically, the claim that the schedule allows for "sufficient exercise of processes and procedures by staff" is too strong. Effectively, every cycle has a two-year period during which nothing significant happens related to the root KSK rollover. This is long enough to lose institutional memory (in the form of staff changes) and to lose the automatic "muscle memory" (for lack of a better term) needed to proceed through a rollover. I would argue, though, that this is not really an issue, since a rollover of the root is always special, important, and risky, given the special role of the root. I would argue that we want people to be on guard during a root rollover and while institutional memory is nice to have, it does not necessarily lead to increased vigilance. Thirdly, I would like to comment on the emphasis given to emergency rollovers. Many of the choices are (partly) justified by stating that they make emergency rollovers easier or possible, but, in my view, insufficient consideration is given as to what such an emergency rollover would look like, and how the key that is being rolled to is protected differently from the key that is seen as compromised. Because all keys are managed in the same facilities, it seems highly unlikely to me that one key is compromised independent of the other keys managed in the same facility. Consequently, no matter what procedures are followed, there is no secure key on standby to roll to in case a key is compromised, independent of how it was compromised. One could argue that a key that has been "exposed" to the world longer, is more likely to be compromised because an adversary has had more time to perform cryptanalysis on this key. Realistically, though, in the proposed scheme the effective public lifetime of a key is 5 years, two of which it is pre-published for, and three of which it is active for. A new key is published one year into the active part of a key's lifecycle, meaning that an adversary would have a 3-year head start on compromising the active key compared to the newly introduced key that would be the go-to key in case of an emergency rollover. If a means exists for an adversary to compromise a key within a 3-year time window, then arguably the algorithm for that key is no longer strong enough to be used in production. This means that any emergency rollover under such conditions must be to a new algorithm, and thus a new, unknown and not pre-published key. A second note on emergency rollovers is that while technically there might be conditions under which they could be possible, in human terms, trust in "the system" (of the root and DNSSEC on the root) will be thoroughly compromised to the point where the question becomes if one should not give up. If we are unable as a community to securely manage signing of the root, why should people place their trust in it? Taken together, I think the whole premise of an emergency rollover is potentially flawed and should be placed outside of consideration. I know this is strongly worded, but I believe we - as a community - would be better off investing our time in ensuring that an emergency rollover never ever has to take place, rather than planning for a compromise, a case of shutting the stable door when the horse has well and truly bolted. My fourth point concerns pre-establishing keys in resolvers through RFC 5011 and other means. I think the proposed two-year prepublication is an excellent idea and allows for much more time for the new key to be picked up by any means (and not just RFC 5011). If there is one thing we have learned from the recent rollover, it's that RFC 5011 is not the ideal rollover mechanism, nor is it the only rollover mechanism. Applications ship with built-in keys and OS vendors increasingly distribute trust anchors in updates. That is likely to become more common practice than it is now, with more applications performing their own DNS resolution. Announcing keys well ahead of time is an important means to provide time for the key to become established through all the different distribution mechanisms. I therefore fully support the practice of prepublishing, and would even argue that publishing two future keys may be in order (given the practical replacement life cycle of some applications). In the short term, publishing an extra RSA 2048-bit key would be problematic given packet sizes, so the N+2 key could be distributed via the IANA web channel only. In the longer term, of course, such a second standby key should also be part of the DNSKEY set, something which is only possible after an algorithm rollover to an algorithm with shorter signature and key lengths. Finally I'd like to briefly comment on communication of planned rollovers and new keys. The "send only" approach in the current proposal may not have the desired effect, I would strongly encourage explicitly planning proactive communication with OS vendors as a minimum, as key distribution through OS updates is a likely future channel. I hope this input proves useful, and am happy to answer any questions. -- Roland M. van Rijswijk-Deij -- NLnet Labs

1 1

KSK Rollover Proposal
by Michael StJohns Jan. 13, 2020

Jan. 13, 2020

General comments on the timeline: 1) At this point you've defined a process which will have steady state of 2 keys in the trust anchor set for about 2/3s of the period. An emergency key revocation is possible during that period of time. The other 1/3 of the time, you have no standby key available. Why not just go ahead and do what 5011 recommends you do and add a third key? If there is a size issue, adding an EC key as the third key allows you to get a head start on algorithm rollover. (Last sentence of 2.5 is incorrect "requiring changes ... more often" - you can keep the same schedule, the keys just stick around a bit longer). 2) The period of three years is tied to the active period of a key, rather than to a specific roll-over (e.g. Key N+1 replacing Key N). The operational plan needs to consider whether any delays in taking a key out of service will violate general cryptographic guidance. Make sure that you're following both the guidance for key lifetime, and any sunset provisions for key strength that show up in the meantime. E.g. NIST SP 800-57Pt1, table 4 sunsets RSA2048 as of 2031 - or roughly at the beginning of the 4th key rollover if this schedule is followed. 3) As a consequence of the three year period, there is approximately 1.75 years between major HSM actions (e.g. key generation and revocation - the period D). Loss of skills by the HSM operators during the long period need to be considered. 4) There is no real reason to have the standby key present on the HSM after generation until it's ready to start signing stuff. I'm assuming that the AEP has a backup mechanism for generated keys that's used between HSM operations (which is pretty obvious as both HSMs must share a storage master key to allow for key copying). 5) G and H - Assuming that there is a backup mechanism for the HSMs, simply deleting the keys from the HSM won't necessarily cause them to be destroyed if any backups were made. Both HSMs must go through an update for the Storage Master Key to complete the deletion of the key material. 6) Consider other mechanisms for co-generation of the private key on two different HSMs as opposed to generate/export/import current model. For example HSM A -> Genkeypair -> ECDH Ka1, HSM B -> Genkeypair -> Kb1. HSMA ECDH (Ka1.private, Kb1.public) -> KDF() -> either RSA gen seed or EC private key. The use of ECDH gets the same secret on both HSMs without the need to move sensitive information out of the HSM, even in an encrypted form. The shared secret can be fed into a KDF to generate an EC private key, which can then be used to generate a public key from the private one. If you're doing RSA key pair generation, use the shared secret as a seed to a PRNG which is used in turn to generate the RSA key pairs. 7) Would it help if I made an errata for RFC5011 "In section 5, 'Missing' state, delete 'This is an abnormal state'"? Mike StJohns, NthPermutation Security

1 0

proposed future rz KSK rollover plan
by John Dickinson Nov. 25, 2019

Nov. 25, 2019

A couple of thoughts… I would like to see a reference to RFC 7958. I know it is on IANA’s Trust Anchor and Keys page. However, since it defines the meanings of some of the terms used in the xml and this document it should be referenced here. I think the validFrom and validUntil fields in the trust anchor file could be more explicitly linked to the stages of this document. I can imagine that a reader might wonder if the validFrom is the start of stage E, D, C or even B as indicated in Section 2.2. Are you sure you mean B? Likewise, validUntil might be end of E or F. RFC 7958 only states that “Relying parties SHOULD NOT use a KeyDigest outside of the time range given in the validFrom and validUntil attributes.” it does not say what “use” means. 2.4 states “Note that the timelines given here are aspirational and not guaranteed. If an event occurs that warrants detailed study before proceeding, the rollover process can pause with the active KSK continuing to be used, even if doing so exceeds the nominal three-year period.” could this cause problems for operators relying on the validFrom and validUntil attributes? It would be nice if the legend in the timeline diagram showed the name of the phase and not the letter. regards John John Dickinson https://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford Science Park Robert Robinson Avenue Oxford OX4 4GA U.K.

1 0

Re: [Comments-proposal-future-rz-ksk-rollovers-01nov19] [ksk-rollover] Proposal for Future Root Zone KSK Rollovers
by Michael Richardson Nov. 6, 2019

Nov. 6, 2019

Kim Davies <kim.davies(a)iana.org> wrote: > The three-year rollover strikes a responsible balance ensuring that > procedures and software remain sufficiently agile to adopt new keys as > they are commissioned, while not introducing too much operational > complexity through overly-frequent changes to the KSK. The standby > period will allow a longer pre-publication and consequently allow for > the new KSK’s earlier use if there is a need to perform an emergency > rollover. > The public comment period is slated to close at the end of January. We > encourage you to submit your feedback so we may integrate it into the > final approach. > For those at the ICANN 66 meeting in Montreal this week, we will be > presenting the proposal to the DNSSEC session being held later today. I read the document quickly. I used the submit button, which then generated a mailto: URL, bring up in gmail, which I didn't really want to use. Couldn't you just tell me the email address to use? And gmail won't let me copy and paste the email address easily... sigh: I guess it is: comments-proposal-future-rz-ksk-rollovers-01nov19(a)icann.org I have two comments: 1) In the D and E periods, you have a dashed line, which I think described as the RFC5011 hold-down period. I suggest that you give these two periods a name/number/designation. Maybe D_0 and E_0 or something like that. Maybe a completely new letter. 2) you write: doc> We also propose that each new KSK be generated well before it signs doc> the zone. This will allow a longer period of pre-publication, and doc> consequently allow for the new KSK’s earlier use if there is a need doc> to perform an emergency rollover. As a result, the overall lifespan doc> of future KSKs is anticipated to be about six years — two years of doc> which will be in a standby state (published, but not yet actively doc> used), three years in an doc> active state, and the final year being revoked and then deleted from doc> the key management facilities. Some have expressed concern that the longer the public key is visible the longer a (brute force?) adversary will have to attack the key. I do not entirely concur with this view: if such an attack exists, it exists regardless of when the key is published, and we need to roll the key more often. I'd like to see some discussion of this issue. Still, if there were credible serious concerns here, it seems that there could be a state B-prime, between B and C, or perhaps even from end of A to beginning of C in which a hash of the public key is published, but not the public key itself. Again, I'm **skeptical** about this attack. In particular, software distributions that might sit on the shelf (be burned into CDroms) could embed the hash of the key (K+1) at year Q3 or year Y+3, a full two and half years before the key is in use. (Maybe that would argue for a shorter phase D, and longer state B-prime) I would like to see some feedback (endorsement?) from the RedHat RHEL and Canonical Server LTS managers (and Windows server) about the details of this cycle. I think that the three year KSK cycle with the 2+bit year intro may fit VERY WELL into their release process. The resuling being that, except in emergencies, any LTS image installed within it's support lifespan of typically 5 years, will be able to authenticate the root zone without any additional parts. -- Michael Richardson <mcr+IETF(a)sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

1 0