Hi,
We've posted an update to this draft, which in many ways is an extension of RFC 9859 (Generalized Notifications) in the sense that instead of sending generalized notifications on changes to DNSKEYs or delegation info, the child (or its agent) instead sends a DNS UPDATE to the target of a DSYNC UPDATE announcement by the parent. The -02 changes fall into three buckets: 1. Making the SIG(0) bootstrap more robust. The "Management of SIG(0) Public Keys" section was restructured to expose the two-direction symmetry -- bootstrapping the child's key into the UPDATE Receiver, and bootstrapping the Receiver's key into the child -- as a single coherent section rather than two loosely related ones. We also added a baseline retry policy for the case of a missing UPDATE response. Finally, a section has been added on coordinating the at-ns bootstrap method via the HSYNCPARAM pubkey key (with an IANA request for a (KEY, _signal) entry in the RFC 8552 registry). 2. Looking ahead to PQ. A new section covers choosing a PQ-safe SIG(0) algorithm for this path. Because the UPDATE path is infrequent and TCP-based, signature size is not a constraint -- so we can use a PQ-safe algorithm here today. Our testbed on the public Internet has successfully rolled its KSK more than 7000 times, with zero outages, authorized by a SIG(0) signature using the NIST-standardized PQ-safe algorithm ML-DSA-44. 3. Clarity and prototype work. A fair amount of text was rewritten for clarity, and the prototype implementation in tdns is now substantially more complete, which shook out a number of small specification issues along the way. The companion draft draft-berra-dnsop-keystate has also been updated (-03) in step with these changes, so the two stay aligned. The keystate draft has been simplified, but the ability to query the parent for the status of a SIG(0) key is still needed. Reviews welcome. Johan Stenstam
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
