Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation
RFC 8472

Note: This ballot was opened for revision 10 and is now closed.

(Ben Campbell) Yes

Comment (2018-05-09 for -12)
No email
send info
Thanks for this document. I am balloting "yes", but have a few comments:

- I support Alexey's DISCUSS. Additionally, do I understand the version negotiation to require the client to support all previous version from the one it initially advertises? If so, how would you deprecate a version at some time in the future?

- I shared some of the confusion about this being limited to TLS 1.2 and earlier. In particular, there is repeating language that to the effect of "For TLS 1.2 and earlier...", which seems strange for a draft that only supports 1.2 in the first place.

§1.1: Please consider using the 8174 boilerplate across the cluster. While I did not find lower case keywords in this draft, I did in the other two and it would be best to be consistent across all three.

§2: "[I-D.ietf-tokbind-protocol] describes version {1, 0} of the protocol.": While one might infer that version to be {1,0} give the name "Token Binding 1.0", I never saw it explicitly mentioned.

Editorial Comments:

§2: "Please note that the server MAY select any lower protocol version, see Section 3": comma splice

Benjamin Kaduk Yes

Comment (2018-05-10 for -13)
No email
send info
I agree with Adam and Warren's comments.

The point already made about version negotiation has a corollary
that if the client sends a dense list of versions, then the server
will know decisively that a specific version has (or has not) been
negotiated, and can rely on that at the application layer.  When the
client can receive an unsupported version back from the server, the
client will not use token binding and the server has to infer from
the client's application-layer traffic whether token binding is
expected to be in use.  (Whether or not this is a desired or useful
property to have is not necessarily clear.)

Section 4

   the client advertises, then the server MUST NOT include
   "token_binding" extension in the server hello.

Nit: """the "token_binding" extension"""

Section 6.1

   The Token Binding protocol version and key parameters are negotiated
   via "token_binding" extension within the TLS handshake. [...]

Nit: """the "token_binding" extension".  (Also at the end of this

   [...] TLS prevents
   active attackers from modifying the messages of the TLS handshake,
   therefore it is not possible for the attacker to remove or modify the
   "token_binding" extension.

I wonder if we want to explicitly say *successful* TLS handshakes,
but given the context in the main protocol document it's probably
not necessary.

(Eric Rescorla) Yes

(Adam Roach) Yes

Comment (2018-05-08 for -12)
No email
send info
Addendum: the ARTART review raises a point that I believe should be fixed or clarified in the document:

Original Comments:

I would really like to see a non-normative mention of draft-ietf-tokbind-tls13
in here, to let readers know that a TLS 1.3 solution is in progress rather than
merely being excluded from scope.

I also think the Abstract is incomplete without mentioning the limitation of
this document's mechanism to TLS 1.2 and lower.

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2018-05-09 for -12)
No email
send info
Please also see Will LIU's OpsDir review here:
It suggests a simple change which will remove confusion/ambiguity.

The document says (in the Introduction):
"The negotiation of the Token Binding protocol and key parameters in combination with TLS 1.3 and later versions is beyond the scope of this document."

How hard would it be to make it work with TLS 1.3? Actually, what part of it doesn't already? (I'm guessing I'm missing something super-obvious)...

(Mirja Kühlewind) No Objection

Comment (2018-04-26 for -11)
No email
send info
One quick question: Why does this spec not cover TLS1.3?

(Terry Manderson) No Objection

(Alexey Melnikov) (was Discuss) No Objection

Comment (2018-05-10 for -13)
No email
send info
   struct {
       uint8 major;
       uint8 minor;
   } TB_ProtocolVersion;

I think naming them "major" and "minor" is misleading, because it doesn't actually mean anything.

Lack of description of how versionning is to be used makes me sad, but I understand that this was discussed in the WG.

Alvaro Retana No Objection

Martin Vigoureux No Objection