1. The False Dichotomy of Cryptographic Degradation vs. UDP Truncation

Critique: The proposal justifies reducing the RSA ZSK to 1536 bits to prevent root zone referral and NXDOMAIN responses from exceeding the 1232-byte UDP buffer size established by the 2020 DNS Flag Day. This trades fundamental cryptographic strength for protocol convenience. The 2020 Flag Day was designed to prevent UDP fragmentation, not to eliminate TCP fallback. By choosing an unstandardized, weaker RSA key size (which drops security well below modern 112-bit baselines) for a span of three years, ICANN is inverting security priorities. Modern authoritative root servers and recursive resolvers are highly optimized for TCP.

Proposed Solution: Do not degrade the RSA ZSK. I propose two alternatives:

Alternative A (Preferred): As suggested by others, roll the ZSK algorithm to ECDSA P-256 prior to the KSK algorithm rollover. Since Verisign successfully transitioned massive zones like .com and .net to ECDSA using a double-signing approach with no end-user disruption, the root zone maintainers already possess the operational telemetry to execute this safely.

Alternative B: Maintain the 2048-bit RSA ZSK and allow the double-signed responses to exceed 1232 bytes, actively triggering the Truncated (TC) bit. Use the transition period to actively enforce and test the ecosystem’s TCP compliance, which aligns with broader IETF efforts (like DNS over Quic/TLS) that assume reliable transport layers.

2. The Cryptographic Stockpiling Risk of Pre-Computed SKRs

Critique: The operational plan relies heavily on generating multiple parallel Signed Key Responses (SKRs) during quarterly ceremonies to account for forward transitions, extensions, and backouts (e.g., generating CC→DD, DD→CC, and CC→CC simultaneously). While this allows agility, storing pre-computed signatures for backward state transitions creates a novel "cryptographic stockpiling" vulnerability. If a malicious actor infiltrates the distribution pipeline and exfiltrates the DD→CC SKR, they could potentially execute an unauthorized downgrade attack, forcing the root zone back to a weaker state without ever needing access to the physical HSMs.

Proposed Solution: Transition states should not rely on "cold storage" SKRs. I recommend implementing a time-bound cryptographic lock on backout SKRs. For example, backout SKRs could be encrypted using a Shamir Secret Sharing scheme, where the decryption keys are distributed among Trusted Community Representatives (TCRs). A rollback should require a verifiable, mini-ceremony to unlock the backout state, ensuring that downgrade files cannot be unilaterally or maliciously deployed.

3. Redundancy and Obscurity in Phase DD

Critique: Phase DD introduces ECDSA signatures without publishing the corresponding DNSKEYs. As noted by cryptographic standards, ECDSA public key recovery is trivial when multiple signatures are available. Therefore, Phase DD operates purely on security through obscurity and needlessly extends the timeline of the transition while adding operational complexity.

Proposed Solution: Eliminate Phase DD entirely and merge it into Phase EE. Introduce the ECDSA signatures and the ECDSA DNSKEYs simultaneously. This "flash cut" of the new algorithm data is exactly how standard double-signing is executed at the TLD level. Removing Phase DD simplifies the state machine and removes an entire quarter of operational risk.

4. Telemetry-Driven Revocation (Phase FF) instead of Static Timers

Critique: The proposal designates a static 70-day period (from day 11 to day 81 of the quarter) for the RSA KSK to be published with the REVOKE bit set before deletion. Given the heterogeneity of global resolver caching behavior, a static day-count is an arbitrary metric that risks breaking validation for edge networks that fail to update trust anchors promptly.

Proposed Solution: Shift from a time-based revocation window to a telemetry-based threshold. The revoked RSA KSK should remain in the root zone until queries requesting the old trust anchor (via RFC 8145 signaling or passive root server telemetry) drop below a predefined statistical noise threshold (e.g., less than 0.5% of total validation queries). The Bylaws or operational procedures should state that the key is removed on day 81 only if the telemetry threshold is met; otherwise, the revoked key publication is extended.

The proposal to reduce the RSA ZSK to 1536 bits is misguided, prioritizing UDP packet size over essential cryptographic strength and disregarding modern security standards. Furthermore, the reliance on pre-computed SKRs creates significant risk of unauthorized downgrade attacks, while the inclusion of Phase DD relies on security through obscurity, and the static 70-day revocation timer for the RSA KSK is an arbitrary metric that ignores global resolver caching issues.

To resolve these issues, I propose shifting directly to an ECDSA P-256 ZSK or maintaining the 2048-bit RSA key while enforcing TCP compliance. Additionally, I recommend using a Shamir Secret Sharing scheme to secure rollback SKRs, eliminating the redundant Phase DD for a flash cut, and implementing telemetry-driven revocation to ensure the old key remains until reliance falls below a specific threshold.