Algorithm Implementation Requirements and Usage Guidance for DNSSEC
draft-ietf-dnsop-algorithm-update-10
Yes
(Alexey Melnikov)
(Ignas Bagdonas)
(Warren Kumari)
No Objection
(Alvaro Retana)
(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)
(Suresh Krishnan)
Note: This ballot was opened for revision 06 and is now closed.
Roman Danyliw
No Objection
Comment
(2019-04-12 for -09)
Sent for earlier
Thank you for addressing my COMMENTS.
Adam Roach Former IESG member
Yes
Yes
(2019-04-09 for -08)
Sent
Thanks to everyone who worked on this document. I agree with Benjamin's comments regarding the need to move any reference that pertains to a normative statement in this document -- including the normative language in the §3.1 and §3.3 tables -- into the "Normative References" section. --------------------------------------------------------------------------- §1.1: > New, stronger > algorithms appear and existing algorithms are found to be less secure > then originally thought. Nit: "...than originally thought..." ^ Nit 2: This text describes the diminished desirability of older algorithms only in the context of hardware advancements, which are usually incremental and can be seen coming (although progress on large quantum computers might change this). It should probably also mention the possibility of newly-discovered vulnerabilities that can render algorithms undesirable instantaneously (see, e.g., the MD5 Verisign root cert exploit demonstrated by Sotirov et al in 2008), as this serves as a far more compelling motivation to get the new algorithms in the field before they're strictly needed. --------------------------------------------------------------------------- > RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones > deploying it Nit: "...deploying them..."
Alexey Melnikov Former IESG member
Yes
Yes
(for -07)
Not sent
Alissa Cooper Former IESG member
Yes
Yes
(2019-04-08 for -07)
Sent
Please respond to the Gen-ART review. In line with Mirja's comment, if the WG or someone in it were planning on maintaining the 4.1 comparison table somewhere less stable than an RFC, that seems like it could be useful and could be linked to from the WG datatracker page.
Barry Leiba Former IESG member
Yes
Yes
(2019-04-07 for -07)
Sent
— Section 1.2 — This document only provides recommendations with respect to mandatory-to-implement algorithms or algorithms so weak that recommendation cannot be recommended. “...so weak that their use cannot [or perhaps can no longer] be recommended.”
Ignas Bagdonas Former IESG member
Yes
Yes
(for -08)
Not sent
Warren Kumari Former IESG member
Yes
Yes
(for -06)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -09)
Not sent
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2019-04-05 for -07)
Sent
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.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -08)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -07)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -08)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2019-04-03 for -07)
Sent
I wonder if it makes sense to keep section "4.1. DNSKEY Algorithms" with the table in the document. Of course this is only a current snapshot but probably gives readers also in future a good indication with tools to look at.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -09)
Not sent