[Unbearable] SECDIR early review of draft-ietf-tokbind-tls13-00

[Stephen Kent <[e-mail]>]

SECDIR *early* review of draft-ietf-tokbind-tls13-00

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 with the intent of improving security 
requirements and considerations in IETF drafts.Comments not addressed in 
last call may be included in AD reviews during the IESG review.Document 
editors and WG chairs should treat these comments just like any other 
last call comments.

This (very brief) document defines how to negotiate Token Binding for 
TLS v1.3. Existing IETF documents (IDs) define this protocol and how to 
negotiate it capability only for earlier versions of TLS.

The first question that comes to mind is why there is a need for a new 
ID, instead of adding text to draft-ietf-tokbind-negotiation-10. I 
realize that draft-ietf-tokbind-negotiation-10 is in last call, but the 
text here is so small that it seems overkill to create a separate RFC. 
I’m guessing that the argument is that this document references TLS 1.3, 
which is not yet an RFC, and thus the author is trying to avoid creating 
a down reference problem with draft-ietf-tokbind-negotiation-10. Right?

Section 2 notes that the format of the extension is the same as defined 
in draft-ietf-tokbind-negotiation-10, so nothing new there. The section 
cites two differences from the behavior in 
draft-ietf-tokbind-negotiation-10, which are described in just two 
sentences. Section 3 adds one paragraph to deal with 0-RTT, a TLS 1.3 
feature not present in earlier versions.Section 4 is non-normative, but, 
presumably useful. The security concerns are asserted to be the same as 
for draft-ietf-tokbind-negotiation-10, plus a sentence discussing why 
the 0-RTT exclusion avoids other potential security concerns.

So, if folks don’t want to delay publication of 
draft-ietf-tokbind-negotiation-10, I guess this is OK as a separate 
document, updating that RFC.