Reviewer: Matthew Miller Review result: Has Issues [ I realize how unfortunate it is this arrives well past last call. I beg forgiveness and ask that you accept the comments as you would have if they arrived on time. ] 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. Document: draft-ietf-stunbis-16 Reviewer: Matthew A. Miller Review Date: 2018-03-07 IETF LC End Date: 2018-02-20 IESG Telechat date: 2018-04-05 Summary: This document obsoletes 5389, adding some protection to downgrade attacks against message integrity usage, as well incorporating DTLS (over UDP). The document is mostly ready, but there are a couple of issues I have. Major Issues: N/A Minor Issues: * I am wondering why a more robust password algorithm (key derivation function) was not defined (e.g., HKDF-SHA-256) instead of or in addition to, a simple salted "SHA-256" hash. Some amount of parameterization is accounted for in the PASSWORD-ALGORITHM/S attributes. I think it is perfectly fair and appropriate to take this issue as "asking for a quick rationale (that maybe ought to be highlighted better in the document)" over "use a real key derivation function". * The description for 17.5.1. "MD5" list the key size as 20 bytes, but the hash length of MD5 is 16 bytes (128 bits). I think this is merely a typo, since the purpose appears to be for backwards compatibility with existing systems. * Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key" (long-term credential) and Section appear to define the same functional algorithm, but with subtle syntax differences. As far as I can tell, they are actually the same algorithm; would it not be acceptable to have Section 9.2.2 point to Section 17.5.1.1 for the algorithm description?
