Re: [DNSOP] [Ext] DNSSEC Strict Mode

[Samuel Weiler <[e-mail]>]

On Thu, 25 Feb 2021, Ben Schwartz wrote:

> On Thu, Feb 25, 2021 at 10:26 AM Paul Hoffman <[e-mail]> 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?