Subject: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-algorithm-update-07: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 05 Apr 2019 09:21:04 -0700

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.

---

From: Bob Harold <[email-masked]>
Date: Fri, 5 Apr 2019 12:37:30 -0400

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/

I think the word they wanted is "eminent".

-- 
Bob Harold

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Apr 2019 07:55:36 -0400 (EDT)

>       updates to the guidance given.

Personally, it seems a PS feels like it has a little more weight. Not
just a recommendation but a strong nudge towards doing this.

>       implement the various MUST-level algorithms you have to follow those

I would not say those references are normative in that sense. You don't
HAVE to read how GOST is specified to not implement it.

>       computational resources increase.

Added.

>       "downgraded from <blah>" would aid clarity.

Added.

>       nit: SHA-384 has an advantage over ... SHA-384?

Fixed.

>       appropriate for final publication since review after that point would

That was fixed too :)

Thanks for the review!

Paul

---

From: Warren Kumari <[email-masked]>
Date: Thu, 11 Apr 2019 12:20:21 -0400

[ - IESG (for clutter), Bob & Tim (through DNSOP / Chairs respectively) ]

On Tue, Apr 9, 2019 at 7:55 AM Paul Wouters <[email-masked]> wrote:

> [ SNIP ]
Perhaps, but there are still lots of Informative references which
implementers would need to read. For example:

RFC5702, RFC6605:
8 RSA/SHA-256 RSASHA256 Y * [RFC5702]
10 RSA/SHA-512 RSASHA512 Y * [RFC5702]
13 ECDSA Curve P-256 with SHA-256 ECDSAP256SHA256 Y * [RFC6605]

RFC4509:
2 SHA-256 MANDATORY [RFC4509]

It is a simple matter to make these Normative....

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Apr 2019 14:24:26 -0500

> It is a simple matter to make these Normative....

I'll also note (sic) that note 1 at
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/
says:

  Even references that are relevant only for optional features must be
  classified as normative if they meet the above conditions for normative
  references.

-Ben