Hello Shumon,
It is great to see I were not the only one thinking about it. But I
think forcing servers to send all signatures unless the client supplied
list of supported algorithms is not helpful. DO bit were introduced to
hide new features from older implementations. I think we need the same
here. Kind of DO2 bit, but it needs list of algorithms.
My variant is similar in some parts, but differs in few.
- resolver or forwarder needs to signal upstream server a need for more
than one desired algorithm
- ordered list works well only for end clients.
- if resolver needs to re-fetch something it already has, it should do
that with combined requirements from clients
More below.
On 19/10/2025 15:46, Shumon Huque wrote:
I see that this draft was recently published, but hasn't seen
discussion on list yet:
https://datatracker.ietf.org/doc/html/draft-sheth-pqc-dnssec-strategy-00
This does not mention at all how should it be deployed. Sure, it needs
hackatons with support for those algorithms. But we also need a way for
efficient switch from more adopted to less adopted algorithms. Without
going insecure for TLD zones or even root zone. I miss outlined strategy
in this document for it, although its title suggests it should be included.
See this attempt a few years ago to propose algorithm negotiation in
DNSSEC:
https://datatracker.ietf.org/doc/html/draft-huque-dnssec-alg-nego-03
It was discussed at IETF at the time, but there was significant
pushback (mainly
no compelling justification to introduce such additional complexity).
I still think
it's a reasonable idea though.
Shumon.
Yes, I agree. TLS protocol allows the same thing. You have certificate
chains, signed by multiple algorithms. Two separate chains at server.
But client receives only one chain, the one most preferred and most
secure. Difference is TLS is always between end client and the
authoritative server. Nothing in between. But that is solvable.
I think Clients in section 4 can signal their preference by ordered list
only for themselves. Recursive resolvers, which might have two clients
with different top preferred algorithms need a way to request signatures
for both top algs of them. That is why my DAP is unordered and if
contains multiple algorithms, multiple of them should be send by the
server. I think that is mandatory.
Section 5, change to server is mistake to send SERVFAIL. If client
supports different algorithms than server offers, the result for this
algorith on client would be insecure. Server can send no signatures at
all, but it MUST send algorithm list it has signatures for. If that is
problem on client, then it indicated supported algorithms wrong way.
Section 6, I solve this by requesting combined DAP from clients. It
should receive multiple signatures, if multiple clients indicated
different preference.
Section 7, client can solve this by including all supported algorithms
in DAP. Either it receives some supported signatures or client will emit
stripped signatures validation error. If PQC is delegated by DS parent
record and DNSKEY is missing RRSIG for PQC, then client should fail with
SERVFAIL status.
Section 8. I propose to have opt-in system. If something strips new
EDNS0 options, it should work like legacy validating servers with just
DO=1 set. My variant allows signing even production zone with
experimental algorithm. Clients without support for this new extension
would not know the server supports something new. Would not be bothered
and would still have AD bit set. Very similar to DO bit requirement for
DNSSEC aware clients protecting ancient software stacks.
I think your proposal is good, but needs some bits tuned. The most
important, I think auth server needs a freedom to omit some signatures,
unless client indicated support for them. Offering new features only to
new clients ready to consume them. Request to offer all algorithms
should be something new.
But thank you for sharing your draft! I can lookup some arguments to it
and think how to fix them.
Best regards,
Petr
--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
