On Thu, 25 Feb 2021, Ben Schwartz wrote:
On Thu, Feb 25, 2021 at 10:26 AM Paul Hoffman <paul.hoff...@icann.org> wrote: In reading draft-schwartz-dnsop-dnssec-strict-mode, I still don't understand why it is even useful. If I am signing one of my zones with two algorithms, I must intend to do so. What is the value of me saying that only one of the signing algorithms is the strong one?That's not especially the intent. Currently, if you sign with two algorithms, and either of those algorithms becomes insecure*, your zone becomes susceptible to forgery. If you mark both algorithms as Strict, then your zone remains secure (for validators who implement both algorithms and this draft). Marking only one algorithm as Strict is necessary during certain transitions but is not otherwise very useful. *possibly unbeknownst to the public
While I remain unconvinced...This piece of the use case - though not the "my algorithm isn't supported everywhere" case - seems like it could also be solved by defining a new signature algorithm type, e.g. RSASHA512+ECDSAP384SHA384 [*], where a single (very long) DNSKEY record has keying material for multiple underlying crypto suites and a single (likely also long) RRSIG of this type has signatures for multiple suites. Specify the "algorithm" as only validating when all of the pieces separately are valid - essentially, define an algorithm that is at least as strong as the strongest, not the weakest, one of the set.
Someone will aruge that this needlessly burns a codepoint from an 8-bit field, potentially even burning them as pairwise combinations of underlying algorithms. But it is a different way of doing the signaling, and the resolver logic feels, intuitively, a little simpler.
-- Sam [*] is that an algorithm identifier or a crypto key in its own right?
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
