There is a trick available which might or might not be a good idea:
Define a single DNSSEC "algorithm" (with a given assinged number) which
in fact uses different cryptographic algorithms for KSK and ZSK,
respectively.
It would be completely okay for RFC 4035 and all the DNSSEC operations,
since from the perspective of DNSSEC it's still a single "algorithm";
and it would do the proposed job of quantum-secured DNSKEY signature and
small other signatures.
Regarding relaxing RFC 4035 requirements: I think it's pretty difficult.
For now, I'd like to see draft-huque-dnsop-multi-alg-rules move forward.
Yet your question seem to be slightly different.
Libor
On 27. 06. 26 0:38, Johan Stenstam wrote:
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 [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
