draft-west-leave-secure-cookies-alone

[stash-sfdc]

https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone-01

Section 8.5 and Section 8.6 of [RFC6265] spell out some of the
drawbacks of cookies' implementation: due to historical accident,
non-secure origins can set cookies which will be delivered to secure
origins in a manner indistinguishable from cookies set by that origin
itself. This enables a number of attacks, which have been recently
spelled out in some detail in [COOKIE-INTEGRITY].

We can mitigate the risk of these attacks by making it more difficult
for non-secure origins to influence the state of secure origins.
Accordingly, this document recommends the deprecation and removal of
non-secure origins' ability to write cookies with a 'secure' flag,
and their ability to overwrite cookies whose 'secure' flag is set.

Probably want to implement this as a secure default (jar configuration, possibly?)

[stash-sfdc]

See also: https://www.chromestatus.com/features/4506322921848832 - Chrome and Firefox are probably implementing this

[stash]

Chrome (and thus Opera) and Firefox have shipped this.

[stash]

https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone-01#section-3 is a good summary, but defer to https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-5.4 for the new processing model:

This document updates Section 5.3 of [RFC6265] as follows:

1. After step 8 of the current algorithm, which sets the cookie's
   "secure-only-flag", execute the following step:

   1. If the "scheme" component of the "request-uri" does not
      denote a "secure" protocol (as defined by the user agent),
      and the cookie's "secure-only-flag" is "true", then abort
      these steps and ignore the newly created cookie entirely.

2. Before step 3 of step 11 of the current algorithm, execute the
   following step:

   1. If the "scheme" component of the "request-uri" does not
      denote a "secure" protocol (as defined by the user agent),
      and the "old-cookie"'s "secure-only-flag" is set, then abort
      these steps and ignore the newly create cookie entirely.

The implementation change should default to "on", which potentially means a semver major update. Maybe unsafeModificationsToSecureCookies: 'allow' is the flag to disable it?