Dear Colleagues, please find below my report. Have a nice day! Best, Matthias General: 1. Webinar Series with ISPCP The next planned ones are: * Jun (ICANN86): (1)Post-Quantum Transition & (2) Privacy vs. Security * Sept: The Evolving Role of SSAC in Global Governance * Oct: DNSSEC and the Future of Trust * Nov (ICANN87): (1) Routing Security (MANRS) & (2) DNS Configuration Best Practices 2. ICANN 86: BC & SSAC Plenary on Artificial Intelligence and DNS Abuse Planning for the session is already fully underway. The organizing team has already held two coordination and planning sessions to define the scope, structure, speakers, and key discussion topics for the plenary. This collaborative session reflects the growing recognition within the ICANN community of the need to address the evolving intersection of AI technologies and DNS abuse, and underscores the value of cross-community cooperation in tackling emerging challenges. Publications: SAC133: SSAC Comments on Proposed Root KSK Algorithm Rollover 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. Ongoing work parties: * DNSSEC Operational Considerations Work Party * Responsible Integration of External Technologies into the DNS * DNS Abuse and Artificial Intelligence * DNS Transparency SSAC Membership Committee: The application window for SSAC membership is now open. Interested candidates are encouraged to submit their applications during this period. Further details on the application process and eligibility criteria can be found on https://www.icann.org/en/ssac. [1] Links: ------ [1] https://www.icann.org/en/ssac