Last Call Review of draft-ietf-tram-stunbis-16

Request Review of draft-ietf-tram-stunbis
Requested rev. no specific revision (document currently at 21)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-02-20
Requested 2018-02-06
Authors Marc Petit-Huguenin, Gonzalo Salgueiro, Jonathan Rosenberg, Dan Wing, Rohan Mahy, Philip Matthews
Draft last updated 2018-03-09
Completed reviews Genart Last Call review of -15 by Dale Worley (diff)
Secdir Last Call review of -16 by Matthew Miller (diff)
Genart Telechat review of -16 by Dale Worley (diff)
Artart Telechat review of -16 by Peter Saint-Andre (diff)
Assignment Reviewer Matthew Miller 
State Completed
Review review-ietf-tram-stunbis-16-secdir-lc-miller-2018-03-09
Reviewed rev. 16 (document currently at 21)
Review result Has Issues
Review completed: 2018-03-09


[ 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

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

* Both "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 for the algorithm description?