Last Call Review of draft-ietf-lamps-pkix-shake-08

Request Review of draft-ietf-lamps-pkix-shake
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-04-10
Requested 2019-03-27
Authors Panos Kampanakis, Quynh Dang
Draft last updated 2019-03-31
Completed reviews Secdir Last Call review of -08 by Yoav Nir (diff)
Genart Last Call review of -08 by Joel Halpern (diff)
Opsdir Last Call review of -08 by Tianran Zhou (diff)
Genart Telechat review of -11 by Joel Halpern (diff)
Assignment Reviewer Yoav Nir
State Completed
Review review-ietf-lamps-pkix-shake-08-secdir-lc-nir-2019-03-31
Reviewed rev. 08 (document currently at 15)
Review result Has Issues
Review completed: 2019-03-31


I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

The document is almost ready. The intent is clear and the IANA instructions are good.

I have two issues with the Security Considerations section.  That section has two paragraphs, and I'll start with the second one.

The second paragraph has a SHOULD-level requirement to choose an ECDSA curve with an appropriate strength to match that of the hash function (SHAKE128 vs SHAKE256). This seems to me like a compliance requirement. While this is not a hard-and-fast rule, these should usually go in the body of the document, such as in section 5 rather than in security considerations.  It's also puzzling why there are no similar recommendations for the strength of the RSA key.

The first paragraph I find confusing.  It states that the SHAKE functions are deterministic, and goes on to explain that this means that executing them on the same input will result in the same output, and that users should not expect this to be the case. Why does this need to be said? Is this not the same for any hash function? The paragraph than goes on to tell the reader that  with different output lengths, the shorter ones are prefixes of the longer ones, and that this is like hash function truncation.  Why do we need any of this information and why is this related to security?  This is especially puzzling considering that the document fixes the output length to a specific value for each of the two functions.