[Unbearable] Benjamin Kaduk's Yes on draft-ietf-tokbind-negotiation-13: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tokbind-negotiation-13: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

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