[Unbearable] Benjamin Kaduk's No Objection on draft-ietf-tokbind-https-15: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tokbind-https-15: No Objection

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-https/



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

I agree with Alexey about clarifying that backslashes are only for readability.

I'm curious why Section 2 limits to at most one referred_token_binding.


Section 2

   A TokenBindingMessage is validated by the server as described in
   Section 4.2.  ("Server Processing Rules") of
   [I-D.ietf-tokbind-protocol].

Nit: no period after "4.2".

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

I repeat my remark about "associated" from tokbind-protocol.


Section 2.1

It seems a little unusual to see "Applications other than Web
browsers MAY [...]", though I do not object.


Section 3

To be clear, this means that the EKM used is the one from before
the renegotiation, corresponding in the somewhat-common use case of
renegotiation for optional client authentication to the
unauthenticated-client state, right?


Section 5.3

   As illustrated in Section 5.5, when a client receives this header
   field, it should take the TokenBindingID of the provided TokenBinding
   from the referrer and create a referred TokenBinding with it to
   include in the TokenBindingMessage on the redirect request.  In other
   words, the Token Binding message in the redirect request to the Token
   Provider now includes one provided binding and one referred binding,
   the latter constructed from the binding between the client and the
   Token Consumer.

I'm not really an HTTP expert, but is "redirect request" the right
term (as opposed to, say, "redirected request" or "post-redirect
request")?

   The TokenBindingMessage SHOULD contain a TokenBinding with
   TokenBindingType referred_token_binding.

At this point we may have lost track of what "The
TokenBindingMessage" refers to -- some explicit scope (the message
sent to the Token Provider after following the redirect) could be
helpful.


Section 7.1

   The goal of the Federated Token Binding mechanisms is to prevent
   attackers from exporting and replaying tokens used in protocols
   between the client and Token Consumer, [...]

Do we actually need to limit the scope to Token Consumer?  The Token
Provider may also issue tokens that we want to protect, after all.


Section 7.2

Do we need to repeat the normative statements already made in
[TBPROTO]?  Maybe we can just say that [TBPROTO] requires these
things to be used, to protect against [TRIPLE-HS].