Algorithm Implementation Requirements and Usage Guidance for DNSSEC

Note: This ballot was opened for revision 06 and is now closed.

Ignas Bagdonas Yes

Alissa Cooper Yes

Comment (2019-04-08 for -07)
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.

Warren Kumari Yes

Barry Leiba Yes

Comment (2019-04-07 for -07)
— Section 1.2 —

   This document only provides recommendations with respect to
   mandatory-to-implement algorithms or algorithms so weak that
   recommendation cannot be recommended.

“ weak that their use cannot [or perhaps can no longer] be recommended.”

Alexey Melnikov Yes

Adam Roach Yes

Comment (2019-04-09 for -08)
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.



>  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..."

Deborah Brungard No Objection

Roman Danyliw No Objection

Comment (2019-04-12 for -09)
Thank you for addressing my COMMENTS.

Benjamin Kaduk No Objection

Comment (2019-04-05 for -07)
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

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.

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Comment (2019-04-03 for -07)
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.

Alvaro Retana No Objection

Martin Vigoureux No Objection

Magnus Westerlund No Objection