I am wondering what the behavior would be if
- the DS RRset signals two algorithms
- the validator disables support for one of those algorithms
- requests a RRset from a certain provider that signs with that algorithm
Correct me if I am wrong:
- The desired behavior according to this draft is to treat this response
as insecure.
- The behavior according the existing DNSSEC rules is to treat it as bogus.
I would not like to make exceptional behavior for an algorithm not
supported and a disabled algorithm.
Best regards,
Matthijs
On 10/21/25 11:21, Peter Thomassen wrote:
Hi,
We've updated draft-huque-dnsop-multi-alg-rules yesterday (mostly
editorial/clarity fixes).
A significant addition though is the insertion of new Section 1, called
"tl;dr: Nutshell Proof of Sanity".
Without going into solution details, this section is trying to establish
a baseline understanding of why the proposed adjustment of validation
rules is neither far-fetched nor dangerous, but actually a very natural
refinement.
You can read the tl;dr here, it's pretty short: https://www.ietf.org/
archive/id/draft-huque-dnsop-multi-alg-rules-07.html#name-tldr-nutshell-
proof-of-sani
Note that the proposal does NOT change anything for validators which
follow algorithm support requirements. It only affects validators with a
local policy to not support a mainstream algorithm which they would be
expected to support. The goal is to adjust things slightly, to handle
this case more gracefully.
The authors would like to encourage discussion about this baseline
objective (without going into the "how" of the proposal).
We'd like to hear both support for and technical objections to the
Nutshell Proof of Sanity, so we can put subsequent work on more solid
footing.
Thanks!
Cheers,
Peter
(for the co-authors as well)
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
