Re: [secdir] SECDIR early review of draft-ietf-tokbind-tls13-00

[Nick Harper <[e-mail]>]

On Thu, Mar 22, 2018 at 8:00 AM, Stephen Kent <[e-mail]> wrote:

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

That sounds right. My recollection of WG discussions on whether to add this
TLS 1.3 language to draft-ietf-tokbind-negotiation was that it was unclear
how the tokbind drafts would get sequenced with respect to
draft-ietf-tls-tls13 in IETF last call and the RFC Editor's queue, and
didn't want the tokbind drafts to get delayed waiting for
draft-ietf-tls-tls13 to get published.

>
>
> 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.
>