Hi all, in the latest few days, there has been some discussion in the WhatsApp chat of LACRALO about DNSSEC and its rollout to ccTLDs. Unfortunately that conversation remains off the record, is not multilingual, and is not equally accessible to all member organizations' representatives. The key take-home of that conversation is that intervening at ccTLD managers is a matter for the local community as much, or much more, than the ccNSO or any other part of ICANN barring the SSAC. Please Oscar, Laura, Vanda etc. bring it back here to be able to make everyone a party to it. The following is related though at a different level: I am forwarding here a message from Matthias Hudobnik to the ALAC lists regarding the key (literally!) cryptographic process that secures the DNS, the KSK. As you will easily see, there are some pretty hairy technical and operational issues at stake. In particular it is necessary to make a compromise between the strength of the protection to the root (via the size of the key) with the capacity and throughput of the systems that use it, at least for a period of time of 2 to 4 years. There are also considerations of post-quantum cryptography but they can be allayed somewhat. Please consult with the technically savvy members of your ALS and, as much as possible, with the ISPs and ccTLD managers with which we should all be in contact for the realization of our roles, and if necessary and appropriate start a discussion in order to emit a recommendation as follow-up to the ongoing process. To our representatives, please prepare a presentation - with an appropriate speaker if the matter exceeds your field of work - so the community can be kept abreast of this important development, and then be able to answer questions about the security and stability of the DNS that may come from unexpected sources. Yours, Alejandro Pisanty ---------- Forwarded message --------- From: Matthias M. Hudobnik via At-Large <at-large@icann.org> Date: Fri, Apr 24, 2026 at 2:15 PM Subject: [At-Large] SAC133: SSAC Comments on Proposed Root KSK Algorithm Rollover To: <at-large@atlarge-lists.icann.org> Dear Colleagues, The SSAC has published SAC133, providing comments on the proposed transition of the Root KSK from RSA/SHA-256 (Algorithm 8) to ECDSA P-256/SHA-256 (Algorithm 13). Here is a summary of the key points. *Overall Support* The SSAC endorses the proposed algorithm transition, including the selection of Algorithm 13, the double-signing rollover methodology, and the inclusion of backout SKRs and flexible phase scheduling. It finds the proposal consistent with the 2024 Root Zone Algorithm Rollover Study and prior SSAC advisories (SAC063, SAC073, SAC102, SAC108), and notes it addresses SSR2 Recommendation 23. The SSAC encourages ICANN to proceed. *RSA ZSK Size Reduction (2048 → 1536 bits)* The SSAC considers the ZSK size reduction operationally advisable to keep root zone responses under the 1232-byte UDP buffer threshold (established by DNS Flag Day 2020) during double-signing. It acknowledges the reduction lowers security from approximately 112 bits to approximately 96 bits, but finds this acceptable given each ZSK's short public exposure window (approximately 110 days, or approximately 193 days in a covert attacker scenario). However, the SSAC recommends that the final implementation plan: - Formally document this as a strictly time-bound exception to cryptographic best practices that establishes no precedent for future operations. - Include a cryptographic estimate of the computational cost and time required to break a 1536-bit key within its operational window. The SSAC also concurs with the proposal's rejection of the alternative approach (rolling the ZSK to Algorithm 13 before the KSK), as it would violate RFC 6840 mandatory algorithm rules, and the relevant draft specification has not been adopted by the IETF DNSOP working group. *Timeline Concerns* The proposed rollover spans approximately 4 years (Q2/2027 Phase AA through Q3/2030 Phase HH). The SSAC questions whether this duration is necessary and raises two specific concerns: EE (double-signing / trust anchor update via RFC 5011) is planned for approximately 2 years, yet RFC 5011's mandatory hold-down period is only 30 days. The SSAC requests an explicit operational justification for this duration and suggests evaluating a threshold-based approach using telemetry from the 2018 and ongoing 2025 rollovers, which could allow a shorter Phase EE if the ecosystem is ready while preserving the ability to extend if it is not. AA (ECDSA KSK generation and secure storage, with no root zone changes) targets Q2/2027, approximately six months after the October 2026 KSK rollover. The SSAC questions why Q4/2026 could not serve as a start date, given that the required personnel, facilities, and procedures will have just been exercised. A shorter overall timeline would also reduce the total time the 1536-bit RSA ZSK remains in active use. The SSAC additionally notes that while DNSSEC does not face the same post-quantum urgency as other protocols already deploying PQC, avoiding prolonged use of a reduced-strength RSA ZSK would reflect sound planning. *Missing Success Criteria* The SSAC notes that while the plan includes flexible phase scheduling, it lacks defined success criteria or specific thresholds for each phase that would determine when a schedule extension is necessary or when it is safe to resume. Without these, there is no objective basis for phase transition decisions. *Operational Readiness* The SSAC finds the ecosystem well-prepared for the transition: - Algorithm 13 is a mandatory implementation algorithm under RFC 8624 and RFC 9904. - Algorithm 13 deployment surpassed Algorithm 8 globally as of April 2024 and continues to grow. - Algorithm 13 is deployed by major TLDs (.com, .net, .gov) without reported issues. - SIDN's completed algorithm rollover for .nl in 2023 confirmed broad resolver support. - All major open-source resolvers (BIND, Unbound, Knot Resolver, PowerDNS Recursor) and commercial DNS platforms support Algorithm 13. - ICANN's Thales Luna G7 HSMs have been confirmed ready for ECDSA within the DNSSEC Practice Statement. - RFC 5011 remains the primary mechanism for resolver trust anchor updates. *Operational Conventions* The use of distinct phase identifiers (AA through HH) to differentiate this algorithm rollover from prior non-algorithm rollovers is noted as a sensible convention. Link: https://itp.cdn.icann.org/en/files/publications/sac-133-10-04-2026-en.pdf. Best, Matthias _______________________________________________ At-Large mailing list -- at-large@icann.org To unsubscribe send an email to at-large-leave@icann.org At-Large Official Site: http://atlarge.icann.org _______________________________________________ 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. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . .