[secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15

[David Mandelberg <[e-mail]>]

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 summary of the review is Ready with nits.

(nit) Section 2.3 describes MACs as "based on cryptographic hash 
functions using a secret key". If the intent is to limit this to MACs 
that use cryptographic hash functions, I'd suggest using the term HMAC 
instead of MAC. If not, I think there are other MAC algorithms that 
don't use hashes.

(nit) The description of Chunk Length in Section 3.2 seems a bit 
complicated. (Not a lot complicated, just a bit.) I'd expect at least 
occasional security issues from incorrect implementations in programming 
languages that don't enforce in-bounds memory access. I'm guessing it's 
either too late to simplify the field, or there are good reasons for it 
to be the way it is? Are there any lessons learned by existing 
implementations that would be worth mentioning to help future 
implementors avoid issues with out-of-bounds memory access here? ("No" 
is a fine answer if this turns out to not have been a problem.)

(nit) Section 5.1.5, bullet point 4 says 'If the elapsed time is longer 
than the lifespan carried in the State Cookie, then ... the endpoint 
MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the 
peer endpoint.' That's different from the behavior if the MAC fails in 
bullet point 2. Does that mean that endpoints are REQUIRED to keep track 
of every secret they've ever used, so that they can distinguish between 
failed MACs and expired cookies for very old cookies? Should that be 
relaxed a bit to let implementations only store moderately recent secrets?

(nit) Section 12.2.3 says "Regardless of where confidentiality is 
provided, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] 
SHOULD be used for key management." That makes sense for ESP, but is it 
intended to apply to DTLS too? (DTLS is mentioned earlier in the same 
section.)

P.S. This was a very long document, so I ended up just skimming a bunch 
of the parts that I guessed were less likely to be relevant to security. 
Let me know if there are any particular sections I should take a closer 
look at.