Collected KSK comments
I'm pulling together comments that we might make. I am including who said them, because we said that Caucus contributions would be attributable to their source. Speaking for myself, I would rather have the comments be considered to have been made by the committee, which is to say without attribution. If that's a general viewpoint, let me know. George Michaelson: The proposal should address algorithm rollover. As that is considered out of scope for this version, propose for the next change. The proposal should include measurement. (George: specifically what would you like to measure?) The alternate/replacement key pre-gen stuff is forward-thinking, and good. Paul Muchene: Phase D, the KSK standby state, it potentially invites an attacker to exploit possible vulnerabilities with either the properties of the key or key generation algorithm. If phase D could be reduced a reasonably shorter duration (1-1.5 years) this problem could be mitigated. However, if this duration is pretty short and will inconvenience the dissemination of the KSK to OS and DNS software vendors, then considerations should be proposed for using a longer KSK key length of 3072-bit RSA. Dessalegn Yehuala Section 2.4 seems to give a soft rationale for the rollover frequency. Arguments exist for a longer or a shorter interval, and these arguments don't seem to be strong enough to make a firm choice. Section 2.6 assumes current state of the strength of the current cryptographic algorithm employed for the KSK (2048-bit RSA), there is no risk mitigation identified in the event the current cryptographic algorithm discovered to have some exploitable vulnerabilities. Fred Baker: in that context, researchers from KeyFactor presented a paper at First IEEE Conference on Trust, Privacy, and Security that reported that one in 172 RSA certificates certified keys for which the private key could be derived from the public key. Davey Song: Suggests changing to an ECC algorithm rather than changing to a 3072 bit key. There should be a predictable timeline for algorithm rollover and as a result a advance timeline for study, review, and testing work on this.
On Mon, Dec 16, 2019 at 2:55 PM Fred Baker <fred@isc.org> wrote:
The proposal should include measurement. (George: specifically what would you like to measure?)
Generally: * Active experimentation in things like APNIC Labs, ATLAS, other models. * Passive capture in things like DITL root operator captures/samples/logs, so we can do before/during/after checks. Specific things it might be worth doing: * count cutover from UDP to TCP due to TC/Frag effects. change in underlying UDP/TCP ratios * count failure to complete DNNSEC. (presumed as 'excess query load in DNSSEC contexts, more than before the increase in packetsize) * count of changes in query load, * increases in non-DNSSEC query (presumed as 'because of failure') * any packet level measure which is capable of identifying code type/version, visible changes in version (signs of adoption of new code, with known capabilities) I see potential for deliberate A/B testing even within a root letter: de-cohere state for some fraction of responses, (reply with variant legal responses) and see how things change, but this might be contentious, more likely to cause surprise. breaks POLA. (declaration of interest: I work with people who measure DNS in APNIC, RIPE, I am chair of the DNS OARC)
Hi Fred, I agree with you. It should be from the group if we majorly agree that they are valid observation which I think they are. Thanks AK On Mon, Dec 16, 2019 at 4:55 AM Fred Baker <fred@isc.org> wrote:
I'm pulling together comments that we might make. I am including who said them, because we said that Caucus contributions would be attributable to their source. Speaking for myself, I would rather have the comments be considered to have been made by the committee, which is to say without attribution. If that's a general viewpoint, let me know.
George Michaelson: The proposal should address algorithm rollover. As that is considered out of scope for this version, propose for the next change.
The proposal should include measurement. (George: specifically what would you like to measure?)
The alternate/replacement key pre-gen stuff is forward-thinking, and good.
Paul Muchene: Phase D, the KSK standby state, it potentially invites an attacker to exploit possible vulnerabilities with either the properties of the key or key generation algorithm.
If phase D could be reduced a reasonably shorter duration (1-1.5 years) this problem could be mitigated. However, if this duration is pretty short and will inconvenience the dissemination of the KSK to OS and DNS software vendors, then considerations should be proposed for using a longer KSK key length of 3072-bit RSA.
Dessalegn Yehuala Section 2.4 seems to give a soft rationale for the rollover frequency. Arguments exist for a longer or a shorter interval, and these arguments don't seem to be strong enough to make a firm choice.
Section 2.6 assumes current state of the strength of the current cryptographic algorithm employed for the KSK (2048-bit RSA), there is no risk mitigation identified in the event the current cryptographic algorithm discovered to have some exploitable vulnerabilities.
Fred Baker: in that context, researchers from KeyFactor presented a paper at First IEEE Conference on Trust, Privacy, and Security that reported that one in 172 RSA certificates certified keys for which the private key could be derived from the public key.
Davey Song: Suggests changing to an ECC algorithm rather than changing to a 3072 bit key.
There should be a predictable timeline for algorithm rollover and as a result a advance timeline for study, review, and testing work on this. _______________________________________________ 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.
-- Website <http://www.unilorin.edu.ng>, Weekly Bulletin <http://www.unilorin.edu.ng/index.php/bulletin> UGPortal <http://uilugportal.unilorin.edu.ng/> PGPortal <https://uilpgportal.unilorin.edu.ng/>
Dear RSSAC Caucus, I’m starting to put together a statement from the RSSAC in response to the Public Comment Proceeding on the Proposal for Future Root Zone KSK Rollovers. I based if off of RSSAC039, but it’s mostly just boilerplate right now. <https://docs.google.com/document/d/1U1qKPRx9URRfiI4jijvLKSCS2W6upZRDppUsbANq...> One concern I have is in RSSAC039 the RSSAC was very clear in keeping comments within the scope of the RSSAC. See section 2 of RSSAC039. <https://www.icann.org/en/system/files/files/rssac-039-07aug18-en.pdf> Some of the comments below I construe as being outside of RSSAC’s scope. Specifically the comments about key breakage and algorithm rolls. I’m having a hard time understanding how key compromise would impact the operation, administration, security, or integrity of the RSS. We could relate these to the operation, administration, security, or integrity of the RSS. For example, if the KSK were compromised it would likely require some kind of emergency procedure take place at IANA, the RZM and RSOs. That kind of emergency procedure might be interesting to mention in RSSAC’s statement, but is this what the RSSAC Caucus actually wants to discuss? —Andrew On Dec 16, 2019, at 12:04, ABDULKARIM AYOPO OLOYEDE <oloyede.aa@unilorin.edu.ng<mailto:oloyede.aa@unilorin.edu.ng>> wrote: Hi Fred, I agree with you. It should be from the group if we majorly agree that they are valid observation which I think they are. Thanks AK On Mon, Dec 16, 2019 at 4:55 AM Fred Baker <fred@isc.org<mailto:fred@isc.org>> wrote: I'm pulling together comments that we might make. I am including who said them, because we said that Caucus contributions would be attributable to their source. Speaking for myself, I would rather have the comments be considered to have been made by the committee, which is to say without attribution. If that's a general viewpoint, let me know. George Michaelson: The proposal should address algorithm rollover. As that is considered out of scope for this version, propose for the next change. The proposal should include measurement. (George: specifically what would you like to measure?) The alternate/replacement key pre-gen stuff is forward-thinking, and good. Paul Muchene: Phase D, the KSK standby state, it potentially invites an attacker to exploit possible vulnerabilities with either the properties of the key or key generation algorithm. If phase D could be reduced a reasonably shorter duration (1-1.5 years) this problem could be mitigated. However, if this duration is pretty short and will inconvenience the dissemination of the KSK to OS and DNS software vendors, then considerations should be proposed for using a longer KSK key length of 3072-bit RSA. Dessalegn Yehuala Section 2.4 seems to give a soft rationale for the rollover frequency. Arguments exist for a longer or a shorter interval, and these arguments don't seem to be strong enough to make a firm choice. Section 2.6 assumes current state of the strength of the current cryptographic algorithm employed for the KSK (2048-bit RSA), there is no risk mitigation identified in the event the current cryptographic algorithm discovered to have some exploitable vulnerabilities. Fred Baker: in that context, researchers from KeyFactor presented a paper at First IEEE Conference on Trust, Privacy, and Security that reported that one in 172 RSA certificates certified keys for which the private key could be derived from the public key. Davey Song: Suggests changing to an ECC algorithm rather than changing to a 3072 bit key. There should be a predictable timeline for algorithm rollover and as a result a advance timeline for study, review, and testing work on this. _______________________________________________ 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://www.icann.org/privacy/policy [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p...>) and the website Terms of Service (https://www.icann.org/privacy/tos [icann.org]<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. Website [unilorin.edu.ng]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.unilorin.edu.ng&d=Dw...>, Weekly Bulletin [unilorin.edu.ng]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.unilorin.edu.ng_inde...> UGPortal [uilugportal.unilorin.edu.ng]<https://urldefense.proofpoint.com/v2/url?u=http-3A__uilugportal.unilorin.edu...> PGPortal [uilpgportal.unilorin.edu.ng]<https://urldefense.proofpoint.com/v2/url?u=https-3A__uilpgportal.unilorin.ed...> _______________________________________________ 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 (4)
-
ABDULKARIM AYOPO OLOYEDE -
Andrew McConachie -
Fred Baker -
George Michaelson