FOR REVIEW: RSSAC Statement on IANA's Proposal for Future Root Zone KSK Rollovers
Dear RSSAC Caucus, The call to discuss RSSAC’s input to IANA on IANA's Proposal for Future Root Zone KSK Rollovers ended 25 minutes ago. On the call the Caucus members present resolved all comments in the working document. <https://docs.google.com/document/d/1U1qKPRx9URRfiI4jijvLKSCS2W6upZRDppUsbANq...> Please review the document and provide any final comments by Sunday January 12th. After that the document will be finalized and remain stable for 7 days in preparation for an online vote by the RSSAC. Thanks, Andrew
All: I have made one proposed addition to a sentence that was added during the call. The sentence read: However, the RSSAC would like to see a stronger commitment from IANA to begin studying and documenting a comprehensive approach to an algorithm rollover, and have that plan subject to public review. I think we should mention key length changes: However, the RSSAC would like to see a stronger commitment from IANA to begin studying and documenting a comprehensive approach to an algorithm rollover or key length change, and have that plan subject to public review. I bring this up because IANA might choose not to change algorithms for a long time, but might want to change the key length to avoid issues with crypto-breaking quantum computers that attack RSA keys. There is nascent research that suggests that crypto-breaking quantum computers that attack elliptic curve keys might be easier to construct than ones that attack RSA keys, and simply using longer RSA keys could significantly reduce the ability for crypto-breaking quantum computers to break them. Thoughts? --Paul Hoffman
Hi Paul, I have a couple of thoughts. A number of people have been advocating for algorithm change for many years now. So it seems justified that IANA should take on work to study and plan for that. I don't get the sense that there is a lot of demand from the community to about a length change, or at least not yet. You said the research is nascent. I worry that, as written, there is ambiguity. Is RSSAC requesting a single study that would evaluate both alg roll and length change? or separate studies? Would a single study on length change only satisfy the recommendation (since it says "or")? Is the underlying message "RSSAC thinks IANA should be prepared with a length change plan?" or is it "if IANA wants to change the length RSSAC wants a chance to review the plan?" DW
On Jan 8, 2020, at 1:31 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
All: I have made one proposed addition to a sentence that was added during the call. The sentence read:
However, the RSSAC would like to see a stronger commitment from IANA to begin studying and documenting a comprehensive approach to an algorithm rollover, and have that plan subject to public review.
I think we should mention key length changes:
However, the RSSAC would like to see a stronger commitment from IANA to begin studying and documenting a comprehensive approach to an algorithm rollover or key length change, and have that plan subject to public review.
I bring this up because IANA might choose not to change algorithms for a long time, but might want to change the key length to avoid issues with crypto-breaking quantum computers that attack RSA keys. There is nascent research that suggests that crypto-breaking quantum computers that attack elliptic curve keys might be easier to construct than ones that attack RSA keys, and simply using longer RSA keys could significantly reduce the ability for crypto-breaking quantum computers to break them.
Thoughts?
--Paul Hoffman_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On Jan 8, 2020, at 3:38 PM, Wessels, Duane <dwessels@verisign.com> wrote:
I have a couple of thoughts.
A number of people have been advocating for algorithm change for many years now. So it seems justified that IANA should take on work to study and plan for that. I don't get the sense that there is a lot of demand from the community to about a length change, or at least not yet. You said the research is nascent.
The community has indeed been advocating for an algorithm change. That seems to be based on key size, not on quantum resistance. There is also the possibility that whatever quantum-resistant signing algorithm that comes out of the NIST competition is suitable for DNSSEC (which it very will might not be due to the size of signatures, keys, or both).
I worry that, as written, there is ambiguity. Is RSSAC requesting a single study that would evaluate both alg roll and length change? or separate studies? Would a single study on length change only satisfy the recommendation (since it says "or")?
The latter was what I intended, but I see where there is ambiguity. Better wording might be "... studying and documenting a comprehensive approach to an algorithm rollover, or to a key length change, ...".
Is the underlying message "RSSAC thinks IANA should be prepared with a length change plan?" or is it "if IANA wants to change the length RSSAC wants a chance to review the plan?"
The latter, definitely. Is the new proposal above sufficient for that? Or do you have clearer wording? Or should we not say anything to IANA about wanting to have a public plan if they decide to do an RSA key length change? --Paul Hoffman
On Jan 9, 2020, at 00:46, Paul Hoffman <paul.hoffman@icann.org<mailto:paul.hoffman@icann.org>> wrote: I worry that, as written, there is ambiguity. Is RSSAC requesting a single study that would evaluate both alg roll and length change? or separate studies? Would a single study on length change only satisfy the recommendation (since it says "or")? The latter was what I intended, but I see where there is ambiguity. Better wording might be "... studying and documenting a comprehensive approach to an algorithm rollover, or to a key length change, …” I’ve included this suggested text in the document. <https://docs.google.com/document/d/1U1qKPRx9URRfiI4jijvLKSCS2W6upZRDppUsbANq...>
On Jan 9, 2020, at 10:22, Andrew McConachie <andrew.mcconachie@icann.org<mailto:andrew.mcconachie@icann.org>> wrote: On Jan 9, 2020, at 00:46, Paul Hoffman <paul.hoffman@icann.org<mailto:paul.hoffman@icann.org>> wrote: I worry that, as written, there is ambiguity. Is RSSAC requesting a single study that would evaluate both alg roll and length change? or separate studies? Would a single study on length change only satisfy the recommendation (since it says "or")? The latter was what I intended, but I see where there is ambiguity. Better wording might be "... studying and documenting a comprehensive approach to an algorithm rollover, or to a key length change, …” I’ve included this suggested text in the document. <https://docs.google.com/document/d/1U1qKPRx9URRfiI4jijvLKSCS2W6upZRDppUsbANq... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1U1qKPRx9URRfiI4jijvLKSCS2W6upZRDppUsbANqIOg_edit-3Fusp-3Dsharing&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KNEpS67O2txk54bIz-1lXP0tI5Rmtg88Ogwh6PVSGXJyTMuY0E2SHr70jrG3fGLJ&m=dQ6gmRar1KdTywAiZ5V_uJlY6H2L-rolaSJxgqTCVbk&s=oVxBbf-vWt3sLnbjqZLY3OpARR1n8TrEJezin_0Du9E&e=>> Ryan Stephenson asks a good question in the document about whether we should change the title of section 3.2 to "Algorithm and Key Length Changes”. I have a somewhat related question. Is it better to talk of ‘key lengths’ or ‘key sizes’? —Andrew
On Jan 9, 2020, at 7:33 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Ryan Stephenson asks a good question in the document about whether we should change the title of section 3.2 to "Algorithm and Key Length Changes”.
If the group wants to mention sizes in the text, then it seems reasonable to add that to the section title.
I have a somewhat related question. Is it better to talk of ‘key lengths’ or ‘key sizes’?
Either is fine, and both are used nearly equally in the literature. I don't even know of anyone who argues "you should be saying 'length'" or "you should be saying 'size'". --Paul Hoffman
Looks like NIST.SP.800-81-2.pdf uses key size and RFC 6781 uses key length. I would use with the RFC. -----Original Message----- From: rssac-caucus <rssac-caucus-bounces@icann.org> On Behalf Of Paul Hoffman Sent: Thursday, January 9, 2020 10:36 AM To: Andrew McConachie <andrew.mcconachie@icann.org> Cc: RSSAC Caucus <rssac-caucus@icann.org> Subject: [Non-DoD Source] Re: [RSSAC Caucus] [Ext] Re: FOR REVIEW: RSSAC Statement on IANA's Proposal for Future Root Zone KSK Rollovers On Jan 9, 2020, at 7:33 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Ryan Stephenson asks a good question in the document about whether we should change the title of section 3.2 to "Algorithm and Key Length Changes”.
If the group wants to mention sizes in the text, then it seems reasonable to add that to the section title.
I have a somewhat related question. Is it better to talk of ‘key lengths’ or ‘key sizes’?
Either is fine, and both are used nearly equally in the literature. I don't even know of anyone who argues "you should be saying 'length'" or "you should be saying 'size'". --Paul Hoffman
On Jan 9, 2020, at 7:33 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
I have a somewhat related question. Is it better to talk of ‘key lengths’ or ‘key sizes’?
To my mind (and Paul will tell you that I get the details wrong), a key, the entity it identifies or that uses it, and an algorithm that might use it are a matched set. If I were to provide a quantum key to an RSA algorithm, it simply wouldn't work. So to my mind, whenever you talk about a key or a key length (which is specifically an attribute of an RSA key), you are implicitly talking about the entire set - and would do well to say so. In other words, if we're using RSA keys and changing the length, we should say "we plan to still use the RSA algorithm, but we are changing the length". Stating that we want to use an elliptical curve key only makes sense if we change the algorithm to an elliptical curve algorithm - and I'll bet one wants to get far more specific in such a case. Now, as was pointed out on the call, if we're commenting on *this*key*roll*, then discussing different algorithms is out of scope - but not, I would argue, because it doesn't make sense, but because there is a decision that has already been made and acts as prior restraint. What I'd like to see, therefore, is a compound statement conveying "IANA chooses to continue to use the RSA algorithm, but proposes to change the key length" or some such thing. The value of that is that mumble time units in the future, IANA will presumably roll the key again. At that point, I fully expect that "conservation of mental cycles" will be in vogue, and someone will say "why don't we do it the way we did it last time?" This document will come out and get updated to the new scenario. At that point, I'd like the statement to force the question - should the same prior restraint be in effect, or should one contemplate other algorithms? If other algorithms are also in view, that will imply making sure that relevant software can support elliptic curve or whatever. In the meantime, I could imagine BIND, UNBOUND, etc sprouting an algorithmic API, and the indicated future discussion therefore enabled to say "well, the relevant packages all support <>; that's at least an option." I could also imagine folks like Paul, Wes, and others kicking the tires of said software, and saying "<> actually works."
Hi Paul, On Thu, Jan 9, 2020 at 12:31 AM Paul Hoffman <paul.hoffman@icann.org> wrote:
All: I have made one proposed addition to a sentence that was added during the call. The sentence read:
However, the RSSAC would like to see a stronger commitment from IANA to begin studying and documenting a comprehensive approach to an algorithm rollover, and have that plan subject to public review.
I think we should mention key length changes:
However, the RSSAC would like to see a stronger commitment from IANA to begin studying and documenting a comprehensive approach to an algorithm rollover or key length change, and have that plan subject to public review.
I bring this up because IANA might choose not to change algorithms for a long time, but might want to change the key length to avoid issues with crypto-breaking quantum computers that attack RSA keys. There is nascent research that suggests that crypto-breaking quantum computers that attack elliptic curve keys might be easier to construct than ones that attack RSA keys, and simply using longer RSA keys could significantly reduce the ability for crypto-breaking quantum computers to break them.
Thoughts?
I was of a similar view but perhaps didn't articulate it well when I commented on the "concerns" section of the document. A commitment from IANA to incorporate algorithmic or key length rollover changes is a good suggestion.
--
Paul M
I read the revised document. It has the merit of being short. I like short. Some sentences are now compound, and the role of a comma in a compound sentence can include implying LINKAGE. I do not see measurement, and the establishment of root telemetry as irrevocably bound: They are two things, not one thing. A minor nit. To the key length. DNS is not a domain where secrecy of past signed states matters so we do not seek PFS. I think we would be silly to pre-emptively sign with longer (RSA?) keys in a belief future events may create breakable state in QC. I think we should continue to explore SHORTER key lengths by algorithm change, and reconsider this in the light of QC when QC announces significant return. I think the work on mitigation should be done but doesn't have to reflect in signed state yet. Having managed transition to shorted keys in different Alg, the re-roll into a longer key technology is then possible and understood: its not being conducted blind. I'd welcome CFRG input on long term DNSSEC responses to QC. "make RSA more longerer" doesn't feel to me like the answer. I could live with this document as-is btw. -G On Thu, Jan 9, 2020 at 5:26 AM Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus,
The call to discuss RSSAC’s input to IANA on IANA's Proposal for Future Root Zone KSK Rollovers ended 25 minutes ago.
On the call the Caucus members present resolved all comments in the working document. <https://docs.google.com/document/d/1U1qKPRx9URRfiI4jijvLKSCS2W6upZRDppUsbANq...>
Please review the document and provide any final comments by Sunday January 12th. After that the document will be finalized and remain stable for 7 days in preparation for an online vote by the RSSAC.
Thanks, Andrew
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Dear RSSAC Caucus, The Google doc is now locked in view only mode. I have accepted all comments and prepared a PDF version(attached) to be voted upon by the RSSAC. Thank you to all the Caucus members who helped prepare this document. Thanks, Andrew On Jan 8, 2020, at 20:26, Andrew McConachie <andrew.mcconachie@icann.org<mailto:andrew.mcconachie@icann.org>> wrote: Dear RSSAC Caucus, The call to discuss RSSAC’s input to IANA on IANA's Proposal for Future Root Zone KSK Rollovers ended 25 minutes ago. On the call the Caucus members present resolved all comments in the working document. <https://docs.google.com/document/d/1U1qKPRx9URRfiI4jijvLKSCS2W6upZRDppUsbANq... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1U1qKPRx9URRfiI4jijvLKSCS2W6upZRDppUsbANqIOg_edit-3Fusp-3Dsharing&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KNEpS67O2txk54bIz-1lXP0tI5Rmtg88Ogwh6PVSGXJyTMuY0E2SHr70jrG3fGLJ&m=fA7LwTCI0T_56BuZXQyPMQRNznNY3_psek9iJ4kvdRY&s=F7tcRlS56cIQs8ryPbmCW46hkZ-iTnlMihMGhOE5SQ4&e=>> Please review the document and provide any final comments by Sunday January 12th. After that the document will be finalized and remain stable for 7 days in preparation for an online vote by the RSSAC. Thanks, Andrew _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org<mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p... ) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t... ). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (8)
-
Andrew McConachie -
Fred Baker -
George Michaelson -
Paul Hoffman -
Paul M -
Stephenson, Ryan M CIV DISA IE (USA) -
Wes Hardaker -
Wessels, Duane