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

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tokbind-protocol-18: 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-protocol/



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

Section 2

   When a server supporting the Token Binding protocol receives a bound
   token, the server compares the Token Binding ID in the token with the
   Token Binding ID established with the client.  If the bound token
   came from a TLS connection without a Token Binding, or if the Token
   Binding IDs do not match, the token is rejected.

"came from" is perhaps a bit ambiguous; I'd suggest "is received on"
instead.


Section 3.3

The need for synchronization between application+token-binding and
the TLS stack (around renegotiation) is real, but is also potentially
really hard.  Can we get some guidance on how to not screw it up?


Section 3.4

   An implementation MUST ignore any unknown Token Binding types.

This is the section on extensions; do we mean to say that unknown
extension types are to be ignored?  (If we do, it would seem to
duplicate a line in Section 4.2.)


Section 4.1

   The client MUST include at least one TokenBinding structure in the
   Token Binding message.  The key parameters used in the
   provided_token_binding MUST match those negotiated with the server
   (e.g., via [I-D.ietf-tokbind-negotiation] or a different mechanism).

This seems to imply but not specifically state that the mandatory
TokenBinding is of type provided_token_binding.  Changing "the" to
"this" in the second line would subtly sneak this in, but it's
probably better to also explicitly say "of type
provided_token_binding" in the first sentence.


Section 4.2

I would suggest adding a pargaraph break between the sentences in

   If the use of the Token Binding protocol was not negotiated, but the
   client sends the Token Binding message, the server MUST reject any
   contained bindings.  If the Token Binding type is
   "provided_token_binding", the server MUST verify that the signature
   algorithm (including elliptic curve in the case of ECDSA) and key
   length in the Token Binding message match those negotiated with this
   client (e.g., via [I-D.ietf-tokbind-negotiation] or a different
   mechanism).


   If a Token Binding is rejected, any associated bound tokens MUST also
   be rejected by the server. [...]

Is "associated" scoped to "presented on the current TLS connection"
or a more global property?  (I understand that the association could
be either via direct embedding of ID in token or via an external
database mapping.)


Section 6.1

This policy sounds more like "Specification Required" than "Expert
Review" (the former still includes expert review).