Re: Secdir telechat review of draft-ietf-httpbis-rfc6265bis-19

[Steven Bingler <[e-mail]>]

Hello Valery and Secdir,

Thank you for the review and my apologies for the late reply. I had to
take a hiatus.

Find my responses to your issues below. The changes I've made have not
yet been published as a draft but are available to view on the github
repo. https://github.com/httpwg/http-extensions/blob/main/draft-ietf-httpbis-rfc6265bis.md

> 1. Please, make it more clear that the restrictions on the cookie use, that the
> server imposes via attributes, are not guaranteed to be honored even by a
> honest user agent. For example, if the clocks on the server and on the client
> are out of sync, then the user agent may innocently try to use cookie beyond
> its lifetime. Thus, the imposed restrictions for the received cookies MUST be
> checked by the server.

I've expanded "The Expire Attribute"'s text to warn of this behavior.
Assuming I'm understanding your comment correctly I don't believe any
other attributes can similarly "ignore" their restrictions so long as
the UA is honest.

> 2. Section 8.1 states that "by default, cookies do not provide confidentiality
> or integrity from network attackers, even when used in conjunction with HTTPS"....

I tweaked the text a bit to acknowledge that HTTPS does offer benefits.

> 3. Section 8.3 lists security risks when cookies are sent in clear and clause 3
> states: "A malicious client could alter the Cookie header before transmission,
> with unpredictable results". I failed to understand how this is concerned with
> the use of TLS. In my understanding, malicious clients can do this in any case,
> regardless on whether TLS is used or not. Am I missing something?

Agreed that the third point is unclear. I've removed it.

> 4. Section 7.1, last para states that "it is RECOMMENDED that user agents adopt
> a policy for third-party cookies that is as restrictive as compatibility
> constraints permit". This gives no concrete recommendations, and no examples,
> thus making this requirement vague and subjective. I think this requirement
> should be provided with more details how to deal with it.

This is difficult to do given the range of compatibility constraints
among user agents. Some agents could strive for maximum compatibility
while others for maximum user privacy. The third-party cookie policies
will differ greatly between those two types of UAs.

Upcoming cookie changes, such as CHIPS, would make this reasonable
feedback for https://www.ietf.org/archive/id/draft-ietf-httpbis-layered-cookies-00.html#name-third-party-cookies

> Just out of curiosity - the draft adds a requirement that cookie SHOULD NOT be
> greater than 400 days. I wonder why this particular margin was chosen. Why not
> 365 days (a year) - it looks like a natural equivalet to "very long, but not
> infinite"?

400 days was chosen to allow for cookies that exist for yearly events
(Tax return services for example) with some added padding in case the
user visited a little later. Plus to get a nice round number.

- Steven