-
Notifications
You must be signed in to change notification settings - Fork 3
/
rfc8446.html
9188 lines (6195 loc) · 461 KB
/
rfc8446.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
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<!-- saved from url=(0045)https://datatracker.ietf.org/doc/html/rfc8446 -->
<html lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<title>
rfc8446
</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<style>
@media only screen
and (min-width: 992px)
and (max-width: 1199px) {
body { font-size: 14pt; }
div.content { width: 96ex; margin: 0 auto; }
}
@media only screen
and (min-width: 768px)
and (max-width: 991px) {
body { font-size: 14pt; }
div.content { width: 96ex; margin: 0 auto; }
}
@media only screen
and (min-width: 480px)
and (max-width: 767px) {
body { font-size: 11pt; }
div.content { width: 96ex; margin: 0 auto; }
}
@media only screen
and (max-width: 479px) {
body { font-size: 8pt; }
div.content { width: 96ex; margin: 0 auto; }
}
@media only screen
and (min-device-width : 375px)
and (max-device-width : 667px) {
body { font-size: 9.5pt; }
div.content { width: 96ex; margin: 0; }
}
@media only screen
and (min-device-width: 1200px) {
body { font-size: 10pt; margin: 0 4em; }
div.content { width: 96ex; margin: 0; }
}
h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
font-weight: bold;
/* line-height: 0pt; */
display: inline;
white-space: pre;
font-family: monospace;
font-size: 1em;
font-weight: bold;
}
pre {
font-size: 1em;
margin-top: 0px;
margin-bottom: 0px;
}
.pre {
white-space: pre;
font-family: monospace;
}
.header{
font-weight: bold;
}
.newpage {
page-break-before: always;
}
.invisible {
text-decoration: none;
color: white;
}
@media print {
body {
margin-top: 5em;
font-family: monospace;
font-size: 10.5pt;
}
h1, h2, h3, h4, h5, h6 {
font-size: 1em;
}
a:link, a:visited {
color: inherit;
text-decoration: none;
}
.noprint {
display: none;
}
}
@media screen {
.grey, .grey a:link, .grey a:visited {
color: #777;
}
.meta-info {
background-color: #EEE;
}
.top {
border-top: 7px solid #EEE;
}
.pad {
padding-top: 7px;
line-height: 24px;
padding-bottom: 4px;
}
.bgwhite { background-color: white; }
.bgred { background-color: #F44; }
.bggrey { background-color: #666; }
.bgbrown { background-color: #840; }
.bgorange { background-color: #FA0; }
.bgyellow { background-color: #EE0; }
.bgmagenta{ background-color: #F4F; }
.bgblue { background-color: #66F; }
.bgcyan { background-color: #4DD; }
.bggreen { background-color: #4F4; }
.legend { font-size: 90%; }
.cplate { font-size: 70%; border: solid grey 1px; }
}
.bgwhite { background-color: white; }
.bgred { background-color: #F44; }
.bggrey { background-color: #666; }
.bgbrown { background-color: #840; }
.bgorange { background-color: #FA0; }
.bgyellow { background-color: #EE0; }
.bgmagenta{ background-color: #F4F; }
.bgblue { background-color: #66F; }
.bgcyan { background-color: #4DD; }
.bggreen { background-color: #4F4; }
.draftcontent { margin-top:0px !important;}
</style>
<!--[if lt IE 9]>
<script src="https://www.ietf.org/lib/dt/7.36.0/html5shiv/html5shiv.min.js"></script>
<script src="https://www.ietf.org/lib/dt/7.36.0/respond/dest/respond.min.js"></script>
<![endif]-->
<link rel="alternate" type="application/atom+xml" title="Document changes" href="https://datatracker.ietf.org/feed/document-changes/draft-ietf-tls-tls13/">
<meta name="description" content="The Transport Layer Security (TLS) Protocol Version 1.3 (RFC )">
<script src="./rfc8446_files/d3.min.js.download"></script>
<script src="./rfc8446_files/jquery.min.js.download"></script>
<link rel="shortcut icon" href="https://www.ietf.org/lib/dt/7.36.0/ietf/images/ietf-icon-blue3.png">
<link rel="apple-touch-icon" href="https://www.ietf.org/lib/dt/7.36.0/ietf/images/apple-touch-icon.png">
</head>
<body style="padding-top: 0;">
<div class="content" id="content">
<!-- template: /a/www/ietf-datatracker/web/ietf/templates/doc/document_html.html -->
<div class="rfcmarkup">
<div class="noprint" style="height: 6px;">
<div onmouseover="this.style.cursor='pointer';" onclick="showLegend();" onmouseout="hideLegend()" style="height: 6px; min-height: 6px; width: 96ex; position: absolute; margin-top:0; " class="meta-info bgblue" title="Click for colour legend."> </div>
<div id="legend" class="meta-info noprint pre legend" style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; " onmouseover="showLegend();" onmouseout="hideLegend();">
</div>
</div>
<div class="noprint">
<pre class="pre meta-info">[<a href="https://datatracker.ietf.org/" title="Document search and retrieval page">Search</a>] [<a href="https://www.rfc-editor.org/rfc/rfc8446.txt" title="Plaintext version of this document">txt</a>|<a href="https://www.rfc-editor.org/rfc/rfc8446.html" title="HTML version of this document, from XML2RFC">html</a>|<a href="https://www.rfc-editor.org/rfc/pdfrfc/rfc8446.txt.pdf" title="PDF version of this document">pdf</a>|<a href="https://www.rfc-editor.org/rfc/inline-errata/rfc8446.html">with errata</a>|<a href="https://datatracker.ietf.org/doc/rfc8446/bibtex" title="BibTex entry for this document">bibtex</a>] [<a href="https://datatracker.ietf.org/doc/rfc8446/" title="Datatracker information for this document">Tracker</a>] [<a href="https://datatracker.ietf.org/group/tls/" title="The working group handling this document">WG</a>] [<a href="mailto:draft-ietf-tls-tls13@ietf.org?subject=draft-ietf-tls-tls13" title="Send email to the document authors">Email</a>] [<a href="https://www.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-tls13-28.txt" title="Inline diff (wdiff)">Diff1</a>] [<a href="https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-28.txt" title="Side-by-side diff">Diff2</a>] [<a href="https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tls-tls13-28.txt" title="Run an idnits check of this document">Nits</a>]
From: <a href="https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-28">draft-ietf-tls-tls13-28</a> Proposed Standard
<a class="text-warning" href="https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-tls13">IPR declarations</a>
<a class="text-warning" href="https://www.rfc-editor.org/errata_search.php?rfc=8446&rec_status=0">Errata exist</a></pre>
</div>
<div class="draftcontent">
<pre>Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 8446 Mozilla
Obsoletes: <a href="https://datatracker.ietf.org/doc/html/rfc5077">5077</a>, <a href="https://datatracker.ietf.org/doc/html/rfc5246">5246</a>, <a href="https://datatracker.ietf.org/doc/html/rfc6961">6961</a> August 2018
Updates: <a href="https://datatracker.ietf.org/doc/html/rfc5705">5705</a>, <a href="https://datatracker.ietf.org/doc/html/rfc6066">6066</a>
Category: Standards Track
ISSN: 2070-1721
<span class="h1">The Transport Layer Security (TLS) Protocol Version 1.3</span>
Abstract
This document specifies version 1.3 of the Transport Layer Security
(TLS) protocol. TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery.
This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077,
5246, and 6961. This document also specifies new requirements for
TLS 1.2 implementations.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="https://datatracker.ietf.org/doc/html/rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>.
<span class="grey">Rescorla Standards Track [Page 1]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-2"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://datatracker.ietf.org/doc/html/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
<span class="grey">Rescorla Standards Track [Page 2]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-3"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
Table of Contents
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-1">1</a>. Introduction ....................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-6">6</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-1.1">1.1</a>. Conventions and Terminology ................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-7">7</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-1.2">1.2</a>. Major Differences from TLS 1.2 .............................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-8">8</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-1.3">1.3</a>. Updates Affecting TLS 1.2 ..................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-9">9</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-2">2</a>. Protocol Overview ..............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-10">10</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-2.1">2.1</a>. Incorrect DHE Share .......................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-14">14</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-2.2">2.2</a>. Resumption and Pre-Shared Key (PSK) .......................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-15">15</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-2.3">2.3</a>. 0-RTT Data ................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-17">17</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-3">3</a>. Presentation Language ..........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-19">19</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-3.1">3.1</a>. Basic Block Size ..........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-19">19</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-3.2">3.2</a>. Miscellaneous .............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-20">20</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-3.3">3.3</a>. Numbers ...................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-20">20</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-3.4">3.4</a>. Vectors ...................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-20">20</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-3.5">3.5</a>. Enumerateds ...............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-21">21</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-3.6">3.6</a>. Constructed Types .........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-22">22</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-3.7">3.7</a>. Constants .................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-23">23</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-3.8">3.8</a>. Variants ..................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-23">23</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4">4</a>. Handshake Protocol .............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-24">24</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.1">4.1</a>. Key Exchange Messages .....................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-25">25</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.1">4.1.1</a>. Cryptographic Negotiation ..........................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-26">26</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.2">4.1.2</a>. Client Hello .......................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-27">27</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3">4.1.3</a>. Server Hello .......................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-31">31</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.4">4.1.4</a>. Hello Retry Request ................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-33">33</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2">4.2</a>. Extensions ................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-35">35</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.1">4.2.1</a>. Supported Versions .................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-39">39</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.2">4.2.2</a>. Cookie .............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-40">40</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3">4.2.3</a>. Signature Algorithms ...............................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-41">41</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4">4.2.4</a>. Certificate Authorities ............................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-45">45</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.5">4.2.5</a>. OID Filters ........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-45">45</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.6">4.2.6</a>. Post-Handshake Client Authentication ...............<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-47">47</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.7">4.2.7</a>. Supported Groups ...................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-47">47</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.8">4.2.8</a>. Key Share ..........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-48">48</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.9">4.2.9</a>. Pre-Shared Key Exchange Modes ......................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-51">51</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.10">4.2.10</a>. Early Data Indication .............................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-52">52</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.11">4.2.11</a>. Pre-Shared Key Extension ..........................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-55">55</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.3">4.3</a>. Server Parameters .........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-59">59</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.1">4.3.1</a>. Encrypted Extensions ...............................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-60">60</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2">4.3.2</a>. Certificate Request ................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-60">60</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.4">4.4</a>. Authentication Messages ...................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-61">61</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.1">4.4.1</a>. The Transcript Hash ................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-63">63</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2">4.4.2</a>. Certificate ........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-64">64</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.3">4.4.3</a>. Certificate Verify .................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-69">69</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.4">4.4.4</a>. Finished ...........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-71">71</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.5">4.5</a>. End of Early Data .........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-72">72</a>
<span class="grey">Rescorla Standards Track [Page 3]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-4"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.6">4.6</a>. Post-Handshake Messages ...................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-73">73</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.1">4.6.1</a>. New Session Ticket Message .........................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-73">73</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.2">4.6.2</a>. Post-Handshake Authentication ......................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-75">75</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.3">4.6.3</a>. Key and Initialization Vector Update ...............<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-76">76</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-5">5</a>. Record Protocol ................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-77">77</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-5.1">5.1</a>. Record Layer ..............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-78">78</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-5.2">5.2</a>. Record Payload Protection .................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-80">80</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-5.3">5.3</a>. Per-Record Nonce ..........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-82">82</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-5.4">5.4</a>. Record Padding ............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-83">83</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-5.5">5.5</a>. Limits on Key Usage .......................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-84">84</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-6">6</a>. Alert Protocol .................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-85">85</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-6.1">6.1</a>. Closure Alerts ............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-87">87</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-6.2">6.2</a>. Error Alerts ..............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-88">88</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-7">7</a>. Cryptographic Computations .....................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-90">90</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-7.1">7.1</a>. Key Schedule ..............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-91">91</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-7.2">7.2</a>. Updating Traffic Secrets ..................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-94">94</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-7.3">7.3</a>. Traffic Key Calculation ...................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-95">95</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-7.4">7.4</a>. (EC)DHE Shared Secret Calculation .........................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-95">95</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-7.4.1">7.4.1</a>. Finite Field Diffie-Hellman ........................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-95">95</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-7.4.2">7.4.2</a>. Elliptic Curve Diffie-Hellman ......................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-96">96</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-7.5">7.5</a>. Exporters .................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-97">97</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-8">8</a>. 0-RTT and Anti-Replay ..........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-98">98</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-8.1">8.1</a>. Single-Use Tickets ........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-99">99</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-8.2">8.2</a>. Client Hello Recording ....................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-99">99</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-8.3">8.3</a>. Freshness Checks .........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-101">101</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-9">9</a>. Compliance Requirements .......................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-102">102</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-9.1">9.1</a>. Mandatory-to-Implement Cipher Suites .....................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-102">102</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-9.2">9.2</a>. Mandatory-to-Implement Extensions ........................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-103">103</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-9.3">9.3</a>. Protocol Invariants ......................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-104">104</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-10">10</a>. Security Considerations ......................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-106">106</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-11">11</a>. IANA Considerations ..........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-106">106</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-12">12</a>. References ...................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-109">109</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-12.1">12.1</a>. Normative References ....................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-109">109</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-12.2">12.2</a>. Informative References ..................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-112">112</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-A">Appendix A</a>. State Machine ........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-120">120</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-A.1">A.1</a>. Client ....................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-120">120</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-A.2">A.2</a>. Server ....................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-121">121</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-B">Appendix B</a>. Protocol Data Structures and Constant Values .........<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-122">122</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.1">B.1</a>. Record Layer ..............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-122">122</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.2">B.2</a>. Alert Messages ............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-123">123</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.3">B.3</a>. Handshake Protocol ........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-124">124</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.3.1">B.3.1</a>. Key Exchange Messages .................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-125">125</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.3.2">B.3.2</a>. Server Parameters Messages ............................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-131">131</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.3.3">B.3.3</a>. Authentication Messages ...............................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-132">132</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.3.4">B.3.4</a>. Ticket Establishment ..................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-132">132</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.3.5">B.3.5</a>. Updating Keys .........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-133">133</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.4">B.4</a>. Cipher Suites .............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-133">133</a>
<span class="grey">Rescorla Standards Track [Page 4]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-5"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-C">Appendix C</a>. Implementation Notes .................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-134">134</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-C.1">C.1</a>. Random Number Generation and Seeding ......................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-134">134</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-C.2">C.2</a>. Certificates and Authentication ...........................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-135">135</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-C.3">C.3</a>. Implementation Pitfalls ...................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-135">135</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-C.4">C.4</a>. Client Tracking Prevention ................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-137">137</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-C.5">C.5</a>. Unauthenticated Operation .................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-137">137</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-D">Appendix D</a>. Backward Compatibility ...............................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-138">138</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.1">D.1</a>. Negotiating with an Older Server ..........................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-139">139</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.2">D.2</a>. Negotiating with an Older Client ..........................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-139">139</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.3">D.3</a>. 0-RTT Backward Compatibility ..............................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-140">140</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4">D.4</a>. Middlebox Compatibility Mode ..............................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-140">140</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.5">D.5</a>. Security Restrictions Related to Backward Compatibility ...<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-141">141</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E">Appendix E</a>. Overview of Security Properties ......................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-142">142</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.1">E.1</a>. Handshake .................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-142">142</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.1.1">E.1.1</a>. Key Derivation and HKDF ...............................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-145">145</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.1.2">E.1.2</a>. Client Authentication .................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-146">146</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.1.3">E.1.3</a>. 0-RTT .................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-146">146</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.1.4">E.1.4</a>. Exporter Independence .................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-146">146</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.1.5">E.1.5</a>. Post-Compromise Security ..............................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-146">146</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.1.6">E.1.6</a>. External References ...................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-147">147</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.2">E.2</a>. Record Layer ..............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-147">147</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.2.1">E.2.1</a>. External References ...................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-148">148</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.3">E.3</a>. Traffic Analysis ..........................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-148">148</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.4">E.4</a>. Side-Channel Attacks ......................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-149">149</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.5">E.5</a>. Replay Attacks on 0-RTT ...................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-150">150</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.5.1">E.5.1</a>. Replay and Exporters ..................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-151">151</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.6">E.6</a>. PSK Identity Exposure .....................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-152">152</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.7">E.7</a>. Sharing PSKs ..............................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-152">152</a>
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.8">E.8</a>. Attacks on Static RSA .....................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-152">152</a>
Contributors .....................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-153">153</a>
Author's Address .................................................<a href="https://datatracker.ietf.org/doc/html/rfc8446#page-160">160</a>
<span class="grey">Rescorla Standards Track [Page 5]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-6"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
<span class="h2"><a class="selflink" id="section-1" href="https://datatracker.ietf.org/doc/html/rfc8446#section-1">1</a>. Introduction</span>
The primary goal of TLS is to provide a secure channel between two
communicating peers; the only requirement from the underlying
transport is a reliable, in-order data stream. Specifically, the
secure channel should provide the following properties:
- Authentication: The server side of the channel is always
authenticated; the client side is optionally authenticated.
Authentication can happen via asymmetric cryptography (e.g., RSA
[<a href="https://datatracker.ietf.org/doc/html/rfc8446#ref-RSA" title=""A Method for Obtaining Digital Signatures and Public-Key Cryptosystems"">RSA</a>], the Elliptic Curve Digital Signature Algorithm (ECDSA)
[<a href="https://datatracker.ietf.org/doc/html/rfc8446#ref-ECDSA" title=""Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)"">ECDSA</a>], or the Edwards-Curve Digital Signature Algorithm (EdDSA)
[<a href="https://datatracker.ietf.org/doc/html/rfc8032" title=""Edwards-Curve Digital Signature Algorithm (EdDSA)"">RFC8032</a>]) or a symmetric pre-shared key (PSK).
- Confidentiality: Data sent over the channel after establishment is
only visible to the endpoints. TLS does not hide the length of
the data it transmits, though endpoints are able to pad TLS
records in order to obscure lengths and improve protection against
traffic analysis techniques.
- Integrity: Data sent over the channel after establishment cannot
be modified by attackers without detection.
These properties should be true even in the face of an attacker who
has complete control of the network, as described in [<a href="https://datatracker.ietf.org/doc/html/rfc3552" title=""Guidelines for Writing RFC Text on Security Considerations"">RFC3552</a>]. See
<a href="https://datatracker.ietf.org/doc/html/rfc8446#appendix-E">Appendix E</a> for a more complete statement of the relevant security
properties.
TLS consists of two primary components:
- A handshake protocol (<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4">Section 4</a>) that authenticates the
communicating parties, negotiates cryptographic modes and
parameters, and establishes shared keying material. The handshake
protocol is designed to resist tampering; an active attacker
should not be able to force the peers to negotiate different
parameters than they would if the connection were not under
attack.
- A record protocol (<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-5">Section 5</a>) that uses the parameters established
by the handshake protocol to protect traffic between the
communicating peers. The record protocol divides traffic up into
a series of records, each of which is independently protected
using the traffic keys.
<span class="grey">Rescorla Standards Track [Page 6]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-7"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
TLS is application protocol independent; higher-level protocols can
layer on top of TLS transparently. The TLS standard, however, does
not specify how protocols add security with TLS; how to initiate TLS
handshaking and how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors
of protocols that run on top of TLS.
This document defines TLS version 1.3. While TLS 1.3 is not directly
compatible with previous versions, all versions of TLS incorporate a
versioning mechanism which allows clients and servers to
interoperably negotiate a common version if one is supported by both
peers.
This document supersedes and obsoletes previous versions of TLS,
including version 1.2 [<a href="https://datatracker.ietf.org/doc/html/rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>]. It also obsoletes the TLS ticket
mechanism defined in [<a href="https://datatracker.ietf.org/doc/html/rfc5077" title=""Transport Layer Security (TLS) Session Resumption without Server-Side State"">RFC5077</a>] and replaces it with the mechanism
defined in <a href="https://datatracker.ietf.org/doc/html/rfc8446#section-2.2">Section 2.2</a>. Because TLS 1.3 changes the way keys are
derived, it updates [<a href="https://datatracker.ietf.org/doc/html/rfc5705" title=""Keying Material Exporters for Transport Layer Security (TLS)"">RFC5705</a>] as described in <a href="https://datatracker.ietf.org/doc/html/rfc8446#section-7.5">Section 7.5</a>. It also
changes how Online Certificate Status Protocol (OCSP) messages are
carried and therefore updates [<a href="https://datatracker.ietf.org/doc/html/rfc6066" title=""Transport Layer Security (TLS) Extensions: Extension Definitions"">RFC6066</a>] and obsoletes [<a href="https://datatracker.ietf.org/doc/html/rfc6961" title=""The Transport Layer Security (TLS) Multiple Certificate Status Request Extension"">RFC6961</a>] as
described in <a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.1">Section 4.4.2.1</a>.
<span class="h3"><a class="selflink" id="section-1.1" href="https://datatracker.ietf.org/doc/html/rfc8446#section-1.1">1.1</a>. Conventions and Terminology</span>
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
<a href="https://datatracker.ietf.org/doc/html/bcp14">BCP 14</a> [<a href="https://datatracker.ietf.org/doc/html/rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="https://datatracker.ietf.org/doc/html/rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
The following terms are used:
client: The endpoint initiating the TLS connection.
connection: A transport-layer connection between two endpoints.
endpoint: Either the client or server of the connection.
handshake: An initial negotiation between client and server that
establishes the parameters of their subsequent interactions
within TLS.
peer: An endpoint. When discussing a particular endpoint, "peer"
refers to the endpoint that is not the primary subject of
discussion.
<span class="grey">Rescorla Standards Track [Page 7]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-8"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
receiver: An endpoint that is receiving records.
sender: An endpoint that is transmitting records.
server: The endpoint that did not initiate the TLS connection.
<span class="h3"><a class="selflink" id="section-1.2" href="https://datatracker.ietf.org/doc/html/rfc8446#section-1.2">1.2</a>. Major Differences from TLS 1.2</span>
The following is a list of the major functional differences between
TLS 1.2 and TLS 1.3. It is not intended to be exhaustive, and there
are many minor differences.
- The list of supported symmetric encryption algorithms has been
pruned of all algorithms that are considered legacy. Those that
remain are all Authenticated Encryption with Associated Data
(AEAD) algorithms. The cipher suite concept has been changed to
separate the authentication and key exchange mechanisms from the
record protection algorithm (including secret key length) and a
hash to be used with both the key derivation function and
handshake message authentication code (MAC).
- A zero round-trip time (0-RTT) mode was added, saving a round trip
at connection setup for some application data, at the cost of
certain security properties.
- Static RSA and Diffie-Hellman cipher suites have been removed; all
public-key based key exchange mechanisms now provide forward
secrecy.
- All handshake messages after the ServerHello are now encrypted.
The newly introduced EncryptedExtensions message allows various
extensions previously sent in the clear in the ServerHello to also
enjoy confidentiality protection.
- The key derivation functions have been redesigned. The new design
allows easier analysis by cryptographers due to their improved key
separation properties. The HMAC-based Extract-and-Expand Key
Derivation Function (HKDF) is used as an underlying primitive.
- The handshake state machine has been significantly restructured to
be more consistent and to remove superfluous messages such as
ChangeCipherSpec (except when needed for middlebox compatibility).
- Elliptic curve algorithms are now in the base spec, and new
signature algorithms, such as EdDSA, are included. TLS 1.3
removed point format negotiation in favor of a single point format
for each curve.
<span class="grey">Rescorla Standards Track [Page 8]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-9"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
- Other cryptographic improvements were made, including changing the
RSA padding to use the RSA Probabilistic Signature Scheme
(RSASSA-PSS), and the removal of compression, the Digital
Signature Algorithm (DSA), and custom Ephemeral Diffie-Hellman
(DHE) groups.
- The TLS 1.2 version negotiation mechanism has been deprecated in
favor of a version list in an extension. This increases
compatibility with existing servers that incorrectly implemented
version negotiation.
- Session resumption with and without server-side state as well as
the PSK-based cipher suites of earlier TLS versions have been
replaced by a single new PSK exchange.
- References have been updated to point to the updated versions of
RFCs, as appropriate (e.g., <a href="https://datatracker.ietf.org/doc/html/rfc5280">RFC 5280</a> rather than <a href="https://datatracker.ietf.org/doc/html/rfc3280">RFC 3280</a>).
<span class="h3"><a class="selflink" id="section-1.3" href="https://datatracker.ietf.org/doc/html/rfc8446#section-1.3">1.3</a>. Updates Affecting TLS 1.2</span>
This document defines several changes that optionally affect
implementations of TLS 1.2, including those which do not also support
TLS 1.3:
- A version downgrade protection mechanism is described in
<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3">Section 4.1.3</a>.
- RSASSA-PSS signature schemes are defined in <a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3">Section 4.2.3</a>.
- The "supported_versions" ClientHello extension can be used to
negotiate the version of TLS to use, in preference to the
legacy_version field of the ClientHello.
- The "signature_algorithms_cert" extension allows a client to
indicate which signature algorithms it can validate in X.509
certificates.
Additionally, this document clarifies some compliance requirements
for earlier versions of TLS; see <a href="https://datatracker.ietf.org/doc/html/rfc8446#section-9.3">Section 9.3</a>.
<span class="grey">Rescorla Standards Track [Page 9]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-10"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
<span class="h2"><a class="selflink" id="section-2" href="https://datatracker.ietf.org/doc/html/rfc8446#section-2">2</a>. Protocol Overview</span>
The cryptographic parameters used by the secure channel are produced
by the TLS handshake protocol. This sub-protocol of TLS is used by
the client and server when first communicating with each other. The
handshake protocol allows peers to negotiate a protocol version,
select cryptographic algorithms, optionally authenticate each other,
and establish shared secret keying material. Once the handshake is
complete, the peers use the established keys to protect the
application-layer traffic.
A failure of the handshake or other protocol error triggers the
termination of the connection, optionally preceded by an alert
message (<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-6">Section 6</a>).
TLS supports three basic key exchange modes:
- (EC)DHE (Diffie-Hellman over either finite fields or elliptic
curves)
- PSK-only
- PSK with (EC)DHE
<span class="grey">Rescorla Standards Track [Page 10]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-11"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
Figure 1 below shows the basic full TLS handshake:
Client Server
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* -------->
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the
previously noted message.
* Indicates optional or situation-dependent
messages/extensions that are not always sent.
{} Indicates messages protected using keys
derived from a [<a href="https://datatracker.ietf.org/doc/html/rfc8446#ref-sender">sender</a>]_handshake_traffic_secret.
[] Indicates messages protected using keys
derived from [<a href="https://datatracker.ietf.org/doc/html/rfc8446#ref-sender">sender</a>]_application_traffic_secret_N.
Figure 1: Message Flow for Full TLS Handshake
The handshake can be thought of as having three phases (indicated in
the diagram above):
- Key Exchange: Establish shared keying material and select the
cryptographic parameters. Everything after this phase is
encrypted.
- Server Parameters: Establish other handshake parameters
(whether the client is authenticated, application-layer protocol
support, etc.).
<span class="grey">Rescorla Standards Track [Page 11]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-12"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
- Authentication: Authenticate the server (and, optionally, the
client) and provide key confirmation and handshake integrity.
In the Key Exchange phase, the client sends the ClientHello
(<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.2">Section 4.1.2</a>) message, which contains a random nonce
(ClientHello.random); its offered protocol versions; a list of
symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key
shares (in the "key_share" (<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.8">Section 4.2.8</a>) extension), a set of
pre-shared key labels (in the "pre_shared_key" (<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.11">Section 4.2.11</a>)
extension), or both; and potentially additional extensions.
Additional fields and/or messages may also be present for middlebox
compatibility.
The server processes the ClientHello and determines the appropriate
cryptographic parameters for the connection. It then responds with
its own ServerHello (<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3">Section 4.1.3</a>), which indicates the negotiated
connection parameters. The combination of the ClientHello and the
ServerHello determines the shared keys. If (EC)DHE key establishment
is in use, then the ServerHello contains a "key_share" extension with
the server's ephemeral Diffie-Hellman share; the server's share MUST
be in the same group as one of the client's shares. If PSK key
establishment is in use, then the ServerHello contains a
"pre_shared_key" extension indicating which of the client's offered
PSKs was selected. Note that implementations can use (EC)DHE and PSK
together, in which case both extensions will be supplied.
The server then sends two messages to establish the Server
Parameters:
EncryptedExtensions: responses to ClientHello extensions that are
not required to determine the cryptographic parameters, other than
those that are specific to individual certificates.
[<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.1">Section 4.3.1</a>]
CertificateRequest: if certificate-based client authentication is
desired, the desired parameters for that certificate. This
message is omitted if client authentication is not desired.
[<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2">Section 4.3.2</a>]
<span class="grey">Rescorla Standards Track [Page 12]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-13"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
Finally, the client and server exchange Authentication messages. TLS
uses the same set of messages every time that certificate-based
authentication is needed. (PSK-based authentication happens as a
side effect of key exchange.) Specifically:
Certificate: The certificate of the endpoint and any per-certificate
extensions. This message is omitted by the server if not
authenticating with a certificate and by the client if the server
did not send CertificateRequest (thus indicating that the client
should not authenticate with a certificate). Note that if raw
public keys [<a href="https://datatracker.ietf.org/doc/html/rfc7250" title=""Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"">RFC7250</a>] or the cached information extension
[<a href="https://datatracker.ietf.org/doc/html/rfc7924" title=""Transport Layer Security (TLS) Cached Information Extension"">RFC7924</a>] are in use, then this message will not contain a
certificate but rather some other value corresponding to the
server's long-term key. [<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2">Section 4.4.2</a>]
CertificateVerify: A signature over the entire handshake using the
private key corresponding to the public key in the Certificate
message. This message is omitted if the endpoint is not
authenticating via a certificate. [<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.3">Section 4.4.3</a>]
Finished: A MAC (Message Authentication Code) over the entire
handshake. This message provides key confirmation, binds the
endpoint's identity to the exchanged keys, and in PSK mode also
authenticates the handshake. [<a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.4">Section 4.4.4</a>]
Upon receiving the server's messages, the client responds with its
Authentication messages, namely Certificate and CertificateVerify (if
requested), and Finished.
At this point, the handshake is complete, and the client and server
derive the keying material required by the record layer to exchange
application-layer data protected through authenticated encryption.
Application Data MUST NOT be sent prior to sending the Finished
message, except as specified in <a href="https://datatracker.ietf.org/doc/html/rfc8446#section-2.3">Section 2.3</a>. Note that while the
server may send Application Data prior to receiving the client's
Authentication messages, any data sent at that point is, of course,
being sent to an unauthenticated peer.
<span class="grey">Rescorla Standards Track [Page 13]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-14"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
<span class="h3"><a class="selflink" id="section-2.1" href="https://datatracker.ietf.org/doc/html/rfc8446#section-2.1">2.1</a>. Incorrect DHE Share</span>
If the client has not provided a sufficient "key_share" extension
(e.g., it includes only DHE or ECDHE groups unacceptable to or
unsupported by the server), the server corrects the mismatch with a
HelloRetryRequest and the client needs to restart the handshake with
an appropriate "key_share" extension, as shown in Figure 2. If no
common cryptographic parameters can be negotiated, the server MUST
abort the handshake with an appropriate alert.
Client Server
ClientHello
+ key_share -------->
HelloRetryRequest
<-------- + key_share
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 2: Message Flow for a Full Handshake with
Mismatched Parameters
Note: The handshake transcript incorporates the initial
ClientHello/HelloRetryRequest exchange; it is not reset with the
new ClientHello.
TLS also allows several optimized variants of the basic handshake, as
described in the following sections.
<span class="grey">Rescorla Standards Track [Page 14]</span></pre>
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-15"></span>
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a> TLS August 2018</span>
<span class="h3"><a class="selflink" id="section-2.2" href="https://datatracker.ietf.org/doc/html/rfc8446#section-2.2">2.2</a>. Resumption and Pre-Shared Key (PSK)</span>
Although TLS PSKs can be established out of band, PSKs can also be
established in a previous connection and then used to establish a new
connection ("session resumption" or "resuming" with a PSK). Once a
handshake has completed, the server can send the client a PSK
identity that corresponds to a unique key derived from the initial
handshake (see <a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.1">Section 4.6.1</a>). The client can then use that PSK
identity in future handshakes to negotiate the use of the associated
PSK. If the server accepts the PSK, then the security context of the
new connection is cryptographically tied to the original connection
and the key derived from the initial handshake is used to bootstrap
the cryptographic state instead of a full handshake. In TLS 1.2 and
below, this functionality was provided by "session IDs" and "session
tickets" [<a href="https://datatracker.ietf.org/doc/html/rfc5077" title=""Transport Layer Security (TLS) Session Resumption without Server-Side State"">RFC5077</a>]. Both mechanisms are obsoleted in TLS 1.3.
PSKs can be used with (EC)DHE key exchange in order to provide
forward secrecy in combination with shared keys, or can be used
alone, at the cost of losing forward secrecy for the application
data.