Re: draft-west-leave-secure-cookies-alone

[Mike West <[e-mail]>]

Thanks for noting this, Martin. I somehow didn't think to ping these
drafts to the list.

On Thu, Oct 22, 2015 at 12:05 AM, Martin Thomson
<[e-mail]> wrote:
> I realize that we haven't discussed this at all, but it seems like a
> no-brainer to me.  That is, if someone (Mike?) has a satisfactory
> answer to this question: do you know what level of breakage is this
> going to cause?  I have heard that this misfeature is relied upon by
> some non-trivial number of sites.

Chrome sees something like 0.01% of `Set-Cookie` operations fall into
the category that this draft suggests ignoring.

Mozilla has similar metrics hovering around 0.02%.

> For me, as long I can be satisfied that the breakage is extremely low,
> or that it will soon be, then that's sufficient.  However, a
> non-trivial amount of bustage will likely prevent us from deploying a
> change like this.

I think we can mitigate the impact by rolling this kind of change out
in a somewhat coordinated fashion, and announcing it beforehand. The
current cipher-suite deprecations seem like a reasonable model to
follow.

On Thu, Oct 22, 2015 at 7:44 AM, Willy Tarreau <[e-mail]> wrote:
> I think in fact that what we're missing is the ability for the
> browser to tell the server how it considers the cookie (secure or
> not). The servers could then decide to ignore non-secure cookies
> in this case and that would protect much better, including against
> cookie injection. That would require updating the cookie syntax and
> spec though since we can't pass attributes with cookies :-/

About that... https://tools.ietf.org/html/draft-west-origin-cookies-01
is one approach.
https://tools.ietf.org/html/draft-west-cookie-prefixes-04 is another
(and has the advantage of being trivial to implement). Chrome's
implemented the latter (at least the `$Secure-*` prefix) behind a flag
for folks to start playing with.

-mike