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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
|
<pre>Internet Engineering Task Force (IETF) J. Salowey
Request for Comments: 8447 Tableau Software
Updates: <a href="./rfc3749">3749</a>, <a href="./rfc5077">5077</a>, <a href="./rfc4680">4680</a>, <a href="./rfc5246">5246</a>, <a href="./rfc5705">5705</a>, S. Turner
<a href="./rfc5878">5878</a>, <a href="./rfc6520">6520</a>, <a href="./rfc7301">7301</a> sn3rd
Category: Standards Track August 2018
ISSN: 2070-1721
<span class="h1">IANA Registry Updates for TLS and DTLS</span>
Abstract
This document describes a number of changes to TLS and DTLS IANA
registries that range from adding notes to the registry all the way
to changing the registration policy. These changes were mostly
motivated by WG review of the TLS- and DTLS-related registries
undertaken as part of the TLS 1.3 development process.
This document updates the following RFCs: 3749, 5077, 4680, 5246,
5705, 5878, 6520, and 7301.
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="./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/rfc8447">https://www.rfc-editor.org/info/rfc8447</a>.
<span class="grey">Salowey & Turner Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS 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://www.rfc-editor.org/bcp/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.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Adding "TLS" to Registry Names . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. Aligning with <a href="./rfc8126">RFC 8126</a> . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5">5</a>. Adding "Recommended" Column . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-6">6</a>. Session Ticket TLS Extension . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-7">7</a>. TLS ExtensionType Values . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-8">8</a>. TLS Cipher Suites Registry . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-9">9</a>. TLS Supported Groups . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-10">10</a>. TLS ClientCertificateType Identifiers . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-11">11</a>. New Session Ticket TLS Handshake Message Type . . . . . . . . <a href="#page-12">12</a>
<a href="#section-12">12</a>. TLS Exporter Labels Registry . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-13">13</a>. Adding Missing Item to TLS Alerts Registry . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-14">14</a>. TLS Certificate Types . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-15">15</a>. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-16">16</a>. Additional Notes . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-17">17</a>. Designated Expert Pool . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-18">18</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-19">19</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-20">20</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-20.1">20.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-20.2">20.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<span class="grey">Salowey & Turner Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Per this document, IANA has made changes to a number of IANA
registries related to Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS). These changes were almost entirely
motivated by the development of TLS 1.3 [<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>].
The changes introduced by this document range from simple, e.g.,
adding notes, to complex, e.g., changing a registry's registration
policy. Instead of listing the changes and their rationale here in
the introduction, each section provides rationale for the proposed
change(s).
This document proposes no changes to the registration policies for
TLS Alerts [<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>], TLS ContentType [<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>], TLS HandshakeType
[<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>], and TLS Certificate Status Types [<a href="./rfc6961" title=""The Transport Layer Security (TLS) Multiple Certificate Status Request Extension"">RFC6961</a>] registries; the
existing policies (Standards Action for the first three; IETF Review
for the last), are appropriate for these one-byte code points because
of their scarcity.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. 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://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Adding "TLS" to Registry Names</span>
For consistency amongst TLS registries, IANA has prepended "TLS" to
the following registries:
o Application-Layer Protocol Negotiation (ALPN) Protocol IDs
[<a href="./rfc7301" title=""Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension"">RFC7301</a>],
o ExtensionType Values,
o Heartbeat Message Types [<a href="./rfc6520" title=""Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension"">RFC6520</a>], and
o Heartbeat Modes [<a href="./rfc6520" title=""Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension"">RFC6520</a>].
IANA has updated the reference for these four registries to also
refer to this document. The remainder of this document will use the
registry names with the "TLS" prefix.
<span class="grey">Salowey & Turner Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Aligning with <a href="./rfc8126">RFC 8126</a></span>
Many of the TLS-related IANA registries had the registration
procedure "IETF Consensus", which was changed to "IETF Review" by
[<a href="./rfc8126" title="">RFC8126</a>]. To align with the new terminology, IANA has updated the
following registries to "IETF Review":
o TLS Authorization Data Formats [<a href="./rfc4680" title=""TLS Handshake Message for Supplemental Data"">RFC4680</a>]
o TLS Supplemental Data Formats (SupplementalDataType) [<a href="./rfc5878" title=""Transport Layer Security (TLS) Authorization Extensions"">RFC5878</a>]
This is not a universal change, as some registries originally defined
with "IETF Consensus" are undergoing other changes either as a result
of this document, [<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>], or [<a href="./rfc8422" title=""Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier"">RFC8422</a>].
IANA has updated the reference for these two registries to also refer
to this document.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Adding "Recommended" Column</span>
Per this document, a "Recommended" column has been added to many of
the TLS registries to indicate parameters that are generally
recommended for implementations to support. Adding a "Recommended"
parameter (i.e., "Y") to a registry or updating a parameter to
"Recommended" status requires Standards Action. Not all parameters
defined in Standards Track documents need to be marked as
"Recommended".
If an item is not marked as "Recommended" (i.e., "N"), it does not
necessarily mean that it is flawed; rather, it indicates that the
item either has not been through the IETF consensus process, has
limited applicability, or is intended only for specific use cases.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Session Ticket TLS Extension</span>
The nomenclature for the registry entries in the TLS ExtensionType
Values registry correspond to the presentation language field name
except for entry 35. To ensure that the values in the registry are
consistently identified in the registry, IANA:
o has renamed entry 35 to "session_ticket (renamed from
"SessionTicket TLS")" [<a href="./rfc5077" title=""Transport Layer Security (TLS) Session Resumption without Server-Side State"">RFC5077</a>].
o has added a reference to this document in the "Reference" column
for entry 35.
<span class="grey">Salowey & Turner Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. TLS ExtensionType Values</span>
Experience has shown that the IETF Review registry policy for TLS
extensions was too strict. Based on WG consensus, the decision was
taken to change the registration policy to Specification Required
[<a href="./rfc8126" title="">RFC8126</a>] while reserving a small part of the code space for private
use. Therefore, IANA has updated the TLS ExtensionType Values
registry as follows:
o Changed the registry policy to:
Values with the first byte in the range 0-254 (decimal) are
assigned via Specification Required [<a href="./rfc8126" title="">RFC8126</a>]. Values with the
first byte 255 (decimal) are reserved for Private Use [<a href="./rfc8126" title="">RFC8126</a>].
o Updated the "Reference" to also refer to this document.
See <a href="#section-17">Section 17</a> for additional information about the designated expert
pool.
Despite wanting to "loosen" the registration policies for TLS
extensions, it is still useful to indicate in the IANA registry which
extensions the WG recommends be supported. Therefore, IANA has
updated the TLS ExtensionType Values registry as follows:
o Added a "Recommended" column with the contents as listed below.
This table has been generated by marking Standards Track RFCs as
"Y" and all others as "N". The "Recommended" column is assigned a
value of "N" unless explicitly requested, and adding a value with
a "Recommended" value of "Y" requires Standards Action [<a href="./rfc8126" title="">RFC8126</a>].
IESG Approval is REQUIRED for a Y->N transition.
+----------------------------------------+-------------+
| Extension | Recommended |
+----------------------------------------+-------------+
| server_name | Y |
| | |
| max_fragment_length | N |
| | |
| client_certificate_url | Y |
| | |
| trusted_ca_keys | Y |
| | |
| truncated_hmac | Y |
| | |
| status_request | Y |
| | |
| user_mapping | Y |
<span class="grey">Salowey & Turner Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
+----------------------------------------+-------------+
| Extension | Recommended |
+----------------------------------------+-------------+
| client_authz | N |
| | |
| server_authz | N |
| | |
| cert_type | N |
| | |
| supported_groups | Y |
| | |
| ec_point_formats | Y |
| | |
| srp | N |
| | |
| signature_algorithms | Y |
| | |
| use_srtp | Y |
| | |
| heartbeat | Y |
| | |
| application_layer_protocol_negotiation | Y |
| | |
| status_request_v2 | Y |
| | |
| signed_certificate_timestamp | N |
| | |
| client_certificate_type | Y |
| | |
| server_certificate_type | Y |
| | |
| padding | Y |
| | |
| encrypt_then_mac | Y |
| | |
| extended_master_secret | Y |
| | |
| cached_info | Y |
| | |
| session_ticket | Y |
| | |
| renegotiation_info | Y |
+----------------------------------------+-------------+
<span class="grey">Salowey & Turner Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
IANA has added the following notes:
Note: The role of the designated expert is described in <a href="./rfc8447">RFC 8447</a>.
The designated expert [<a href="./rfc8126" title="">RFC8126</a>] ensures that the specification is
publicly available. It is sufficient to have an Internet-Draft
(that is posted and never published as an RFC) or a document from
another standards body, industry consortium, university site, etc.
The expert may provide more in-depth reviews, but their approval
should not be taken as an endorsement of the extension.
Note: As specified in [<a href="./rfc8126" title="">RFC8126</a>], assignments made in the Private Use
space are not generally useful for broad interoperability. It is
the responsibility of those making use of the Private Use range to
ensure that no conflicts occur (within the intended scope of use).
For widespread experiments, temporary reservations are available.
Note: If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that the
item either has not been through the IETF consensus process, has
limited applicability, or is intended only for specific use cases.
The extensions added by [<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>] are omitted from the above table;
additionally, token_binding is omitted, since [<a href="#ref-TOKBIND" title=""Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation"">TOKBIND</a>] specifies the
value of the "Recommended" column for this extension.
[<a id="ref-RFC8446">RFC8446</a>] also uses the TLS ExtensionType Values registry originally
created in [<a href="./rfc4366" title=""Transport Layer Security (TLS) Extensions"">RFC4366</a>]. The following text is from [<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>] and is
included here to ensure alignment between these specifications.
o IANA has updated this registry to include the "key_share",
"pre_shared_key", "psk_key_exchange_modes", "early_data",
"cookie", "supported_versions", "certificate_authorities",
"oid_filters", "post_handshake_auth", and
"signature_algorithms_cert" extensions with the values defined in
[<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>] and the "Recommended" value of "Y".
o IANA has updated this registry to include a "TLS 1.3" column that
lists the messages in which the extension may appear. This column
has been initially populated from the table in <a href="./rfc8446#section-4.2">Section 4.2 of
[RFC8446]</a> with any extension not listed there marked as "-" to
indicate that it is not used by TLS 1.3.
<span class="grey">Salowey & Turner Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. TLS Cipher Suites Registry</span>
Experience has shown that the IETF Consensus registry policy for TLS
Cipher Suites was too strict. Based on WG consensus, the decision
was taken to change the TLS Cipher Suites registry's registration
policy to Specification Required [<a href="./rfc8126" title="">RFC8126</a>] while reserving a small
part of the code space for private use. Therefore, IANA has updated
the TLS Cipher Suites registry's policy as follows:
Values with the first byte in the range 0-254 (decimal) are
assigned via Specification Required [<a href="./rfc8126" title="">RFC8126</a>]. Values with the
first byte 255 (decimal) are reserved for Private Use [<a href="./rfc8126" title="">RFC8126</a>].
See <a href="#section-17">Section 17</a> for additional information about the designated expert
pool.
The TLS Cipher Suites registry has grown significantly and will
continue to do so. To better guide those not intimately involved in
TLS, IANA has updated the TLS Cipher Suites registry as follows:
o Added a "Recommended" column to the TLS Cipher Suites registry.
The cipher suites that follow in the two tables are marked as "Y".
All other cipher suites are marked as "N". The "Recommended"
column is assigned a value of "N" unless explicitly requested, and
adding a value with a "Recommended" value of "Y" requires
Standards Action [<a href="./rfc8126" title="">RFC8126</a>]. IESG Approval is REQUIRED for a Y->N
transition.
The cipher suites that follow are Standards Track server-
authenticated (and optionally client-authenticated) cipher suites
that are currently available in TLS 1.2.
Cipher Suite Name | Value
----------------------------------------------+------------
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | {0x00,0x9E}
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | {0x00,0x9F}
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2B}
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x2C}
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2F}
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x30}
TLS_DHE_RSA_WITH_AES_128_CCM | {0xC0,0x9E}
TLS_DHE_RSA_WITH_AES_256_CCM | {0xC0,0x9F}
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA8}
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA9}
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAA}
<span class="grey">Salowey & Turner Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
The cipher suites that follow are Standards Track ephemeral pre-
shared key cipher suites that are available in TLS 1.2.
Cipher Suite Name | Value
----------------------------------------------+------------
TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | {0x00,0xAA}
TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | {0x00,0xAB}
TLS_DHE_PSK_WITH_AES_128_CCM | {0xC0,0xA6}
TLS_DHE_PSK_WITH_AES_256_CCM | {0xC0,0xA7}
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | {0xD0,0x01}
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | {0xD0,0x02}
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | {0xD0,0x05}
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAC}
TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAD}
The TLS 1.3 cipher suites specified by [<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>] are not listed here;
that document provides for their "Recommended" status.
Despite the following behavior being misguided, experience has shown
that some customers use the IANA registry as a checklist against
which to measure an implementation's completeness, and some
implementers blindly implement cipher suites. Therefore, IANA has
added the following warning to the registry:
WARNING: Cryptographic algorithms and parameters will be broken or
weakened over time. Blindly implementing cipher suites listed
here is not advised. Implementers and users need to check that
the cryptographic algorithms listed continue to provide the
expected level of security.
IANA has added the following note to ensure that those that focus on
IANA registries are aware that TLS 1.3 [<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>] uses the same
registry but defines ciphers differently:
Note: Although TLS 1.3 uses the same cipher suite space as previous
versions of TLS, TLS 1.3 cipher suites are defined differently,
only specifying the symmetric ciphers and hash function, and
cannot be used for TLS 1.2. Similarly, TLS 1.2 and lower cipher
suite values cannot be used with TLS 1.3.
IANA has added the following notes to document the rules for
populating the "Recommended" column:
Note: CCM_8 cipher suites are not marked as "Recommended". These
cipher suites have a significantly truncated authentication tag
that represents a security trade-off that may not be appropriate
for general environments.
<span class="grey">Salowey & Turner Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
Note: If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that the
item either has not been through the IETF consensus process, has
limited applicability, or is intended only for specific use cases.
IANA has added the following notes for additional information:
Note: The role of the designated expert is described in <a href="./rfc8447">RFC 8447</a>.
The designated expert [<a href="./rfc8126" title="">RFC8126</a>] ensures that the specification is
publicly available. It is sufficient to have an Internet-Draft
(that is posted and never published as an RFC) or a document from
another standards body, industry consortium, university site, etc.
The expert may provide more in-depth reviews, but their approval
should not be taken as an endorsement of the cipher suite.
Note: As specified in [<a href="./rfc8126" title="">RFC8126</a>], assignments made in the Private Use
space are not generally useful for broad interoperability. It is
the responsibility of those making use of the Private Use range to
ensure that no conflicts occur (within the intended scope of use).
For widespread experiments, temporary reservations are available.
IANA has updated the reference for this registry to also refer to
this document.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. TLS Supported Groups</span>
Similar to cipher suites, supported groups have proliferated over
time, and some use the registry to measure implementations.
Therefore, IANA has added a "Recommended" column with a "Y" for
secp256r1, secp384r1, x25519, and x448, while all others are "N".
These "Y" groups are taken from Standards Track RFCs; [<a href="./rfc8422" title=""Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier"">RFC8422</a>]
elevates secp256r1 and secp384r1 to Standards Track. Not all groups
from [<a href="./rfc8422" title=""Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier"">RFC8422</a>], which is Standards Track, are marked as "Y"; these
groups apply to TLS 1.3 [<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>] and previous versions of TLS. The
"Recommended" column is assigned a value of "N" unless explicitly
requested, and adding a value with a "Recommended" value of "Y"
requires Standards Action [<a href="./rfc8126" title="">RFC8126</a>]. IESG Approval is REQUIRED for a
Y->N transition.
IANA has added the following notes:
Note: If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that the
item either has not been through the IETF consensus process, has
limited applicability, or is intended only for specific use cases.
<span class="grey">Salowey & Turner Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
Note: The role of the designated expert is described in <a href="./rfc8447">RFC 8447</a>.
The designated expert [<a href="./rfc8126" title="">RFC8126</a>] ensures that the specification is
publicly available. It is sufficient to have an Internet-Draft
(that is posted and never published as an RFC) or a document from
another standards body, industry consortium, university site, etc.
The expert may provide more in-depth reviews, but their approval
should not be taken as an endorsement of the supported group.
Despite the following behavior being misguided, experience has shown
that some customers use the IANA registry as a checklist against
which to measure an implementation's completeness, and some
implementers blindly implement supported groups. Therefore, IANA has
added the following warning to the registry:
WARNING: Cryptographic algorithms and parameters will be broken or
weakened over time. Blindly implementing supported groups listed
here is not advised. Implementers and users need to check that
the cryptographic algorithms listed continue to provide the
expected level of security.
IANA has updated the reference for this registry to also refer to
this document.
The value 0 (0x0000) has been marked as reserved.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. TLS ClientCertificateType Identifiers</span>
Experience has shown that the IETF Consensus registry policy for TLS
ClientCertificateType Identifiers is too strict. Based on WG
consensus, the decision was taken to change the registration policy
to Specification Required [<a href="./rfc8126" title="">RFC8126</a>] while reserving some of the code
space for Standards Track usage and a small part of the code space
for private use. Therefore, IANA has updated the TLS
ClientCertificateType Identifiers registry's policy as follows:
Values in the range 0-63 are assigned via Standards Action.
Values 64-223 are assigned via Specification Required [<a href="./rfc8126" title="">RFC8126</a>].
Values 224-255 are reserved for Private Use.
See <a href="#section-17">Section 17</a> for additional information about the designated expert
pool.
<span class="grey">Salowey & Turner Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
IANA has added the following notes:
Note: The role of the designated expert is described in <a href="./rfc8447">RFC 8447</a>.
The designated expert [<a href="./rfc8126" title="">RFC8126</a>] ensures that the specification is
publicly available. It is sufficient to have an Internet-Draft
(that is posted and never published as an RFC) or a document from
another standards body, industry consortium, university site, etc.
The expert may provide more in-depth reviews, but their approval
should not be taken as an endorsement of the identifier.
Note: As specified in [<a href="./rfc8126" title="">RFC8126</a>], assignments made in the Private Use
space are not generally useful for broad interoperability. It is
the responsibility of those making use of the Private Use range to
ensure that no conflicts occur (within the intended scope of use).
For widespread experiments, temporary reservations are available.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. New Session Ticket TLS Handshake Message Type</span>
To align with TLS implementations and to align the naming
nomenclature with other Handshake message types, IANA:
o has renamed entry 4 in the TLS HandshakeType registry to
"new_session_ticket (renamed from NewSessionTicket)" [<a href="./rfc5077" title=""Transport Layer Security (TLS) Session Resumption without Server-Side State"">RFC5077</a>].
o has added a reference to this document in the "Reference" column
for entry 4 in the TLS HandshakeType registry.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. TLS Exporter Labels Registry</span>
To aid those reviewers who start with the IANA registry, IANA has
added:
o The following note to the TLS Exporter Labels registry:
Note: [<a href="./rfc5705" title=""Keying Material Exporters for Transport Layer Security (TLS)"">RFC5705</a>] defines keying material exporters for TLS in terms
of the TLS PRF. [<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>] replaced the PRF with HKDF, thus
requiring a new construction. The exporter interface remains the
same; however, the value is computed differently.
o A "Recommended" column to the TLS Exporter Labels registry. The
table that follows has been generated by marking Standards Track
RFCs as "Y" and all others as "N". The "Recommended" column is
assigned a value of "N" unless explicitly requested, and adding a
value with a "Recommended" value of "Y" requires Standards Action
[<a href="./rfc8126" title="">RFC8126</a>]. IESG Approval is REQUIRED for a Y->N transition.
<span class="grey">Salowey & Turner Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
Exporter Value | Recommended |
--------------------------------|-------------|
client finished | Y |
server finished | Y |
master secret | Y |
key expansion | Y |
client EAP encryption | Y |
ttls keying material | N |
ttls challenge | N |
EXTRACTOR-dtls_srtp | Y |
EXPORTER_DTLS_OVER_SCTP | Y |
EXPORTER: teap session key seed | Y |
To provide additional information for the designated experts, IANA
has added the following notes:
Note: The role of the designated expert is described in <a href="./rfc8447">RFC 8447</a>.
The designated expert [<a href="./rfc8126" title="">RFC8126</a>] ensures that the specification is
publicly available. It is sufficient to have an Internet-Draft
(that is posted and never published as an RFC) or a document from
another standards body, industry consortium, university site, etc.
The expert may provide more in-depth reviews, but their approval
should not be taken as an endorsement of the exporter label. The
expert also verifies that the label is a string consisting of
printable ASCII characters beginning with "EXPORTER". IANA MUST
also verify that one label is not a prefix of any other label.
For example, labels "key" or "master secretary" are forbidden.
Note: If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that the
item either has not been through the IETF consensus process, has
limited applicability, or is intended only for specific use cases.
IANA has updated the reference for this registry to also refer to
this document.
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Adding Missing Item to TLS Alerts Registry</span>
IANA has added the following entry to the TLS Alerts registry; the
entry was omitted from the IANA instructions in [<a href="./rfc7301" title=""Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension"">RFC7301</a>]:
120 no_application_protocol Y [<a href="./rfc7301" title=""Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension"">RFC7301</a>] [<a href="./rfc8447">RFC8447</a>]
<span class="grey">Salowey & Turner Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>. TLS Certificate Types</span>
Experience has shown that the IETF Consensus registry policy for TLS
Certificate Types is too strict. Based on WG consensus, the decision
was taken to change registration policy to Specification Required
[<a href="./rfc8126" title="">RFC8126</a>] while reserving a small part of the code space for private
use. Therefore, IANA has changed the TLS Certificate Types registry
as follows:
o Changed the registry policy to:
Values in the range 0-223 (decimal) are assigned via Specification
Required [<a href="./rfc8126" title="">RFC8126</a>]. Values in the range 224-255 (decimal) are
reserved for Private Use [<a href="./rfc8126" title="">RFC8126</a>].
o Added a "Recommended" column to the registry. X.509 and Raw
Public Key are "Y". All others are "N". The "Recommended" column
is assigned a value of "N" unless explicitly requested, and adding
a value with a "Recommended" value of "Y" requires Standards
Action [<a href="./rfc8126" title="">RFC8126</a>]. IESG Approval is REQUIRED for a Y->N
transition.
See <a href="#section-17">Section 17</a> for additional information about the designated expert
pool.
IANA has added the following notes:
Note: The role of the designated expert is described in <a href="./rfc8447">RFC 8447</a>.
The designated expert [<a href="./rfc8126" title="">RFC8126</a>] ensures that the specification is
publicly available. It is sufficient to have an Internet-Draft
(that is posted and never published as an RFC) or a document from
another standards body, industry consortium, university site, etc.
The expert may provide more in-depth reviews, but their approval
should not be taken as an endorsement of the certificate type.
Note: If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that the
item either has not been through the IETF consensus process, has
limited applicability, or is intended only for specific use cases.
IANA has updated the reference for this registry to also refer this
document.
<span class="grey">Salowey & Turner Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
<span class="h2"><a class="selflink" id="section-15" href="#section-15">15</a>. Orphaned Registries</span>
To make it clear that (D)TLS 1.3 has orphaned certain registries
(i.e., they are only applicable to version of (D)TLS protocol
versions prior to 1.3), IANA:
o has added the following to the TLS Compression Method Identifiers
registry [<a href="./rfc3749" title=""Transport Layer Security Protocol Compression Methods"">RFC3749</a>]:
Note: Value 0 (NULL) is the only value in this registry applicable
to (D)TLS protocol version 1.3 or later.
o has added the following to the TLS HashAlgorithm [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] and TLS
SignatureAlgorithm registries [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>]:
Note: The values in this registry are only applicable to (D)TLS
protocol versions prior to 1.3. (D)TLS 1.3 and later versions'
values are registered in the TLS SignatureScheme registry.
o has updated the "Reference" field in the TLS Compression Method
Identifiers, TLS HashAlgorithm and TLS SignatureAlgorithm
registries to also refer to this document.
o has updated the TLS HashAlgorithm registry to list values 7 and
9-223 as "Reserved" and the TLS SignatureAlgorithm registry to
list values 4-6 and 9-223 as "Reserved".
o has added the following to the TLS ClientCertificateType
Identifiers registry [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>]:
Note: The values in this registry are only applicable to (D)TLS
protocol versions prior to 1.3.
Despite the fact that the TLS HashAlgorithm and SignatureAlgorithm
registries are orphaned, it is still important to warn implementers
of pre-TLS1.3 implementations about the dangers of blindly
implementing cryptographic algorithms. Therefore, IANA has added the
following warning to the TLS HashAlgorithm and SignatureAlgorithm
registries:
WARNING: Cryptographic algorithms and parameters will be broken or
weakened over time. Blindly implementing the cryptographic
algorithms listed here is not advised. Implementers and users
need to check that the cryptographic algorithms listed continue to
provide the expected level of security.
<span class="grey">Salowey & Turner Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
<span class="h2"><a class="selflink" id="section-16" href="#section-16">16</a>. Additional Notes</span>
IANA has added the following warning and note to the TLS
SignatureScheme registry:
WARNING: Cryptographic algorithms and parameters will be broken or
weakened over time. Blindly implementing signature schemes listed
here is not advised. Implementers and users need to check that
the cryptographic algorithms listed continue to provide the
expected level of security.
Note: As specified in [<a href="./rfc8126" title="">RFC8126</a>], assignments made in the Private Use
space are not generally useful for broad interoperability. It is
the responsibility of those making use of the Private Use range to
ensure that no conflicts occur (within the intended scope of use).
For widespread experiments, temporary reservations are available.
IANA has added the following notes to the TLS PskKeyExchangeMode
registry:
Note: If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that the
item either has not been through the IETF consensus process, has
limited applicability, or is intended only for specific use cases.
Note: The role of the designated expert is described in <a href="./rfc8447">RFC 8447</a>.
The designated expert [<a href="./rfc8126" title="">RFC8126</a>] ensures that the specification is
publicly available. It is sufficient to have an Internet-Draft
(that is posted and never published as an RFC) or a document from
another standards body, industry consortium, university site, etc.
The expert may provide more in depth reviews, but their approval
should not be taken as an endorsement of the key exchange mode.
<span class="h2"><a class="selflink" id="section-17" href="#section-17">17</a>. Designated Expert Pool</span>
Specification Required [<a href="./rfc8126" title="">RFC8126</a>] registry requests are registered
after a three-week review period on the <tls-reg-review@ietf.org>
mailing list, on the advice of one or more designated experts.
However, to allow for the allocation of values prior to publication,
the designated experts may approve registration once they are
satisfied that such a specification will be published.
Registration requests sent to the mailing list for review SHOULD use
an appropriate subject (e.g., "Request to register value in TLS bar
registry").
<span class="grey">Salowey & Turner Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
Within the review period, the designated experts will either approve
or deny the registration request, communicating this decision to the
review list and IANA. Denials SHOULD include an explanation and, if
applicable, suggestions as to how to make the request successful.
Registration requests that are undetermined for a period longer than
21 days can be brought to the IESG's attention (using the
<iesg@ietf.org> mailing list) for resolution.
Criteria that SHOULD be applied by the designated experts includes
determining whether the proposed registration duplicates existing
functionality, whether it is likely to be of general applicability or
useful only for a single application, and whether the registration
description is clear.
IANA MUST only accept registry updates from the designated experts
and SHOULD direct all requests for registration to the review mailing
list.
It is suggested that multiple designated experts be appointed who are
able to represent the perspectives of different applications using
this specification, in order to enable broadly informed review of
registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular
Expert, that Expert SHOULD defer to the judgment of the other
Experts.
<span class="h2"><a class="selflink" id="section-18" href="#section-18">18</a>. Security Considerations</span>
The change to Specification Required from IETF Review lowers the
amount of review provided by the WG for cipher suites and supported
groups. This change reflects reality in that the WG essentially
provided no cryptographic review of the cipher suites or supported
groups. This was especially true of national cipher suites.
Recommended algorithms are regarded as secure for general use at the
time of registration; however, cryptographic algorithms and
parameters will be broken or weakened over time. It is possible that
the "Recommended" status in the registry lags behind the most recent
advances in cryptanalysis. Implementers and users need to check that
the cryptographic algorithms listed continue to provide the expected
level of security.
Designated experts ensure the specification is publicly available.
They may provide more in-depth reviews. Their review should not be
taken as an endorsement of the cipher suite, extension, supported
group, etc.
<span class="grey">Salowey & Turner Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
<span class="h2"><a class="selflink" id="section-19" href="#section-19">19</a>. IANA Considerations</span>
This document is entirely about changes to TLS-related IANA
registries.
<span class="h2"><a class="selflink" id="section-20" href="#section-20">20</a>. References</span>
<span class="h3"><a class="selflink" id="section-20.1" href="#section-20.1">20.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3749">RFC3749</a>] Hollenbeck, S., "Transport Layer Security Protocol
Compression Methods", <a href="./rfc3749">RFC 3749</a>, DOI 10.17487/RFC3749, May
2004, <<a href="https://www.rfc-editor.org/info/rfc3749">https://www.rfc-editor.org/info/rfc3749</a>>.
[<a id="ref-RFC4680">RFC4680</a>] Santesson, S., "TLS Handshake Message for Supplemental
Data", <a href="./rfc4680">RFC 4680</a>, DOI 10.17487/RFC4680, October 2006,
<<a href="https://www.rfc-editor.org/info/rfc4680">https://www.rfc-editor.org/info/rfc4680</a>>.
[<a id="ref-RFC5077">RFC5077</a>] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", <a href="./rfc5077">RFC 5077</a>, DOI 10.17487/RFC5077,
January 2008, <<a href="https://www.rfc-editor.org/info/rfc5077">https://www.rfc-editor.org/info/rfc5077</a>>.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>,
DOI 10.17487/RFC5246, August 2008,
<<a href="https://www.rfc-editor.org/info/rfc5246">https://www.rfc-editor.org/info/rfc5246</a>>.
[<a id="ref-RFC5705">RFC5705</a>] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", <a href="./rfc5705">RFC 5705</a>, DOI 10.17487/RFC5705,
March 2010, <<a href="https://www.rfc-editor.org/info/rfc5705">https://www.rfc-editor.org/info/rfc5705</a>>.
[<a id="ref-RFC5878">RFC5878</a>] Brown, M. and R. Housley, "Transport Layer Security (TLS)
Authorization Extensions", <a href="./rfc5878">RFC 5878</a>, DOI 10.17487/RFC5878,
May 2010, <<a href="https://www.rfc-editor.org/info/rfc5878">https://www.rfc-editor.org/info/rfc5878</a>>.
[<a id="ref-RFC6520">RFC6520</a>] Seggelmann, R., Tuexen, M., and M. Williams, "Transport
Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) Heartbeat Extension", <a href="./rfc6520">RFC 6520</a>,
DOI 10.17487/RFC6520, February 2012,
<<a href="https://www.rfc-editor.org/info/rfc6520">https://www.rfc-editor.org/info/rfc6520</a>>.
<span class="grey">Salowey & Turner Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
[<a id="ref-RFC7301">RFC7301</a>] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", <a href="./rfc7301">RFC 7301</a>, DOI 10.17487/RFC7301,
July 2014, <<a href="https://www.rfc-editor.org/info/rfc7301">https://www.rfc-editor.org/info/rfc7301</a>>.
[<a id="ref-RFC8126">RFC8126</a>] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>,
<a href="./rfc8126">RFC 8126</a>, DOI 10.17487/RFC8126, June 2017,
<<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
[<a id="ref-RFC8446">RFC8446</a>] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", <a href="./rfc8446">RFC 8446</a>, DOI 10.17487/RFC8446, August 2018,
<<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>>.
<span class="h3"><a class="selflink" id="section-20.2" href="#section-20.2">20.2</a>. Informative References</span>
[<a id="ref-RFC4366">RFC4366</a>] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", <a href="./rfc4366">RFC 4366</a>, DOI 10.17487/RFC4366, April 2006,
<<a href="https://www.rfc-editor.org/info/rfc4366">https://www.rfc-editor.org/info/rfc4366</a>>.
[<a id="ref-RFC6961">RFC6961</a>] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", <a href="./rfc6961">RFC 6961</a>,
DOI 10.17487/RFC6961, June 2013,
<<a href="https://www.rfc-editor.org/info/rfc6961">https://www.rfc-editor.org/info/rfc6961</a>>.
[<a id="ref-RFC8422">RFC8422</a>] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", <a href="./rfc8422">RFC 8422</a>,
DOI 10.17487/RFC8422, August 2018,
<<a href="https://www.rfc-editor.org/info/rfc8422">https://www.rfc-editor.org/info/rfc8422</a>>.
[<a id="ref-TOKBIND">TOKBIND</a>] Popov, A., Nystrom, M., Balfanz, D., and A. Langley,
"Transport Layer Security (TLS) Extension for Token
Binding Protocol Negotiation", Work in Progress,
<a href="./draft-ietf-tokbind-negotiation-14">draft-ietf-tokbind-negotiation-14</a>, May 2018.
<span class="grey">Salowey & Turner Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8447">RFC 8447</a> IANA Registry Updates for TLS and DTLS August 2018</span>
Authors' Addresses
Joe Salowey
Tableau Software
Email: joe@salowey.net
Sean Turner
sn3rd
Email: sean@sn3rd.com
Salowey & Turner Standards Track [Page 20]
</pre>
|
