[Unbearable] Alissa Cooper's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-tokbind-https-14: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 2.1 says:

"The scoping of Token Binding key pairs generated by Web browsers for
   use in first-party and federation use cases defined in this
   specification (Section 5), and intended for binding HTTP cookies,
   MUST be no wider than the granularity of "effective top-level domain
   (public suffix) + 1" (eTLD+1).  I.e., the scope of Token Binding key
   pairs is no wider than the scope at which cookies can be set (see
   [RFC6265]), but MAY be more narrow if cookies are scoped more
   narrowly."

My reading of RFC 6265 is that it does not actually forbid cookie setting at a
scope wider than eTLD+1, although I could be reading Section 5.3 of that
document wrong. That section says that if the user agent is configured to
reject public suffixes, then there is a case where a set-cookie request should
be ignored. If the intent here is to normatively restrict the scope of Token
Binding key pairs to eTLD+1 regardless of whether the user agent restricts
cookies to that scope, that needs to be stated clearly.

I kind of hate to say this but with the way this is phrased I also think you
need a normative reference for the concept of "effective top-level domain." (I
suspect this would be considered a downref and may not already be in the
downref registry, but I'm not one to make a fuss about that.)


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

I would also suggest s/but/and/ in the last sentence quoted from 2.1 above.