Last Call Review of draft-ietf-cose-hash-algs-06
review-ietf-cose-hash-algs-06-secdir-lc-weis-2020-07-06-00

Request Review of draft-ietf-cose-hash-algs
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-05-26
Requested 2020-05-12
Authors Jim Schaad
Draft last updated 2020-07-06
Completed reviews Secdir Last Call review of -06 by Brian Weis (diff)
Genart Last Call review of -03 by Gyan Mishra (diff)
Opsdir Last Call review of -03 by Jouni Korhonen (diff)
Assignment Reviewer Brian Weis 
State Completed
Review review-ietf-cose-hash-algs-06-secdir-lc-weis-2020-07-06
Posted at https://mailarchive.ietf.org/arch/msg/secdir/r7QYD_rpnKuQOEnQcPMVo7uMlp4
Reviewed rev. 06 (document currently at 09)
Review result Ready
Review completed: 2020-07-06

Review
review-ietf-cose-hash-algs-06-secdir-lc-weis-2020-07-06

This is a very tardy security considerations review; many apologies to the ADs and the author. After reviewing draft-ietf-cose-hash-algs-06 I have only two minor wording suggestions, which Jim can choose to implement or not.

(1) Referencing BCP 201 in the second paragraph of Section 2 was a good addition to this sentence:
   Applications should also make sure that the ability to change
   hash functions is part of the base design, as cryptographic advances
   are sure to reduce the strength of a hash function [BCP201].

But reading the BCP does point out that perhaps the current wording is not precise.  I have always considered “cryptographic advances” as the strengthening of algorithms or development of new stronger algorithms rather than increased success of attacks on algorithms. The BCP uses the wording "advances in computing power or advances in cryptoanalytic techniques” to describe this phenomenon. Maybe “cryptographic advances” could be replaced with that phrase from the BCP, or at least change “cryptographic” to “cryptanalytic”.

(2) Security Considerations describes two properties of a hash function. By the time the reader gets to this section they should well understand what is collision resistance. But  then second pre-image resistance is mentioned offhand without any explanation. Adding a parenthetical definition for second pre-image resistance would be helpful to the reader. For example, by adding “(i.e., where it is computationally infeasible to find any second input which has the same output as that of a specified input)” to the end of the sentence. (This text was lifted from the Wikipedia “Preimage attack” article.)