Paul Wouters has entered the following ballot position for draft-ietf-dnsop-rfc8624-bis-10: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/ ---------------------------------------------------------------------- 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" ? 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. 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. 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. It seems the section on Operational Considerations has nothing to do with this document, as this document doesn't handle algorithm rollovers at all? What I would consider a related Operational Considerations is for implementers to start throwing warnings on algorihtms that they plan to remove from their code before actually removing it from their code causing errors as to give operators the time to migrate away from them. ---------------------------------------------------------------------- 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. 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. 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. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
