Subject: FYI: Chrome plans to ship an implementation of same-site cookies.

From: Mike West <[email-masked]>
Date: Fri, 25 Mar 2016 10:35:57 +0100

Hello, HTTP WG folks who are interested in cookies. :)

We've talked on and off about same-site cookies as a defense in depth
against CSRF and related attacks; I think they're solidly enough defined to
ship and let folks begin experimenting with. We plan on pushing them out
the door in Chrome ~51, and I hear that folks at Mozilla are planning on
beginning an implementation in Q2:

Spec: https://tools.ietf.org/html/draft-west-first-party-cookies

Intent to Ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/csCtW3M3-wg

There's a very slightly updated -07 that I'll upload once things open up
again, but it doesn't contain any normative changes. Feedback on the
existing text (or Chrome's implementation) would be much appreciated.

-mike

---

From: Phil Lello <[email-masked]>
Date: Fri, 25 Mar 2016 16:07:56 +0000

Can I ask that the draft change the "Intended Status" to "Informational" -
it seems to me that by being shipped in a full release rather than a beta,
it reflects a standard defined outside the IETF processes.

Best wishes,

Phil Lello

---

From: David Morris <[email-masked]>
Date: Fri, 25 Mar 2016 09:40:46 -0700 (PDT)

What working code is called isn't really relavent in terms of RFC status.
The point of a standard is to get all implementors to do it an
interoperable fashion. Standards can originate outside of a WG. And as far
as I can recall, this WG hasn't rejected this work.

On Fri, 25 Mar 2016, Phil Lello wrote:

> against CSRF and related attacks; I think they're solidly enough
> defined to ship and let folks begin experimenting with. We plan on
> pushing them out the door in Chrome ~51, and I hear that folks at
> Mozilla are planning on beginning an implementation in Q2:
>
> Intent toShip: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/csCt
> W3M3-wg
>
> There's a very slightly updated -07 that I'll upload once things open
> up again, but it doesn't contain any normative changes. Feedback on
> the existing text (or Chrome's implementation) would be much
> appreciated.
>
> -mike
>
>
>
>  
>
> ____________________________________________________________________________
>
> This email has been scanned for spam and viruses by Proofpoint Essentials
> cloud email security - click here to report this email as spam.
>
>
>
>

---

From: Phil Lello <[email-masked]>
Date: Fri, 25 Mar 2016 18:04:20 +0000

I'm clearly not disputing the point of a standard or objecting to the work,
however the status exists for a reason.

BCP9 describes Informational as:

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to verification
   that there has been adequate coordination with the standards process
   (see section 4.2.3 <https://tools.ietf.org/html/bcp9#section-4.2.3>).

   Specifications that have been prepared outside of the Internet
   community and are not incorporated into the Internet Standards
   Process by any of the provisions of section 10
<https://tools.ietf.org/html/bcp9#section-10> may be published as
   Informational RFCs, with the permission of the owner and the
   concurrence of the RFC Editor.

BCP9 describes Proposed Standard as:

   The entry-level maturity for the standards track is "Proposed
   Standard".  A specific action by the IESG is required to move a
   specification onto the standards track at the "Proposed Standard"
   level.

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

   A Proposed Standard should have no known technical omissions with
   respect to the requirements placed upon it.  However, the IESG may
   waive this requirement in order to allow a specification to advance
   to the Proposed Standard state when it is considered to be useful and
   necessary (and timely) even with known technical omissions.

   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended.

IMHO announcing the release into the wild while saying "I think they're
solidly enough defined to ship and let folks begin experimenting with. We
plan on pushing them out the door in Chrome ~51" implies Informational
Status, since it 'does not represent an Internet community consensus or
recommendation' and does not meet the Proposed Standard requirement of
'generally
stable, has resolved known design choices, is believed to be
well-understood, has received significant community review' if it's
released for experimentation - once it's shipped, it's a de facto standard.

Proposed Standard also states 'However, since the content of Proposed
Standards may be changed if problems are found or better solutions are
identified, deploying implementations of such standards into a
disruption-sensitive environment is not recommended.'

Best wishes,

Phil Lello

On Fri, Mar 25, 2016 at 4:40 PM, David Morris <[email-masked]> wrote:

> > Intent toShip:

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 25 Mar 2016 12:44:21 -0700

> On Mar 25, 2016, at 11:04 AM, Phil Lello <[email-masked]> wrote:
> IMHO announcing the release into the wild while saying "I think they're solidly enough defined to ship and let folks begin experimenting with. We plan on pushing them out the door in Chrome ~51" implies Informational Status, since it 'does not represent an Internet community consensus or recommendation' and does not meet the Proposed Standard requirement of 'generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review' if it's released for experimentation - once it's shipped, it's a de facto standard.

No, that isn't even remotely true.  HTTP itself had three years of deployment before
the IETF started working on the protocol definition. The standards track reflects where we
intend a given protocol to be in the future, not the status of ongoing implementations and
deployment of that protocol, and whether or not the protocol becomes a de facto standard
in the mean time is largely unrelated to the stability of its corresponding specification here.

Proposed Standard means the specification is still in flux, regardless of the protocol status.
We want both working code and rough consensus, not just one or the other, in order to
further validate and progress our specifications.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 26 Mar 2016 12:14:59 +1100

Let's not lawyer up on the meaning of the phrase "intended status" -- it's completely advisory and up to the draft submitters. If we actually adopt a document, that's when we need to be concerned about this.

Cheers,

> On 26 Mar 2016, at 5:04 AM, Phil Lello <[email-masked]> wrote:
> 
> I'm clearly not disputing the point of a standard or objecting to the work, however the status exists for a reason.
> 
>    (see 
> section 4.2.3
> ).
>  may be published as
> Proposed Standard also states 'However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended.'
> Best wishes,
> Phil Lello
> 
> 

--
Mark Nottingham   https://www.mnot.net/