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

Alissa, does the latest draft address your DISCUSS?

On Wed, May 9, 2018 at 10:54 AM, Alissa Cooper <alissa@cooperw.in> wrote:

> 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.
>
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>