Paul Wouters via Datatracker <[email protected]> writes: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have some questions I would like to see a short discussion on before > balloting Yes > > > The columns added to the IANA "DNS Security Algorithm Numbers" > [DNSKEY-IANA] > > While doing IANA updates, can this document perhaps also update the name "DNS > Security > Algorithm Numbers" because it is very confusing. It is only the DNSKEY > algorithm numbers, > used in some other records too (eg RRSIG). But there are other algorithm > numbers in DNSSEC > too, and which are not covered by this one (eg DS algorithm numbers). > > Perhaps "DNS Signature Algorithm Numbers" ?
Though I understand the point, I really really don't think such a change should be made in this document. We've tried to make this document focus only on the task at hand, and that's throwing a whole other goal at the document that hasn't had any community discussion. [but I do agree that the two tables are rather confusing... The number of times Warren and I have had to consult the tables and re-learn how they actually work has probably grown beyond counting on two hands at this point] > RECOMMENDED / MUST / MAY > > I wonder why the document uses the levels RECOMMENDED with MAY and MUST, > instead of either > MAY/SHOULD/MUST or RECOMMENDED/NOT RECOMMENDED/MAY. The WG had a discussion about the right wording to use, and this was the consensus selected. Part of the MUST vs RECOMMENDED text comes from not wanting 2 MUSTs assigned to the "Use for" concept as what does that mean? You MUST publish all versions, etc. Instead RECOMMENDED was selected after that discussion to ensure we didn't run into trouble with places where counts other than 1 were needed. There are certainly youtube recordings of this discussion in the DNSOP meeting archives. > Validating recursive resolvers are encouraged to retain support > for all algorithms not marked as MUST NOT. > > Why "encouraged"? This is a perfect spot to use SHOULD or RECOMMENDED, since > it is aimed at implementers of resolvers. Because some of them are MAYs and I don't think you should say SHOULD support a MAY. But your point is valid. It's also confusing because of the word "retain". I'm actually thinking that sentence should go away as I'm not sure it adds anything that aren't already in the recommendations table. Thoughts? > When there are multiple RECOMMENDED algorithms in the "use" > column, operators should choose the best algorithm according to > local policy. > > This reads weird. An operator for a resolver has no real choices for > selecting the best algorithm - the algorithm is set by zone owner, not > the operator of the resolver. I think this sentence should be rewritten > to be signer specific (and publisher specific for DS in the next section), > and a new sentence for resolvers should be added to say something. Validators also get to pick which algorithms they support vs considering anything else to fall into an insecure tree. > It seems the section on Operational Considerations has nothing to do with > this document, as this document doesn't handle algorithm rollovers at all? Well, the document does talk about standardization levels and thus hints at "times are not static forever" and offers guidance for when levels do change (and the table is thus updated). Is it directly reflecting the point of the draft? you're probably right, no. Is it helpful to the reader anyway? probably Is it harmful to have in there? probably not > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Implementations need to be conservative in the selection > of algorithms they implement in order to minimize both code > complexity and the attack surface. > > I don't think this is particularly true or relevant. The real issue is that > DNS > has a long tail and it becomes very difficult to remove old algorithms, so > introducing new ones should be done with constraint. Minimizing code complexity and attack surface are definitely factors in implementations that I'm aware of (DNS or otherwise). Though adding text based on your other comment is possible. Maybe: "Deployed algorithm usage in DNSSEC does not change quickly, and thus constraint should be used when adding new algorithms"? > The perspective of implementers may differ from that of an > operator who wishes to deploy and configure DNSSEC with only > the safest algorithm. > > I think this mixes up implementers/operators with the actual real difference > of resolvers/signers. Signers wish to use the best ones, but resolvers need > to handle older/worse stuff as well. This text is discussion implementation vs operations, but your text is only about operations (signing vs validation) and thus different in nature. If anything, we could talk about both but I think the current statement concept is still needed. > Since the effect of using an unknown DNSKEY algorithm is that > the zone is treated as insecure > > I would use "unsigned" instead of "insecure" here. Maybe: "as unsigned, which results in an insecure delegation"? -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
