[Unbearable] Alexey Melnikov's No Objection on draft-ietf-tokbind-https-14: (with COMMENT)

[Alexey Melnikov <[e-mail]>]

Alexey Melnikov has entered the following ballot position for
draft-ietf-tokbind-https-14: 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 have mostly nits and questions for this document, but see further down, there
might be some minor bugs.

In Section 2:

2.  The Sec-Token-Binding HTTP Request Header Field

     Sec-Token-Binding = EncodedTokenBindingMessage

   The header field name is Sec-Token-Binding and its single value,
   EncodedTokenBindingMessage, is a base64url encoding of a single
   TokenBindingMessage, as defined in [I-D.ietf-tokbind-protocol], using
   the URL- and filename-safe character set described in Section 5 of
   [RFC4648], with all trailing padding characters '=' omitted and
   without the inclusion of any line breaks, whitespace, or other
   additional characters.

   For example:

  Sec-Token-Binding: AIkAAgBBQFzK4_bhAqLDwRQxqJWte33d7hZ0hZWHwk-miKPg4E\
                     9fcgs7gBPoz-9RfuDfN9WCw6keHEw1ZPQMGs9CxpuHm-YAQM_j\
                     aOwwej6a-cQBGU7CJpUHOvXG4VvjNq8jDsvta9Y8_bPEPj25Gg\
                     mKiPjhJEtZA6mJ_9SNifLvVBTi7fR9wSAAAA

I think you should explain here that \ at the end of each line denotes line
continuation and that it is not actually a part of the value.

Later in the same section:

   The TokenBindingMessage MAY also contain exactly one TokenBinding
   structure with TokenBindingType of referred_token_binding, as
   specified in Section 5.3.  In addition to the latter, or rather than
   the latter, the TokenBindingMessage MAY contain other TokenBinding
   structures.

This sentence made me wonder whether it is Ok for a compliant implementation to
only process the first 2 TokenBinding structures and ignore the rest?

   This is use case-specific, and such use cases are
   outside the scope of this specification.

At the top of page 11 (Section 5.3):

   This header field has only meaning if the HTTP status code is 301,
   302, 303, 307 or 308, and MUST be ignored by the client for any other
   status codes.

I just want to point out to other reviewers that this list is non extensible
and will not work with any future 3XX status codes (however unlikely they are).
I am still trying to decide how I feel about that ;-).

In 7.3, next to the last paragraph:

   If A has a pre-existing relationship with S (perhaps has an account
   on S), it now appears to the server S as if A is connecting to it,
   even though it is really C.  (If the server S does not simply use
   Token Binding IDs to identify clients, but also uses bound
   authentication cookies, then A would also have to trick C into
   sending one of A's cookies to S, which it can do through a variety of

C's cookies?

   means - inserting cookies through Javascript APIs, setting cookies
   through related-domain attacks, etc.)  In other words, A tricked C
   into logging into A's account on S.  This could lead to a loss of

Not sure whether A is correct here either.

   privacy for C, since A presumably has some other way to also access
   the account, and can thus indirectly observe A's behavior (for

"C's behaviour"? A can always know A's behaviour.

   example, if S has a feature that lets account holders see their
   activity history on S).

11.1.  Normative References

   [fetch-spec]
              WhatWG, "Fetch", Living Standard ,
              <https://fetch.spec.whatwg.org/>.

I am looking forward to having a discussion within IESG to having a normative
reference to a non stable document ;-). However, in this case I am not
convinced that the reference needs to be normative, as it is only used to
explain why "Sec-" header field prefix was used.