Discussion:
[Uta] SECDIR early review of draft-ietf-tokbind-tls13-00
Stephen Kent
2018-03-22 15:00:55 UTC
Permalink
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.
Nick Harper
2018-04-02 20:25:51 UTC
Permalink
Post by Stephen Kent
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.
Post by Stephen Kent
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.
Loading...