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

[Bob Harold <[e-mail]>]

On Fri, Apr 5, 2019 at 12:21 PM Benjamin Kaduk via Datatracker <
[e-mail]> 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