Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-algorithm-update-07: No Objection
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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a little surprised that this is going for PS rather than BCP, which seems like it would reflect the recognized need for recurring updates to the guidance given. In a similar vein, if we stay at PS, a lot of the references seem like they would need to move from Informative to Normative, since to implement the various MUST-level algorithms you have to follow those references. Section 1.1 The field of cryptography evolves continuously. New stronger algorithms appear and existing algorithms are found to be less secure then originally thought. [...] I'd suggest also noting that attacks previously thought to be computationally infeasible become more accessible as the available computational resources increase. Section 1.2 For clarification and consistency, an algorithm will be specified as MAY in this document only when it has been downgraded. Does "downgraded" mean that it was formerly mandatory but has been rotated out of the mandatory role? Perhaps explicitly saying "downgraded from <blah>" would aid clarity. Section 3.3 SHA-384 shares the same properties as SHA-256, but offers a modest security advantage over SHA-384 (384-bits of strength versus nit: SHA-384 has an advantage over ... SHA-384? recommended for DS and CDS records. While it is unlikely for a DNSSEC use case requiring 384-bit security strength to arise, SHA-384 is provided for such applications and it MAY be used for generating DS and CDS records in these cases. My understanding is that generally we refer to SHA-384 as providing 192-bit security, though of course that's a vague/generic statement and more specific ones are possible. Section 8 We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur Gudmundsson, Paul Hoffman and Evan Hunt for their imminent feedback. IIRC a directorate reviewer noted that "imminent" means "expected to arrive in the near future but not yet present"; such text does not seem appropriate for final publication since review after that point would not be helpful. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
