Thank you sir for sharing. Very valuable indeed. Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround* ============================= On Thu, 24 Jul 2025 at 08:28, Matthias M. Hudobnik via ALAC <alac@icann.org> wrote:

Dear Colleagues,

The SSAC welcomes the opportunity to comment on ICANN’s Draft Applicant Guidebook (AGB) for the New gTLD Program: Next Round. Our comments focus on improving *Section 6.7 on Name Collisions*, with an emphasis on risks arising from *collisions between DNS and alternative naming systems* (e.g., blockchain-based systems), as outlined in the Name Collision Analysis Project Study 2 Report (NCAP2). Summary of Key Recommendations:

1.

*Clarify TRT’s Role in Initial Assessments* AGB §6.7.2 does not clearly state that the *Technical Review Team (TRT)* conducts the initial name collision risk assessment. NCAP2 indicates TRT is responsible from the outset. *Recommendation:* Explicitly assign the initial assessment to the TRT. 2.

*Enable Pre-Delegation Action on High-Risk Strings* Current language suggests high-risk strings are identified only after temporary delegation. NCAP2 supports action based on existing data. *Recommendation:* Allow TRT to recommend withholding delegation if early analysis shows high risk. 3.

*Broaden TRT’s Assessment Scope Beyond DNS Data* Limiting analysis to DNS logs misses collisions from alternative namespaces that resolve via DNS (e.g., users accustomed to *.wallet* from blockchain). ➤ *Recommendation:* Permit use of OSINT, qualitative assessments, and external data sources per NCAP2. 4.

*Allow TRT Flexibility to Evolve Assessment Methods* AGB cites four NCAP2 methods (NI, CI, VI, VIN), but doesn’t state whether TRT may adopt new techniques. *Recommendation:* Affirm TRT’s discretion to evolve methods to address future risks.

These updates will better align the AGB with NCAP2 and ICANN Board guidance, while improving transparency, security, and technical rigor in handling name collisions.

The SSAC appreciates the efforts of the ICANN org and Subsequent Procedures IRT, and we are available for further discussion.

Link: https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee... .

Best,

Matthias _______________________________________________ ALAC mailing list -- alac@icann.org To unsubscribe send an email to alac-leave@icann.org

At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...) _______________________________________________ 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 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