Algorithm Implementation Requirements and Usage Guidance for DNSSEC
draft-ietf-dnsop-algorithm-update-10
Yes
Warren Kumari
(Alexey Melnikov)
(Ignas Bagdonas)
No Objection
(Alvaro Retana)
(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)
(Suresh Krishnan)
Note: This ballot was opened for revision 06 and is now closed.
Warren Kumari
Yes
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
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