On Oct 15, 2024, at 07:49, Wes Hardaker <wjh...@hardakers.net> wrote: > > Paul Hoffman <paul.hoff...@icann.org> writes: > >> In specific, "Use for DNSSSEC Signing" and "Use for DNSSSEC >> Delegation" do not make sense if there is more than one "MUST" in that >> column. You cannot use two algorithms to sign or delegate at the same >> time. > > Thank you for the analysis. I think there are three (obvious) paths forward: > > 1. Define what MUST means in the context for the Use columns. > 2. Use RECOMMENDED instead. > 3. Only allow a single MUST in the Use column because that's what we want > people to really use (which does sound more like a SHOULD). IE, if we > believe ideally there should be one cryptographic algorithm deployed to > simplify the deployed base, we could pick this route. I doubt it would be > popular though, as we already have a fractured ecosystem and it is generally > working. > > Feedback from the WG appreciated :-)
Yes, please! My preference would be #2. If we do #1, it will not match what most IETFers think of "MUST". #3 seems like it would increase ossification, which is the opposite direction from what the IETF is moving. >> How can both 8 and 13 be "MUST use for signing" at the same time? > > Do note that this problem actually isn't new, technically. We disagree. > The values > we pick basically mirror 8624 but 8624 really didn't talk about recommending > *usage* which is what the discussion around this document clearly picked up. It always made sense to say to implementers that they must implement more than one algorithm in their products. The current draft basically adds "and you have to use more of them at the same time, but we can't say how". > Note that 8624 has this to say as well: > > [RFC2119] considers the term SHOULD equivalent to RECOMMENDED, and > SHOULD NOT equivalent to NOT RECOMMENDED. The authors of this > document have chosen to use the terms RECOMMENDED and NOT > RECOMMENDED, as this more clearly expresses the intent to > implementers. > >> How can 14 and 16 be "MAY use for signing" if there are other values >> that MUST be used instead? > > I think that switching to "RECOMMENDED" from "MUST" may solve your concerns? It would, but let's see what the rest of the WG says. (It still would be good to add a sentence or two saying "when there are multiple recommended algorithms in the "use" column, you get to choose the one you want based on local policy". >> Is 15 more recommended than 14 and 16 even though 14 and 16 are >> currently obviously stronger? > > There is no intent to do algorithm comparisons by values encoded in the > columns. I think that's more what Steve and Russ' document are likely > targeting. More importantly, I don't think we should have comparison text > and each row should stand alone. In that case, I request that 14, 15, and 16 be at the same level for "use". It is a bad smell for the WG to say "this weaker algorithm is better for reasons we are not saying". > If you have specific concrete suggestions for value changes, it would be > helpful but do note our goal was to do value changes generally in follow on > documents. We had to break that a little bit because we doubled the number > of recommended columns by adding the "Use" ones. We can't break it "a little bit". The recommendations in this document are all of equal importance. --Paul Hoffman _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
