Folks,
I’d like to introduce the -01 version of this draft (the -00 was uploaded to the data tracker, but I never saw it posted here). The idea is to allow the KSK and the ZSK of a zone to use *different* signature algorithms. During experiments with different ways of navigating the conflict between different PQ-safe algorithms and the 1232 byte constraint when using UDP we realized that essentially all the problems boils down to the requirement to use the same algorithm for both KSK and ZSK. Without that requirement suddenly "PQ-DNSSEC" has a number of solutions that work fine over UDP. The interesting question is whether it is possible to relax that requirement in a safe way. I argue that this is possible. The point is that a KSK and a ZSK have genuinely different requirements, yet today we are forced to pick a single algorithm that serves both. This is also visible operationally: rolling a ZSK is trivial and can be done frequently, while rolling a KSK is more involved (it requires interaction with the parent) and is therefore often done rarely, or in practice not at all. Those facts point in opposite directions. A KSK signs one RRset (the apex DNSKEY) and is referenced by the parent's DS; because it rolls rarely, what matters for it is strength and longevity -- and its signature size is almost irrelevant. A ZSK signs the entire rest of the zone and may roll frequently; what matters for it is small signatures, so that ordinary responses stay small. With a PQ algorithm the DNSKEY RRset is going to grow regardless of which algorithm we choose -- the key, the signature, or both will be large for any of them. So the realistic questions are not "how do we avoid that” but: (a) DNSKEY queries: switch to a transport for large responses. And the parent's DS already carries the KSK algorithm number, so a validator can tell from the DS alone that the DNSKEY RRset is likely large and go straight to such a transport, skipping the truncate-then-retry round trip. (b) all other queries: keep them small by letting the ZSK use an algorithm with small signatures -- which is fine, because the ZSK *key* already lives inside the (already large) DNSKEY RRset. This is exactly what algorithm splitting enables: choose the KSK for KSK requirements, the ZSK for ZSK requirements. The consequence is that we need to adapt one rule to today's changing requirements. RFC 4035’s algorithm-completeness rule -- which requires every algorithm in the DNSKEY RRset to sign every RRset in the zone -- predates the prospect of a large PQ KSK paired with a small ZSK, and under that rule a PQ KSK would force a PQ signature onto every RRset. The draft therefore argues for relaxing the completeness rule. The relaxation is safe because the two algorithms are not peers: they sit in a fixed chain (DS authenticates the KSK, the KSK authenticates the ZSK, the ZSK signs data), so the peer-substitution downgrade that completeness guards against cannot occur. The forgery-window bound that completeness also gave is replaced by a bounded ZSK rotation cadence; the Security Considerations are explicit about that trade. Reviews and pushback both welcome -- in particular, we'd like to hear how people think the completeness rule should evolve to accommodate the KSK/ZSK asymmetry that PQ algorithms bring. Johan Stenstam
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
