On Fri, Apr 5, 2019 at 12:21 PM Benjamin Kaduk via Datatracker < [email protected]> wrote:
> 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. > I think the word they wanted is "eminent". -- Bob Harold
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
