[ 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?