- From: <jeff.hodges@kingsmountain.com>
- Date: Fri, 17 Jun 2016 16:21:08 -0600
- To: "Mike West" <mkwst@google.com>, "Mark Goodwin" <mgoodwin@mozilla.com>
- Cc: "IETF HTTP WG" <ietf-http-wg@w3.org>
Below are some comments/questions on draft-west-first-party-cookies-07. This
spec is fairly complex, especially given how it is intertwined with [FETCH]
and [HTML] and I'm only modestly familiar with the latter specs, so there may
be some silliness in the below.
HTH,
=JeffH
ps: fixed-pitch font may be helpful
Overall comments:
* In the below comments "6265bis" refers to the postulated
draft-ietf-httpbis-rfc6265bis.
* the term registrable domain should be registered domain throughout (details
below)
* RFC6265 does not wrap its algorithm variables in double quotes (as this
draft is doing), and also hyphenates multi-word variable names (even ones that
aren't ABNF rule names). Are you suggesting that 6265bis ought to adopt the
style used in this draft (where alg varbs are quoted), or will the below
proposed updates to 6265bis adopt RFC6265's present style?
I advocate for the latter -- e.g., I suggest: s/"site for
cookies"/site-for-cookies/g
* RFC6265 uses the terms host, server, domain in its algorithms, whereas this
spec introduces the terms site, same site, top-level site, "site for cookies".
This may cause impedance mismatches when attempting to merge this draft into
6265bis. Perhaps just something to be aware of and address at that time.
* when comparing host names, or portions thereof, they ought to first be
canonicalized per RFC6265 S 5.1.2, yes?
detailed comments:
> HTTPbis M. West
> Internet-Draft Google, Inc
> Updates: 6265 (if approved) M. Goodwin
> Intended status: Standards Track Mozilla
> Expires: October 8, 2016 April 6, 2016
>
>
> Same-site Cookies
> draft-west-first-party-cookies-07
>
> Abstract
>
> This document updates RFC6265 by defining a "SameSite" attribute
> which allows servers to assert that a cookie ought not to be sent
> along with cross-site requests. This assertion allows user agents to
> mitigate the risk of cross-origin information leakage, and provides
> some protection against cross-site request forgery attacks.
>
<snip>
>
> 1. Introduction
>
> Section 8.2 of [RFC6265] eloquently notes that cookies are a form of
s/are a/may be employed as/
> ambient authority, attached by default to requests the user agent
> sends on a user's behalf. Even when an attacker doesn't know the
> contents of a user's cookies, she can still execute commands on the
> user's behalf (and with the user's authority) by asking the user
> agent to send HTTP requests to unwary servers.
I'd append to the end of latter sentence..
which will include any previously-set cookies.
> Here, we update [RFC6265] with a simple mitigation strategy that
> allows servers to declare certain cookies as "same-site", meaning
> they should not be attached to "cross-site" requests (as defined in
> section 2.1).
s/2.1)/2.1 of this specification)/
it isn't immediately clear whether the above is referring to section 2.1 of
this spec or RFC6265.
> Note that the mechanism outlined here is backwards compatible with
> the existing cookie syntax. Servers may serve these cookies to all
> user agents; those that do not support the "SameSite" attribute will
RFC6265 does not quote attribute names in prose, it would be written as
SameSite attribute. this style is used in the below comments.
> simply store a cookie which is attached to all relevant requests,
> just as they do today.
suggested mod to latter sentence:
simply store a cookie, which is subsequently attached to all relevant
requests (as defined by [RFC6265]), just as they do today.
> 1.1. Goals
might these be items that should be added into 6265bis' various
"considerations" sections (as appropriate)?
>
> These cookies are intended to provide a solid layer of defense-in-
s/these/Same-site/
> depth against attacks which require embedding an authenticated
> request into an attacker-controlled context:
>
> 1. Timing attacks which yield cross-origin information leakage (such
> as those detailed in [pixel-perfect]) can be substantially
> mitigated by setting the "SameSite" attribute on authentication
> cookies. The attacker will only be able to embed unauthenticated
> resources, as embedding mechanisms such as "<iframe>" will yield
> cross-site requests.
>
> 2. Cross-site script inclusion (XSSI) attacks are likewise mitigated
> by setting the "SameSite" attribute on authentication cookies.
> The attacker will not be able to include authenticated resources
> via "<script>" or "<link>", as these embedding mechanisms will
> likewise yield cross-site requests.
do you actually mean `<script src="..." />` rather than `<script>...</script>`
here?
>
> 3. Cross-site request forgery (CSRF) attacks which rely on top-level
> navigation (HTML "<form>" POSTs, for instance) can also be
> mitigated by treating these navigational requests as "cross-
> site".
>
> 4. Same-site cookies have some marginal value for policy or
> regulatory purposes, as cookies which are not delivered with
> cross-site requests cannot be directly used for tracking
> purposes. It may be valuable for an origin to assert that its
> cookies should not be sent along with cross-site requests in
> order to limit its exposure to non-technical risk.
>
> 1.2. Examples
>
> Same-site cookies are set via the "SameSite" attribute in the "Set-
s/set/declared/ ?
> Cookie" header field. That is, given a server's response to a user
> agent which contains the following header field:
>
> Set-Cookie: SID=31d4d96e407aad42; SameSite=Strict
>
> Subsequent requests from that user agent can be expected to contain
> the following header field if and only if both the requested resource
> and the resource in the top-level browsing context match the cookie.
missing the example header field that ostensibly should appear here?
> 2. Terminology and notation
is the intention that the terminology in this immediate section would be added
to 6265bis' section 2.3 "Terminology" ?
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in [RFC2119].
>
> This specification uses the Augmented Backus-Naur Form (ABNF)
> notation of [RFC5234].
>
> Two sequences of octets are said to case-insensitively match each
> other if and only if they are equivalent under the "i;ascii-casemap"
> collation defined in [RFC4790].
>
> The terms "active document", "ancestor browsing context", "browsing
> context", "document", "WorkerGlobalScope", "sandboxed origin browsing
> context flag", "parent browsing context", "the worker's Documents",
> "nested browsing context", and "top-level browsing context" are
> defined in [HTML].
add to the above list:
Document, shared worker, dedicated worker
> "Service Workers" are defined in the Service Workers specification
> [SERVICE-WORKERS].
>
> The term "origin", the mechanism of deriving an origin from a URI,
> and the "the same" matching algorithm for origins are defined in
> [RFC6454].
>
> "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as
> defined in Section 4.2.1 of [RFC7231].
>
> The term "public suffix" is defined in a note in Section 5.3 of
> [RFC6265] as "a domain that is controlled by a public registry". For
> example, "example.com"'s public suffix is "com". User agents SHOULD
> use an up-to-date public suffix list, such as the one maintained by
> Mozilla at [PSL].
I would add -- "Public suffixes" are also known as "effective top-level
domains (eTLDs). -- since that latter term is also used in many places in the
wild.
> An origin's "registrable domain" is the origin's host's public suffix
> plus the label to its left. That is, "https://www.example.com"'s
> registrable domain is "example.com". This concept is defined more
> rigorously in [PSL].
I suggest: s/registrable domain/registered domain/g
I've inquired with <team@publicsuffix.org> regarding the "registrable domain"
and "registered domain" terms and it seems that this spec should be using
"registered domain".
see also..
https://github.com/publicsuffix/list/issues/236
https://github.com/publicsuffix/publicsuffix.org/pull/2
suggested rewrite of above parag..
An origin's "registered domain" is the origin's host's public suffix
plus the domain name label to its left. That is, for
"https://www.example.com", the public suffix is "com" and the
registered domain is "example.com". This concept is defined more
rigorously in [PSL], and is also known as "effective top-level
domain plus one (eTLD+1)".
[ aside fwiw: I don't think the algorithm or terminology used on
<https://publicsuffix.org/list/> is terribly rigorous and it could use some
improvement ]
> The term "request", as well as a request's "client", "current url",
> "method", and "target browsing context", are defined in [FETCH].
suggest adding request's "initiator" to the list above since it is used in
opening parag of next section
=-=-=-=
Are the below definitions & algorithms in S 2.1 et al slated to be inserted
into 6265bis, e.g., in 6265bis S 5 "User Agent Requirements"?
Also, before diving into same-/cross-site, document-based, worker-based
requests and all, I suggest adding a section here defining the overall concept
of site-for-cookies...
2.1 The Site-for-Cookies Concept
A request is the input to the HTML Fetch algorithm [FETCH].
Initiators of requests have an associated origin, which may
contain a host name. If so, then the host name contains a
registered domain, which is the top-most domain on which
the initiator server-side may set its cookies. Thus this
registered domain is the initiator's site-for-cookies,
which is used in determining whether a request is same-site
or not.
> 2.1. "Same-site" and "cross-site" Requests
>
> A request is "same-site" if its target's URI's origin's registrable
> domain is an exact match for the request's initiator's "site for
> cookies", and "cross-site" otherwise. To be more precise, for a
> given request ("request"), the following algorithm returns "same-
> site" or "cross-site":
>
> 1. If "request"'s client is "null", return "same-site".
>
> 2. Let "site" be "request"'s client's "site for cookies" (as defined
> in the following sections).
>
> 3. Let "target" be the registrable domain of "request"'s current
> url.
>
> 4. If "site" is an exact match for "target", return "same-site".
>
> 5. Return "cross-site".
ISTM there's various issues with the above, below is a suggested overall
revision.
also, I wonder whether it is a good idea to have this particular definition to
be characterized as an algorithm if they are not themselves actually
incorporated within the normative 6265bis cookie-processing algorithms. Thus
the below is not characterized as an algorithm...
2.1. Same-site and Cross-site Requests Definition
Broadly speaking, a request is defined to be a same-site request
if its target browsing context's URL's origin's registered domain
matches the request's initiator's site-for-cookies, as determined
using the below rules and the algorithms given in the following
sections. Otherwise, it is a cross-site request.
Thus, for a given request:
1. If the request's client is `"null"` [FETCH], then the
request is a same-site request.
2. Otherwise, let site be the request's client's site-for
cookies, as determined using the algorithms below, and
let target be the registered domain of the request's
current target browsing context's URL [HTML].
3. Canonicalize target per [RFC6265] S 5.1.2. Site-for-cookies
is already canonicalized at this point.
4. If site and target are identical strings, then the request
is a same-site request.
5. Otherwise, request is a cross-site request.
perhaps also could use here a lead-in step to the below two sections..
A request may be initiated by a Document or by Workers of various
types. If a request's initiator is a Document, see Section 2.1.1,
or if a request's initiator is a Worker, see Section 2.1.2.
> 2.1.1. Document-based requests
the term "document-based request" is essentially undefined here, and does not
appear in [HTML] nor [FETCH] nor [DOM]. they also do not define
document-initiated, but that can be worked around ISTM
given terminology in [FETCH] and [HTML], perhaps re-title this section as..
Determining the Site-for-Cookies of Document-initiated Requests
> The URI displayed in a user agent's address bar is the only security
^^^
URL -- to reduce friction with [HTML],[FETCH],[DOM]
> context directly exposed to users, and therefore the only signal
> users can reasonably rely upon to determine whether or not they trust
> a particular website. The registrable domain of that URI's origin
> represents the context in which a user most likely believes
> themselves to be interacting. We'll label this domain the "top-level
> site".
suggested mods to latter two sentences..
The registered domain of the displayed URL's
origin represents the context in which a user most likely believes
themselves to be interacting. We define this domain to be the
top-level site.
> For a document displayed in a top-level browsing context, we can stop
> here: the document's "site for cookies" is the top-level site.
suggest..
For a document displayed in a top-level browsing context,
we stop here: the document's site-for-cookies is the top-level site.
> For documents which are displayed in nested browsing contexts, we
^
Otherwise,
> need to audit the origins of each of a document's ancestor browsing
> contexts' active documents in order to account for the "multiple-
> nested scenarios" described in Section 4 of [RFC7034]. These
> document's "site for cookies" is the top-level site if and only if
> the document and each of its ancestor documents' origins have the
> same registrable domain as the top-level site. Otherwise its "site
> for cookies" is the empty string.
suggest adding at end of above parag..
The following algorithm is used to make this determination:
> Given a Document ("document") , the following algorithm returns
^
in a nested browsing context
> its "site for cookies" (either a registrable domain, or the empty
> string):
>
> 1. Let "top-document" be the active document in "document"'s
> browsing context's top-level browsing context.
>
> 2. Let "top-origin" be the origin of "top-document"'s URI if "top-
> document"'s sandboxed origin browsing context flag is set,
> and "top-document"'s origin otherwise.
>
> 3. Let "documents" be a list containing "document" and each of
> "document"'s ancestor browsing contexts' active documents.
>
> 4. For each "item" in "documents":
>
> 1. Let "origin" be the origin of "item"'s URI if "item"'s
> sandboxed origin browsing context flag is set, and "item"'s
> origin otherwise.
>
> 2. If "origin"'s host's registrable domain is not an exact match
> for "top-origin"'s host's registrable domain,
do we not need to canonicalize (or ensure they are already canonicalized) both
registered domains per [RFC6265] S 5.1.2 before comparing them?
> return the
> empty string.
suggest last phrase be..
.., set site-for-cookies to the empty string, return site-for-
cookies, and abort these steps.
..?
>
> 5. Return "top-site".
top-site is otherwise undefined, perhaps what is meant here is to return
top-origin ?
perhaps step 5 should be..
Set site-for-cookies to top-origin and return site-for-cookies.
..?
>
> 2.1.2. Worker-based requests
Determining the Site-for-Cookies of Worker-initiated Requests
>
> Worker-driven requests aren't as clear-cut as document-driven
> requests,
terminology is squirrelly here, suggest consistently using worker-initiated
and document-initiated
> as there isn't a clear link between a top-level browsing
> context and a worker. This is especially true for Service Workers
> [SERVICE-WORKERS], which may execute code in the background, without
> any document visible at all.
>
> Note: The descriptions below assume that workers must be same-origin
> with the documents that instantiate them. If this invariant changes,
> we'll need to take the worker's script's URI into account when
> determining their status.
>
> 2.1.2.1. Dedicated and Shared Workers
>
> Dedicated workers are simple, as each dedicated worker is bound to
> one and only one document. Requests generated from a dedicated
> worker (via "importScripts", "XMLHttpRequest", "fetch()", etc) define
> their "site for cookies" as that document's "site for cookies".
>
> Shared workers may be bound to multiple documents at once. As it is
> quite possible for those documents to have distinct "site for cookie"
> values, the worker's "site for cookies" will be the empty string in
> cases where the values diverge, and the shared value in cases where
> the values agree.
s/agree/match/ ?
>
> Given a WorkerGlobalScope ("worker"), the following algorithm returns
> its "site for cookies" (either a registrable domain, or the empty
> string):
>
> 1. Let "site" be "worker"'s origin's host's registrable domain.
>
> 2. For each "document" in "worker"'s Documents:
>
> 1. Let "document-site" be "document"'s "site for cookies" (as
> defined in Section 2.1.1).
>
> 2. If "document-site" is not an exact match for "site", return
> the empty string.
s/empty string/empty string and abort these steps/ ?
>
> 3. Return "site".
>
> 2.1.2.2. Service Workers
>
> Service Workers are more complicated, as they act as a completely
> separate execution context with only tangential relationship to the
> Document which registered them.
>
> Requests which simply pass through a service worker will be handled
> as described above: the request's client will be the Document or
> Worker which initiated the request, and its "site for cookies" will
> be those defined in Section 2.1.1 and Section 2.1.2.1
>
> Requests which are initiated by the Service Worker itself (via a
> direct call to "fetch()", for instance), on the other hand, will have
> a client which is a ServiceWorkerGlobalScope. Its "site for cookies"
> will be the registrable domain of the Service Worker's URI.
Service Worker's URI is not clearly defined in [SERVICE-WORKERS]
would it be ServiceWorker.registration.scope ?
or would it be ServiceWorkerGlobalScope.location.href (It represents the
absolute URL of the script that was used to initialize the worker)? -- I'm
guessing the latter is unlikely and what is referred to here as the "service
worker's URI" is it's scope URL, yes?
> Given a ServiceWorkerGlobalScope ("worker"), the following algorithm
> returns its "site for cookies" (either a registrable domain, or the
> empty string):
>
> 1. Return "worker"'s origin's host's registrable domain.
`"worker"'s origin` is not clearly defined in [SERVICE-WORKERS] or [HTML] --
is it WorkerGlobalScope.location.href (sorta figured out from [HTML]) ?
> 3. Server Requirements
>
> This section describes extensions to [RFC6265] necessary to implement
^
section 4
> the server-side requirements of the "SameSite" attribute.
>
> 3.1. Grammar
>
> Add "SameSite" to the list of accepted attributes in the "Set-Cookie"
> header field's value by replacing the "cookie-av" token definition in
> Section 4.1.1 of [RFC6265] with the following ABNF grammar:
>
> cookie-av = expires-av / max-age-av / domain-av /
> path-av / secure-av / httponly-av /
> samesite-av / extension-av
> samesite-av = "SameSite" / "SameSite=" samesite-value
^^^^^^^
this allows for a SameSite attr without a value?
is that actually used somewhere in the below algorithms?
> samesite-value = "Strict" / "Lax"
>
>
>
> 3.2. Semantics of the "SameSite" Attribute (Non-Normative)
>
> The "SameSite" attribute limits the scope of the cookie such that it
> will only be attached to requests if those requests are "same-site",
> as defined by the algorithm in Section 2.1.
^^^^^^^^^^^^^^^^
delete
> For example, requests
> for "https://example.com/sekrit-image" will attach same-site cookies
> if and only if initiated from a context whose "site for cookies" is
> "example.com".
>
> If the "SameSite" attribute's value is "Strict", or if the value is
> invalid, the cookie will only be sent along with "same-site"
> requests.
suggest s/"same-site" request/same-site request/g
> If the value is "Lax", the cookie will be sent with "same-
> site" requests, and with "cross-site" top-level navigations, as
> described in Section 4.1.1.
what if the SameSite attribute has no attribute value as allowed by the ABNF
above?
> The changes to the "Cookie" header field suggested in Section 4.3
> provide additional detail.
>
> 4. User Agent Requirements
>
> This section describes extensions to [RFC6265] necessary in order to
^
Section 5
> implement the client-side requirements of the "SameSite" attribute.
>
> 4.1. The "SameSite" attribute
>
> The following attribute definition should be considered part of the
> the "Set-Cookie" algorithm as described in Section 5.2 of [RFC6265]:
> If the "attribute-name" case-insensitively matches the string
> "SameSite", the user agent MUST process the "cookie-av" as follows:
>
> 1. If "cookie-av"'s "attribute-value" is not a case-sensitive match
> for "Strict" or "Lax", ignore the "cookie-av".
should the cookie-av's attribute-value match here be case-insensitive since
the match in the following rule is case-insensitive?
also, what if attribute-value is empty becase SameSite had no value ? though
I suppose the above rule addresses that i.e. it would ignore the cookie-av ?
> 2. Let "enforcement" be "Lax" if "cookie-av"'s "attribute-value" is
> a case-insensitive match for "Lax", and "Strict" otherwise.
>
> 3. Append an attribute to the "cookie-attribute-list" with an
> "attribute-name" of "SameSite" and an "attribute-value" of
> "enforcement".
oh, so enforcement here is just a local algorithm variable? and step 3 is
actually saying to use the value of enforcement as the attr-value for SameSite
? if so, perhaps ought to be clarified...
> 4.1.1. "Strict" and "Lax" enforcement
>
> By default, same-site cookies will not be sent along with top-level
> navigations. As discussed in Section 5.2, this might or might not be
> compatible with existing session management systems. In the
> interests of providing a drop-in mechanism that mitigates the risk of
> CSRF attacks, developers may set the "SameSite" attribute in a "Lax"
> enforcement mode that carves out an exception which sends same-site
> cookies along with cross-site requests if and only if they are top-
> level navigations which use a "safe" (in the [RFC7231] sense) HTTP
> method.
>
> Lax enforcement provides reasonable defense in depth against CSRF
> attacks that rely on unsafe HTTP methods (like "POST"), but do not
s/do not/does not/ ?
> offer a robust defense against CSRF as a general category of attack:
>
> 1. Attackers can still pop up new windows or trigger top-level
> navigations in order to create a "same-site" request (as
> described in section 2.1), which is only a speedbump along the
> road to exploitation.
>
> 2. Features like "<link rel='prerender'>" [prerendering] can be
> exploited to create "same-site" requests without the risk of user
> detection.
>
> When possible, developers should use a session management mechanism
> such as that described in Section 5.2 to mitigate the risk of CSRF
> more completely.
"Strict" enforcement is not explicitly defined?
hm, i guess it is defined in S 3.2 -- perhaps add a x-ref to that?
> 4.2. Monkey-patching the Storage Model
>
> Note: There's got to be a better way to specify this. Until I figure
> out what that is, monkey-patching!
>
> Alter Section 5.3 of [RFC6265] as follows:
>
> 1. Add "samesite-flag" to the list of fields stored for each cookie.
s/Add/Add (in the first paragraph)/ -- the list of fields is in the first
parag of S 5.3
> This field's value is one of "None", "Strict", or "Lax".
i'd prefix the above sentence with 'Note: '
> 2. Before step 11 of the current algorithm, add the following:
the below are to be new top-level algorithm steps?
> 1. If the "cookie-attribute-list" contains an attribute with an
> "attribute-name" of "SameSite", set the cookie's "samesite-
> flag" to "attribute-value" ("Strict" or "Lax"). Otherwise,
> set the cookie's "samesite-flag" to "None".
>
> 2. If the cookie's "samesite-flag" is not "None", and the
> request which generated the cookie's client's "site for
> cookies"
the term "cookie's client('s)" is used only here (and also isn't defined in
RFC6265) -- what is it's definition?
> is not an exact match for "request-uri"'s host's
> registrable domain, then abort these steps and ignore the
> newly created cookie entirely.
so the above step applies whether the enforcement policy is lax or strict?
> 4.3. Monkey-patching the "Cookie" header
>
> Note: There's got to be a better way to specify this. Until I figure
> out what that is, monkey-patching!
>
> Alter Section 5.4 of [RFC6265] as follows:
>
> 1. Add the following requirement to the list in step 1:
to the end of the existing bullet list in [RFC6265] ?
> * If the cookie's "samesite-flag" is not "None", and the HTTP
> request is cross-site (as defined in Section 2.1 then exclude
^
)
> the cookie unless all of the following statements hold:
>
> 1. "samesite-flag" is "Lax"
>
> 2. The HTTP request's method is "safe".
>
> 3. The HTTP request's target browsing context is a top-level
> browsing context.
>
> Note that the modifications suggested here concern themselves only
> with the "site for cookies" of the request's client, and the
> registrable domain of the resource being requested. The cookie's
> "domain", "path", and "secure" attributes do not come into play for
> these comparisons.
>
> 5. Authoring Considerations
this section is intended to be added to 6265bis?
> 5.1. Defense in depth
>
> "SameSite" cookies offer a robust defense against CSRF attack when
> deployed in strict mode, and when supported by the client. It is,
> however, prudent to ensure that this designation is not the extent of
> a site's defense against CSRF, as same-site navigations and
> submissions can certainly be executed in conjunction with other
> attack vectors such as cross-site scripting.
>
> Developers are strongly encouraged to deploy the usual server-side
> defenses (CSRF tokens, ensuring that "safe" HTTP methods are
> idempotent, etc) to mitigate the risk more fully.
>
> Additionally, client-side techniques such as those described in
> [app-isolation] may also prove effective against CSRF, and are
> certainly worth exploring in combination with "SameSite" cookies.
>
>
>
> 5.2. Top-level Navigations
>
> Setting the "SameSite" attribute in "strict" mode provides robust
> defense in depth against CSRF attacks, but has the potential to
> confuse users unless sites' developers carefully ensure that their
> session management systems deal reasonably well with top-level
> navigations.
>
> Consider the scenario in which a user reads their email at MegaCorp
> Inc's webmail provider "https://example.com/". They might expect
> that clicking on an emailed link to "https://projects.com/secret/
> project" would show them the secret project that they're authorized
> to see, but if "projects.com" has marked their session cookies as
> "SameSite", then this cross-site navigation won't send them along
> with the request. "projects.com" will render a 404 error to avoid
> leaking secret information, and the user will be quite confused.
>
> Developers can avoid this confusion by adopting a session management
> system that relies on not one, but two cookies: one conceptualy
s/conceptualy/conceptually/
> granting "read" access, another granting "write" access. The latter
> could be marked as "SameSite", and its absence would provide a
s/provide/prompt/ ?
> reauthentication step before executing any non-idempotent action.
> The former could drop the "SameSite" attribute entirely, or choose
> the "Lax" version of enforcement, in order to allow users access to
> data via top-level navigation.
so the above is based on the sites using cookie-based ambient authn (yes?),
which is a reasonable assumption I suppose but perhaps should be stated
explicitly?
> 5.3. Mashups and Widgets
>
> The "SameSite" attribute is inappropriate for some important use-
> cases. In particular, note that content intended for embedding in a
> cross-site contexts (social networking widgets or commenting
> services, for instance) will not have access to such cookies.
by "such cookies" you mean same-site cookies ?
> Cross-
> site cookies may be required in order to provide seamless
> functionality that relies on a user's state.
by "cross-site cookies" you mean cookies lacking the SameSite attribute? this
is the only place this term is used at this time...
> Likewise, some forms of Single-Sign-On might require authentication
by "authentication" here you mean ambient cookie-based authn ?
> in a cross-site context; these mechanisms will not function as
> intended with same-site cookies.
and thus will need to (continue) to use so-called cross-site cookies ?
> 6. Privacy Considerations
the below are to be added to 6265bis ?
>
> 6.1. Server-controlled
>
> Same-site cookies in and of themselves don't do anything to address
> the general privacy concerns outlined in Section 7.1 of [RFC6265].
> The attribute is set by the server, and serves to mitigate the risk
^
SameSite ?
> of certain kinds of attacks that the server is worried about. The
> user is not involved in this decision. Moreover, a number of side-
> channels exist which could allow a server to link distinct requests
> even in the absence of cookies.
you mean to say "..could allow a third-party server to link distinct top-level
navigation requests to first-party servers, even in the absence of cookies." ?
> Connection and/or socket pooling,
> Token Binding, and Channel ID all offer explicit methods of
> identification that servers could take advantage of.
I'm not sure the above sentence is applicable to the third-party cookie
discussion in RFC6265 S 7.1. My understanding is that Token Binding and
ChannelID present server-specific identifiers and cannot be used by a
third-party server to track the UA's top-level navigation requests to various
first-party servers.
> 6.2. Pervasive Monitoring
>
> As outlined in [RFC7258], pervasive monitoring is an attack. Cookies
> play a large part in enabling such monitoring, as they are
> responsible for maintaining state in HTTP connections. We considered
> restricting same-site cookies to secure contexts [secure-contexts] as
> a mitigation but decided against doing so, as this feature should
by "this feature" you mean same-site cookies ?
> result in a strict reduction in the number of cookies floating around
> in cross-site contexts. That is, even if "http://not-example.com"
> embeds a resource from "http://example.com/", that resource will not
> be "same-site", and "http://example.com"'s cookies simply cannot be
> used to correlate user behavior across distinct origins.
>
> 7. References
<snip/>
> [app-isolation]
> Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson,
> "App Isolation - Get the Security of Multiple Browsers
> with Just One", n.d.,
> <http://www.collinjackson.com/research/papers/
> appisolation.pdf>.
the date of this paper appears to be 2011..
CCS’11, October 17–21, 2011, Chicago, Illinois, USA.
Copyright 2011 ACM 978-1-4503-0948-6/11/10
end
Received on Friday, 17 June 2016 22:21:47 UTC