[COSE] Roman Danyliw's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-cose-hash-algs-04: 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-cose-hash-algs/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for extending COSE for this additional use.

** I added my thoughts on the Section 2 language to the email thread of Barry’s
ballot

** Per “To distinguish between these two cases, a new value in the
   recommended column of the COSE Algorithms registry is to be added.
   "Filter Only" indicates that the only purpose of a hash function
   should be to filter results and not those which require collision
   resistance”, I would recommend:

NEW:
To distinguish between these two cases, a new value in the recommended column
of the COSE Algorithms registry is to be added.  "Filter Only" indicates that
the only purpose of a hash function should be to filter results and it is not
intended for applications which require a cryptographically strong algorithm is
needed.

It doesn’t change the intent, but it does generalize to all the security
properties we might want of a hash algorithm.

** Section 5.  Since collision and second-preimage attacks are mentioned, for
completeness it would be worth mentioning the need for preimage resistance for
cryptographic usage too.

** Editorial nits:

-- Abstract.  Editorial. The abstract has an explicit reference,
[I-D.ietf-cose-rfc8152bis-struct], which abstracts are not permitted to have.

-- Section 2.1. Editorial.  s/this could /This could/

-- Section 3.1. Editorial. s/assign a point/assign a code point/

-- Section 3.2. Editorial.

OLD
Locations that use this hash function
      need either to analysis the potential problems with having a
      collision occur, or where the only function of the hash is to
      narrow the possible choices.

NEW
Applications that use this hash function need either to analyze the potential
impact with having a collision occur, or use it only where the function of the
hash is to narrow the possible choices.

-- Section 3.3.  Per “The pair of algorithms known as SHAKE-128 and SHAKE-256
are the instances of SHA-3 that are currently being standardized in the IETF”,
it isn’t clear this sentence will age well.

-- Section 4.  Typo. s/preseved/preserved/