Last Call Review of draft-ietf-lamps-pkix-shake-08
review-ietf-lamps-pkix-shake-08-secdir-lc-nir-2019-03-31-00

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.