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

[Roman Danyliw <[e-mail]>]

Hi Jim!

Thanks for the quick response. You refinements below are an improvement over mine.  Thanks for making them.

Regards,
Roman

> -----Original Message-----
> From: Jim Schaad <[e-mail]>
> Sent: Tuesday, June 9, 2020 12:17 AM
> To: Roman Danyliw <[e-mail]>; 'The IESG' <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> 'Ivaylo Petrov' <[e-mail]>
> Subject: RE: Roman Danyliw's No Objection on draft-ietf-cose-hash-algs-04:
> (with COMMENT)
> 
> 
> 
> -----Original Message-----
> From: Roman Danyliw via Datatracker <[e-mail]>
> Sent: Monday, June 8, 2020 8:23 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> Ivaylo Petrov <[e-mail]>; [e-mail]
> Subject: Roman Danyliw's No Objection on draft-ietf-cose-hash-algs-04: (with
> COMMENT)
> 
> 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.
> [JLS] Yes that makes sense, but I removed the trailing "is needed" because it
> does not read well.
> 
> ** 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.
> [JLS] ACK - I left it this way because it is a draft and not an RFC to make sure
> that it is highlighted for the RFC Editor.
> 
> -- Section 2.1. Editorial.  s/this could /This could/ [JLS] Already caught.
> 
> -- Section 3.1. Editorial. s/assign a point/assign a code point/ [JLS] Done.
> 
> -- 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.
> [JLS] This was already rewritten in response to comments from Barry.
> 
>               Use of this hash function needs analysis of the potential problems with
> having a collision occur, or must be limited to where the function of the hash is
> non-cryptographic.
> 
> -- 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.
> [JLS] It may not age well but it is why these are the ones in the document.
> Perhaps "currently being standardized in the IETF.  This is the reason for
> including these algorithms in this document."
> 
> -- Section 4.  Typo. s/preseved/preserved/ [JLS] Fixed
> 
>