-----Original Message----- From: Roman Danyliw via Datatracker <[email protected]> Sent: Monday, June 8, 2020 8:23 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Ivaylo Petrov <[email protected]>; [email protected] 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 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
