This repository has been archived by the owner on Apr 2, 2020. It is now read-only.
forked from mikewest/cookie-incrementalism
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-west-cookie-incrementalism.html
613 lines (560 loc) · 29.7 KB
/
draft-west-cookie-incrementalism.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>Incrementally Better Cookies</title>
<style type="text/css">/*<![CDATA[*/
body {
font: 16px "Helvetica Neue","Open Sans",Helvetica,Calibri,sans-serif;
color: #333;
font-size-adjust: 0.5;
line-height: 24px;
margin: 75px auto;
max-width: 624px;
padding: 0 5px;
}
.title, .filename, h1, h2, h3, h4, h5 {
font: 16px "Roboto Condensed","Helvetica Neue","Open Sans",Helvetica,Calibri,sans-serif;
font-size-adjust: 0.5;
font-weight: bold;
color: #333;
line-height: 100%;
margin: 1.2em 0 0.3em;
}
.title, #rfc\.title h1 { font-size: 32px; }
h1, section h1, h2, section h2, section h3, nav h2 { font-size: 20px; }
h3, section h4, h4, section h5 { font-size: 16px; }
h1 a[href], h2 a[href], h3 a[href], h4 a[href] {
color: #333;
}
table {
margin-left: 0em;
border-collapse: collapse;
}
th {
text-align: left;
border-bottom: 2px solid #ddd;
}
td {
border-top: 1px solid #ddd;
vertical-align: top;
}
tr:nth-child(2n+1) > td,
tr:nth-child(2n+1) > th {
background-color: #f9f9f9;
}
td.reference {
max-width: 200px;
border-top: none;
padding-right: 1em;
}
.right {
text-align: right;
}
table.header, table#rfc\.headerblock {
width: 100%;
}
table.header td, table#rfc\.headerblock td {
border: none;
background-color: transparent;
color: black;
padding: 0;
}
.filename {
display: block;
color: rgb(119, 119, 119);
font-size: 20px;
font-weight: normal;
line-height: 100%;
margin: 10px 0 32px;
}
#rfc\.abstract+p, #rfc\.abstract+p code, #rfc\.abstract+p samp, #rfc\.abstract+p tt {
font-size: 20px;
line-height: 28px;
}
samp, tt, code, pre, span.tt {
font-size: 13.5px;
font-family: Consolas, monospace;
font-size-adjust: none;
}
pre {
background-color: #eee;
border: 1px solid #ddd;
overflow-x: auto;
padding: 5px;
margin: 5px;
}
.figure, caption {
font-style: italic;
margin: 0 1.5em;
text-align: left;
}
address {
margin: 16px 2px;
line-height: 20px;
}
.vcard {
font-style: normal;
}
.vcardline {
display: block;
}
.vcardline .fn, address b {
font-weight: normal;
}
.vcardline .hidden {
display: none;
}
dl {
margin-left: 1em;
}
dl.dl-horizontal: {
margin-left: 0;
}
dl > dt {
float: left;
margin-right: 1em;
}
dl.nohang > dt {
float: none;
}
dl > dd {
margin-bottom: .5em;
}
dl.compact > dd {
margin-bottom: 0em;
}
dl > dd > dl {
margin-top: 0.5em;
margin-bottom: 0em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
hr {
border: 0;
border-top: 1px solid #eee;
}
hr.noprint {
display: none;
}
a {
text-decoration: none;
}
a[href] {
color: #2a6496;
}
a[href]:hover {
background-color: #eee;
}
p, ol, ul, li {
padding: 0;
}
p {
margin: 0.5em 0;
}
ol, ul {
margin: 0.2em 0 0.2em 2em;
}
li {
margin: 0.2em 0;
}
address {
font-style: normal;
}
ul.toc ul {
margin: 0 0 0 2em;
}
ul.toc li {
list-style: none;
margin: 0;
}
@media screen and (min-width: 924px) {
body {
padding-right: 350px;
}
body>ul.toc, body>#rfc\.toc {
position: fixed;
bottom: 0;
right: 0;
right: calc(50vw - 500px);
width: 300px;
z-index: 1;
overflow: auto;
overscroll-behavior: contain;
}
body>#rfc\.toc {
top: 55px;
}
body>ul.toc {
top: 100px;
}
ul.toc {
margin: 0 0 0 4px;
font-size: 12px;
line-height: 20px;
}
ul.toc ul {
margin-left: 1.2em;
}
}
.github-fork-ribbon-wrapper {
display: none;
}
@media screen and (min-width: 800px) {
/* "Fork me on GitHub" CSS ribbon based on
* https://github.com/simonwhitaker/github-fork-ribbon-css
*/
.github-fork-ribbon {
position: absolute;
padding: 2px 0;
background-color: #a00;
background-image: linear-gradient(to bottom, rgba(0, 0, 0, 0), rgba(0, 0, 0, 0.15));
box-shadow: 0 2px 3px 0 rgba(0, 0, 0, 0.5);
font: 700 12px "Helvetica Neue", Helvetica, Arial, sans-serif;
pointer-events: auto;
top: 38px;
right: -45px;
transform: rotate(45deg);
}
.github-fork-ribbon a[href],
.github-fork-ribbon a[href]:hover {
color: #fff;
background-color: transparent;
text-decoration: none;
text-shadow: 0 -1px rgba(0, 0, 0, 0.5);
text-align: center;
width: 190px;
line-height: 18px;
display: inline-block;
padding: 2px 0;
border: 1.5px dotted #fff;
border-color: rgba(255, 255, 255, 0.6);
}
.github-fork-ribbon-wrapper {
display: block;
width: 130px;
height: 130px;
position: absolute;
overflow: hidden;
top: 0; right: 0;
z-index: 2;
pointer-events: none;
}
}
@media screen and (min-width: 1000px) {
.github-fork-ribbon-wrapper {
position: fixed;
}
/*]]>*/</style>
<meta name="viewport" content="initial-scale=1.0">
<link href="#rfc.toc" rel="Contents">
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction">
<link href="#rfc.section.2" rel="Chapter" title="2 Conventions and Definitions">
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Conformance">
<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Syntax">
<link href="#rfc.section.3" rel="Chapter" title="3 Monkey-Patches against RFC6265bis">
<link href="#rfc.section.3.1" rel="Chapter" title="3.1 “Lax” by Default">
<link href="#rfc.section.3.2" rel="Chapter" title="3.2 Requiring “Secure” for “SameSite=None”">
<link href="#rfc.section.4" rel="Chapter" title="4 Security and Privacy Considerations">
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 CSRF">
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 Secure Transport">
<link href="#rfc.section.4.3" rel="Chapter" title="4.3 Tracking">
<link href="#rfc.section.5" rel="Chapter" title="5 Implementation Considerations">
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Sequencing">
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 Deployment">
<link href="#rfc.section.6" rel="Chapter" title="6 IANA Considerations">
<link href="#rfc.references" rel="Chapter" title="7 References">
<link href="#rfc.references.1" rel="Chapter" title="7.1 Normative References">
<link href="#rfc.references.2" rel="Chapter" title="7.2 Informative References">
<link href="#rfc.acknowledgments" rel="Chapter">
<link href="#rfc.authors" rel="Chapter">
<meta name="generator" content="xml2rfc version 2.14.1 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="West, M." />
<meta name="dct.identifier" content="urn:ietf:id:draft-west-cookie-incrementalism-latest" />
<meta name="dct.issued" scheme="ISO8601" content="2019-07" />
<meta name="dct.abstract" content="This document proposes two changes to cookies inspired by the properties of the HTTP State Tokens mechanism proposed in " />
<meta name="description" content="This document proposes two changes to cookies inspired by the properties of the HTTP State Tokens mechanism proposed in " />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Network Working Group</td>
<td class="right">M. West</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">Google</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">May 7, 2019</td>
</tr>
<tr>
<td class="left">Expires: November 8, 2019</td>
<td class="right"></td>
</tr>
</tbody>
</table>
<p class="title">Incrementally Better Cookies<br />
<span class="filename">draft-west-cookie-incrementalism-latest</span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>This document proposes two changes to cookies inspired by the properties of the HTTP State Tokens mechanism proposed in <a href="#I-D.west-http-state-tokens" class="xref">[I-D.west-http-state-tokens]</a>. First, cookies should be treated as <samp>SameSite=Lax</samp> by default. Second, cookies that explicitly assert <samp>SameSite=None</samp> in order to enable cross-site delivery should also be marked as <samp>Secure</samp>.</p>
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on November 8, 2019.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a>
</li>
<li>2. <a href="#rfc.section.2">Conventions and Definitions</a>
</li>
<ul><li>2.1. <a href="#rfc.section.2.1">Conformance</a>
</li>
<li>2.2. <a href="#rfc.section.2.2">Syntax</a>
</li>
</ul><li>3. <a href="#rfc.section.3">Monkey-Patches against RFC6265bis</a>
</li>
<ul><li>3.1. <a href="#rfc.section.3.1">“Lax” by Default</a>
</li>
<li>3.2. <a href="#rfc.section.3.2">Requiring “Secure” for “SameSite=None”</a>
</li>
</ul><li>4. <a href="#rfc.section.4">Security and Privacy Considerations</a>
</li>
<ul><li>4.1. <a href="#rfc.section.4.1">CSRF</a>
</li>
<li>4.2. <a href="#rfc.section.4.2">Secure Transport</a>
</li>
<li>4.3. <a href="#rfc.section.4.3">Tracking</a>
</li>
</ul><li>5. <a href="#rfc.section.5">Implementation Considerations</a>
</li>
<ul><li>5.1. <a href="#rfc.section.5.1">Sequencing</a>
</li>
<li>5.2. <a href="#rfc.section.5.2">Deployment</a>
</li>
</ul><li>6. <a href="#rfc.section.6">IANA Considerations</a>
</li>
<li>7. <a href="#rfc.references">References</a>
</li>
<ul><li>7.1. <a href="#rfc.references.1">Normative References</a>
</li>
<li>7.2. <a href="#rfc.references.2">Informative References</a>
</li>
</ul><li><a href="#rfc.acknowledgments">Acknowledgments</a>
</li>
<li><a href="#rfc.authors">Author's Address</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a>
</h1>
<p id="rfc.section.1.p.1">The HTTP State Tokens proposal (<a href="#I-D.west-http-state-tokens" class="xref">[I-D.west-http-state-tokens]</a>) aims to replace cookies with a state management mechanism that has better security and privacy properties. That proposal is somewhat aspirational: it’s going to take a long time to come to agreement on the exact contours of a cookie replacement, and an even longer time to actually do so.</p>
<p id="rfc.section.1.p.2">While we’re debating the details of a new state management primitive, it seems quite reasonable to reevaluate some aspects of the existing primitive: cookies. When we can find consensus on some aspect of HTTP State Tokens, we can apply those aspirations to cookies, driving incremental improvements to state management in the status quo.</p>
<p id="rfc.section.1.p.3">Based on conversations at <a href="#HTTP-Workshop-2019" class="xref">[HTTP-Workshop-2019]</a> and elsewhere, I’d suggest that we have something like agreement on at least two principles:</p>
<p></p>
<ol>
<li>HTTP requests should not carry state along with cross-site requests by default (see Section 8.2 of <a href="#RFC6265bis" class="xref">[RFC6265bis]</a>).</li>
<li>HTTP requests should not carry state over non-secure channels (see Section 8.3 of <a href="#RFC6265bis" class="xref">[RFC6265bis]</a>, and <a href="#RFC7258" class="xref">[RFC7258]</a>).</li>
</ol>
<p id="rfc.section.1.p.5">With those principles in mind, this document proposes two changes that seem possible to deploy in the near-term. User agents should:</p>
<p></p>
<ol>
<li>Treat the lack of an explicit <samp>SameSite</samp> attribute as <samp>SameSite=Lax</samp>. That is, the <samp>Set-Cookie</samp> value <samp>key=value</samp> will produce a cookie equivalent to <samp>key=value; SameSite=Lax</samp>. Cookies that require cross-site delivery can explicitly opt-into such behavior by asserting <samp>SameSite=None</samp> when creating a cookie. <br><br> This is spelled out in more detail in <a href="#lax-default" class="xref">Section 3.1</a>.</li>
<li>Require the <samp>Secure</samp> attribute to be set for any cookie which asserts <samp>SameSite=None</samp> (similar conceptually to the behavior for the <samp>__Secure-</samp> prefix). That is, the <samp>Set-Cookie</samp> value <samp>key=value; SameSite=None; Secure</samp> will be accepted, while <samp>key=value; SameSite=None</samp> will be rejected. <br><br> This is spelled out in more detail in <a href="#require-secure" class="xref">Section 3.2</a>.</li>
</ol>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#conventions-and-definitions" id="conventions-and-definitions">Conventions and Definitions</a>
</h1>
<h1 id="rfc.section.2.1">
<a href="#rfc.section.2.1">2.1.</a> <a href="#conformance" id="conformance">Conformance</a>
</h1>
<p id="rfc.section.2.1.p.1">The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 <a href="#RFC2119" class="xref">[RFC2119]</a> <a href="#RFC8174" class="xref">[RFC8174]</a> when, and only when, they appear in all capitals, as shown here.</p>
<h1 id="rfc.section.2.2">
<a href="#rfc.section.2.2">2.2.</a> <a href="#syntax" id="syntax">Syntax</a>
</h1>
<p id="rfc.section.2.2.p.1">This document adjusts some syntax from <a href="#RFC6265bis" class="xref">[RFC6265bis]</a>, and in doing so, relies upon the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" class="xref">[RFC5234]</a>.</p>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#monkey-patches-against-rfc6265bis" id="monkey-patches-against-rfc6265bis">Monkey-Patches against RFC6265bis</a>
</h1>
<h1 id="rfc.section.3.1">
<a href="#rfc.section.3.1">3.1.</a> <a href="#lax-default" id="lax-default">“Lax” by Default</a>
</h1>
<p id="rfc.section.3.1.p.1">The processing algorithm in Section 5.3.7 of <a href="#RFC6265bis" class="xref">[RFC6265bis]</a> treats the absence of a <samp>SameSite</samp> attribute in a <samp>Set-Cookie</samp> header as equivalent to the presence of <samp>SameSite=None</samp>. Cookies are therefore available for cross-site delivery by default, and developers may opt-into more security by setting some other value explicitly. Ideally, we’d invert that such that developers who accepted the risks of cross-site delivery (see Section 8.2 of <a href="#RFC6265bis" class="xref">[RFC6265bis]</a>) could opt into them, while developers who didn’t make any explicit choice would be protected by default.</p>
<p id="rfc.section.3.1.p.2">We could accomplish this goal by first altering the processing algorithm, replacing the current step 1:</p>
<pre>
1. Let "enforcement" be "None".
</pre>
<p id="rfc.section.3.1.p.3">with the following two steps:</p>
<pre>
1. Let "enforcement" be "Lax".
2. If cookie-av's attribute-value is a case-insensitive
match for "None", set "enforcement" to "None".
</pre>
<p id="rfc.section.3.1.p.4">And then by, altering step 13 of the cookie storage model (Section 5.4 of <a href="#RFC6265bis" class="xref">[RFC6265bis]</a>) from:</p>
<pre>
13. If the cookie-attribute-list contains an attribute
with an attribute-name of "SameSite", set the cookie's
same-site-flag to attribute-value (i.e. either "Strict",
"Lax", or "None"). Otherwise, set the cookie's
same-site-flag to "None".
</pre>
<p id="rfc.section.3.1.p.5">to:</p>
<pre>
13. If the cookie-attribute-list contains an attribute
with an attribute-name of "SameSite", set the
cookie's same-site-flag to attribute-value. Otherwise,
set the cookie's same-site-flag to "Lax".
</pre>
<p id="rfc.section.3.1.p.6">This would have the effect of mapping the default behavior in the absence of an explicit <samp>SameSite</samp> attribute, as well as the presence of any unknown <samp>SameSite</samp> value, to the “Lax” behavior, protecting developers by making cross-site delivery an explicit choice, as opposed to an implicit default.</p>
<h1 id="rfc.section.3.2">
<a href="#rfc.section.3.2">3.2.</a> <a href="#require-secure" id="require-secure">Requiring “Secure” for “SameSite=None”</a>
</h1>
<p id="rfc.section.3.2.p.1">Cookies sent over plaintext HTTP are visible to anyone on the network. As section 8.3 of <a href="#RFC6265bis" class="xref">[RFC6265bis]</a> points out, this visibility exposes substantial amounts of data to network attackers. We know, for example, that long-lived and stable cookies have enabled pervasive monitoring <a href="#RFC7258" class="xref">[RFC7258]</a> in the past (see Google’s PREF cookie <a href="#pref-cookie" class="xref">[pref-cookie]</a>), and we know that a secure transport layer provides significant confidentiality protections against this kind of attack.</p>
<p id="rfc.section.3.2.p.2">We can, to a reasonable extent, mitigate this threat by ensuring that cookies intended for cross-site delivery (and therefore likely to be more prevalent on the wire than cookies scoped down to same-site requests) require secure transport.</p>
<p id="rfc.section.3.2.p.3">That is, we can require that any cookie which asserts <samp>SameSite=None</samp> must also assert the <samp>Secure</samp> attribute (Section 4.1.2.5 of <a href="#RFC6265bis" class="xref">[RFC6265bis]</a>) by altering the storage model defined in Section 5.4 of <a href="#RFC6265bis" class="xref">[RFC6265bis]</a>, inserting the following step after the existing step 14:</p>
<pre>
15. If the cookie's "same-site-flag" is "None", abort
these steps and ignore the cookie entirely unless
the cookie's secure-only-flag is true.
</pre>
<p id="rfc.section.3.2.p.4">This is conceptually similar to the requirements put into place for the <samp>__Secure-</samp> prefix (Section 4.1.3.1 of <a href="#RFC6265bis" class="xref">[RFC6265bis]</a>).</p>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#security-and-privacy-considerations" id="security-and-privacy-considerations">Security and Privacy Considerations</a>
</h1>
<h1 id="rfc.section.4.1">
<a href="#rfc.section.4.1">4.1.</a> <a href="#csrf" id="csrf">CSRF</a>
</h1>
<p><samp>SameSite</samp> is a reasonably robust defense against some classes of cross-site request forgery attacks, as described in Section 8.8.1 of <a href="#RFC6265bis" class="xref">[RFC6265bis]</a>, but developers need to opt-into its protections in order for them to have any effect. That is, developers are vulnerable to CSRF attacks by default, and must do some work to shift themselves into a more defensible position.</p>
<p id="rfc.section.4.1.p.2">The change proposed in <a href="#lax-default" class="xref">Section 3.1</a> would invert that requirement, placing the burden on the small number of developers who are building services that require state in cross-site requests. Those developers would be empowered to opt-into the status quo’s less-secure model, while developers who don’t intend for their projects to be embedded in cross-site contexts are protected by default.</p>
<h1 id="rfc.section.4.2">
<a href="#rfc.section.4.2">4.2.</a> <a href="#secure-transport" id="secure-transport">Secure Transport</a>
</h1>
<p id="rfc.section.4.2.p.1">As discussed in Section 8.3 of <a href="#RFC6265bis" class="xref">[RFC6265bis]</a>, cookies delivered over plaintext channels are exposed to intermediaries, and thereby enable pervasive monitoring <a href="#RFC7258" class="xref">[RFC7258]</a>. The change proposed in <a href="#require-secure" class="xref">Section 3.2</a> above would set secure transport as a baseline requirement for all stateful cross-site requests, thereby reducing the risk that these cookies can be cataloged or modified by network attackers.</p>
<p id="rfc.section.4.2.p.2">Requiring secure transport for cookies intended for cross-site usage has the exciting secondary effect of increasing pressure on entities that produce embeddable content to migrate their products to HTTPS. That has security benefits for those third-party products themselves, but also has the effect of removing the potential of mixed content (<a href="#mixed-content" class="xref">[mixed-content]</a>) as a blocker to first-party migration to HTTPS.</p>
<p id="rfc.section.4.2.p.3">Note that in the long term, it seems quite reasonable to take the additional step of requiring the <samp>Secure</samp> attribute for all cookies, regardless of their <samp>SameSite</samp> value. That would have more substantial impact on pervasive monitoring and network attackers generally. This document’s proposal limits itself to <samp>SameSite=None</samp> because that seems like a low-hanging, high-value change that’s deployable in the near term. User agents are encouraged to find additional subsets for which <samp>Secure</samp> can be required.</p>
<h1 id="rfc.section.4.3">
<a href="#rfc.section.4.3">4.3.</a> <a href="#tracking" id="tracking">Tracking</a>
</h1>
<p id="rfc.section.4.3.p.1">The proposals in this document do not in themselves mitigate the privacy risks described in Section 7.1 of <a href="#RFC6265bis" class="xref">[RFC6265bis]</a>. Entities who wish to use cookies to track user activity from cross-site contexts can continue to do so by setting cookies that declare themselves as <samp>SameSite=None</samp>.</p>
<p id="rfc.section.4.3.p.2">Requiring that explicit declaration, however, gives user agents the ability to easily distinguish cookies used for stateful cross-site requests from those with narrower scope. After the change proposed in <a href="#lax-default" class="xref">Section 3.1</a>, only those cookies that make an explicit <samp>SameSite=None</samp> declaration can be directly used for cross-site tracking. It may make sense for user agents to use that information to give users different controls for these cookies, or to apply different policies for expiration and delivery.</p>
<h1 id="rfc.section.5">
<a href="#rfc.section.5">5.</a> <a href="#implementation-considerations" id="implementation-considerations">Implementation Considerations</a>
</h1>
<h1 id="rfc.section.5.1">
<a href="#rfc.section.5.1">5.1.</a> <a href="#sequencing" id="sequencing">Sequencing</a>
</h1>
<p id="rfc.section.5.1.p.1">The steps described in this document don’t need to be taken at the same time. It’s quite possible that it will be less disruptive to deploy <samp>SameSite=Lax</samp> as a default first, and then to require the <samp>Secure</samp> attribute for any explicitly <samp>SameSite=None</samp> cookie as a subsequent step.</p>
<p id="rfc.section.5.1.p.2">User agents are encouraged to adopt these recommendations in whatever order they believe will lead to the widest, most expedient deployment.</p>
<h1 id="rfc.section.5.2">
<a href="#rfc.section.5.2">5.2.</a> <a href="#deployment" id="deployment">Deployment</a>
</h1>
<p id="rfc.section.5.2.p.1">It’s possible that a middle-ground between <samp>SameSite=Lax</samp> and <samp>SameSite=None</samp> could be a better balance between doing what developers want by default, and mitigating CSRF by default. <a href="#I-D.west-cookie-samesite-firstparty" class="xref">[I-D.west-cookie-samesite-firstparty]</a> explores the possibility of integrating First-Party Sets <a href="#first-party-set" class="xref">[first-party-set]</a> with the <samp>SameSite</samp> attribute in order to allow entities that shard themselves across multiple registrable domains to maintain stateful communication between them (to support single-sign on, for example).</p>
<p id="rfc.section.5.2.p.2">It’s possible that user agents who support First-Party Sets could reduce the deployment overhead for developers, and increase the robustness of a site’s CSRF defense for cross-site-but-not-cross-party cookies by defaulting to something like that document’s <samp>FirstPartyLax</samp> instead of <samp>Lax</samp>.</p>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#iana-considerations" id="iana-considerations">IANA Considerations</a>
</h1>
<p id="rfc.section.6.p.1">This document has no IANA actions.</p>
<h1 id="rfc.references">
<a href="#rfc.references">7.</a> References</h1>
<h1 id="rfc.references.1">
<a href="#rfc.references.1">7.1.</a> Normative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="RFC2119">[RFC2119]</b></td>
<td class="top">
<a>Bradner, S.</a>, "<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
</tr>
<tr>
<td class="reference"><b id="RFC5234">[RFC5234]</b></td>
<td class="top">
<a>Crocker, D.</a> and <a>P. Overell</a>, "<a href="https://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008.</td>
</tr>
<tr>
<td class="reference"><b id="RFC6265bis">[RFC6265bis]</b></td>
<td class="top">
<a>Barth, A.</a> and <a>M. West</a>, "<a href="https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03">Cookies: HTTP State Management Mechanism</a>", Internet-Draft draft-ietf-httpbis-rfc6265bis-03, April 2019.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8174">[RFC8174]</b></td>
<td class="top">
<a>Leiba, B.</a>, "<a href="https://tools.ietf.org/html/rfc8174">Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</a>", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.</td>
</tr>
</tbody></table>
<h1 id="rfc.references.2">
<a href="#rfc.references.2">7.2.</a> Informative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="first-party-set">[first-party-set]</b></td>
<td class="top">
<a title="Google">West, M.</a>, "<a href="https://mikewest.github.io/first-party-sets/">First-Party Sets</a>", n.d..</td>
</tr>
<tr>
<td class="reference"><b id="HTTP-Workshop-2019">[HTTP-Workshop-2019]</b></td>
<td class="top">
<a title="Fastly">Nottingham, M.</a>, "<a href="https://github.com/HTTPWorkshop/workshop2019/wiki/Report">HTTP Workshop 2019: Report</a>", April 2019.</td>
</tr>
<tr>
<td class="reference"><b id="I-D.west-cookie-samesite-firstparty">[I-D.west-cookie-samesite-firstparty]</b></td>
<td class="top">
<a title="Google">West, M.</a>, "<a href="https://tools.ietf.org/html/draft-west-cookie-samesite-firstparty-00">First-Party Sets and SameSite Cookies</a>", May 2019.</td>
</tr>
<tr>
<td class="reference"><b id="I-D.west-http-state-tokens">[I-D.west-http-state-tokens]</b></td>
<td class="top">
<a>West, M.</a>, "<a href="https://tools.ietf.org/html/draft-west-http-state-tokens-00">HTTP State Tokens</a>", Internet-Draft draft-west-http-state-tokens-00, March 2019.</td>
</tr>
<tr>
<td class="reference"><b id="mixed-content">[mixed-content]</b></td>
<td class="top">
<a title="Google">West, M.</a>, "<a href="https://w3c.github.io/webappsec-mixed-content/">Mixed Content</a>", n.d..</td>
</tr>
<tr>
<td class="reference"><b id="pref-cookie">[pref-cookie]</b></td>
<td class="top">
<a>Soltani, A.</a>, <a>Peterson, A.</a> and <a>B. Gellman</a>, "<a href="https://www.washingtonpost.com/news/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/">NSA uses Google cookies to pinpoint targets for hacking</a>", December 2013.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7258">[RFC7258]</b></td>
<td class="top">
<a>Farrell, S.</a> and <a>H. Tschofenig</a>, "<a href="https://tools.ietf.org/html/rfc7258">Pervasive Monitoring Is an Attack</a>", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014.</td>
</tr>
</tbody></table>
<h1 id="rfc.acknowledgments"><a href="#rfc.acknowledgments">Acknowledgments</a></h1>
<p id="rfc.section.A.p.1">Conversations with a number of folks at 2019’s HTTP Workshop helped me clarify my thinking around the incremental improvements we can make to cookies. In particular, Martin Thomson and Anne van Kesteren provided insightful feedback.</p>
<h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Mike West</span>
<span class="n hidden">
<span class="family-name">West</span>
</span>
</span>
<span class="org vcardline">Google</span>
<span class="adr">
<span class="vcardline">
<span class="locality"></span>
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline"></span>
</span>
<span class="vcardline">EMail: <a href="mailto:[email protected]">[email protected]</a></span>
<span class="vcardline">URI: <a href="https://www.mikewest.org/">https://www.mikewest.org/</a></span>
</address>
</div>
</body>
</html>