Thanks for the review Yoav. I made changes in the Sec Considerations to address your comments. The changes are described here https://github.com/csosto-pk/adding-shake-to-pkix/issues/42 I will reupload the draft at the end of this week probably unless there are more comments while in IESG review. Panos -----Original Message----- From: Spasm <spasm-bounces@xxxxxxxx> On Behalf Of Yoav Nir via Datatracker Sent: Sunday, March 31, 2019 4:02 PM To: secdir@xxxxxxxx Cc: spasm@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-lamps-pkix-shake.all@xxxxxxxx Subject: [lamps] Secdir last call review of draft-ietf-lamps-pkix-shake-08 Reviewer: Yoav Nir Review result: Has Issues 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. _______________________________________________ Spasm mailing list Spasm@xxxxxxxx https://www.ietf.org/mailman/listinfo/spasm
