Skip to main content

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 revision 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
I-D 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
Request Last Call review on draft-ietf-cose-hash-algs by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/r7QYD_rpnKuQOEnQcPMVo7uMlp4
Reviewed revision 06 (document currently at 09)
Result Ready
Completed 2020-07-06
review-ietf-cose-hash-algs-06-secdir-lc-weis-2020-07-06-00
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.)