idnits 2.17.1 draft-ietf-tls-rfc8447bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5705, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5077, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3749, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5878, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4680, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3749, updated by this document, for RFC5378 checks: 2002-09-05) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (29 March 2022) is 753 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Experimental RFC: RFC 5878 -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS WG J. Salowey 3 Internet-Draft Salesforce 4 Obsoletes: 8447 (if approved) S. Turner 5 Updates: 3749, 5077, 4680, 5246, 5705, 5878, sn3rd 6 6520, 7301 (if approved) 29 March 2022 7 Intended status: Standards Track 8 Expires: 30 September 2022 10 IANA Registry Updates for TLS and DTLS 11 draft-ietf-tls-rfc8447bis-00 13 Abstract 15 This document describes a number of changes to TLS and DTLS IANA 16 registries that range from adding notes to the registry all the way 17 to changing the registration policy. These changes were mostly 18 motivated by WG review of the TLS- and DTLS-related registries 19 undertaken as part of the TLS 1.3 development process. 21 This document obsoletes RFC8447 and updates the following RFCs: 3749, 22 5077, 4680, 5246, 5705, 5878, 6520, 7301. 24 About This Document 26 This note is to be removed before publishing as an RFC. 28 Status information for this document may be found at 29 https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/. 31 Discussion of this document takes place on the Transport Layer 32 Security (TLS) Working Group mailing list (mailto:tls@ietf.org), 33 which is archived at https://mailarchive.ietf.org/arch/browse/lamps/. 35 Source for this draft and an issue tracker can be found at 36 https://github.com/tlswg/rfc8447bis. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 30 September 2022. 55 Copyright Notice 57 Copyright (c) 2022 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Revised BSD License text as 66 described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Revised BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Adding "TLS" to Registry Names . . . . . . . . . . . . . . . 3 74 4. Aligning with RFC 8126 . . . . . . . . . . . . . . . . . . . 4 75 5. Adding "Recommended" Column . . . . . . . . . . . . . . . . . 4 76 6. Session Ticket TLS Extension . . . . . . . . . . . . . . . . 5 77 7. TLS ExtensionType Values . . . . . . . . . . . . . . . . . . 5 78 8. TLS Cipher Suites Registry . . . . . . . . . . . . . . . . . 8 79 9. TLS Supported Groups . . . . . . . . . . . . . . . . . . . . 11 80 10. TLS ClientCertificateType Identifiers . . . . . . . . . . . . 12 81 11. New Session Ticket TLS Handshake Message Type . . . . . . . . 12 82 12. TLS Exporter Labels Registry . . . . . . . . . . . . . . . . 13 83 13. Adding Missing Item to TLS Alerts Registry . . . . . . . . . 14 84 14. TLS Certificate Types . . . . . . . . . . . . . . . . . . . . 14 85 15. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . 15 86 16. Additional Notes . . . . . . . . . . . . . . . . . . . . . . 16 87 17. Designated Expert Pool . . . . . . . . . . . . . . . . . . . 17 88 18. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 20.1. Normative References . . . . . . . . . . . . . . . . . . 18 92 20.2. Informative References . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 95 1. Introduction 97 This document instructs IANA to make changes to a number of the IANA 98 registries related to Transport Layer Security (TLS) and Datagram 99 Transport Layer Security (DTLS). These changes were almost entirely 100 motivated by the development of TLS 1.3 [I-D.ietf-tls-tls13]. 102 The changes introduced by this document range from simple, e.g., 103 adding notes, to complex, e.g., changing a registry's registration 104 policy. Instead of listing the changes and their rationale here in 105 the introduction, each section provides rationale for the proposed 106 change(s). 108 This document proposes no changes to the registration policies for 109 TLS Alerts [RFC8446], TLS ContentType [RFC8446], TLS HandshakeType 110 [RFC8446], and TLS Certificate Status Types [RFC6961] registries; the 111 existing policies (Standards Action for the first three; IETF Review 112 for the last), are appropriate for these one-byte code points because 113 of their scarcity. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in 120 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 3. Adding "TLS" to Registry Names 125 For consistency amongst TLS registries, IANA [SHALL prepend/has 126 prepended] "TLS" to the following registries: 128 * Application-Layer Protocol Negotiation (ALPN) Protocol IDs 129 [RFC7301], 131 * ExtensionType Values, 133 * Heartbeat Message Types [RFC6520], and 135 * Heartbeat Modes [RFC6520]. 137 IANA [SHALL update/has updated] the reference for these four 138 registries to also refer to this document. The remainder of this 139 document will use the registry names with the "TLS" prefix. 141 4. Aligning with RFC 8126 143 Many of the TLS-related IANA registries had the registration 144 procedure "IETF Consensus", which was changed to "IETF Review" by 145 [RFC8126]. To align with the new terminology, IANA [SHALL update/has 146 updated] the following registries to "IETF Review": 148 * TLS Authorization Data Formats [RFC4680] 150 * TLS Supplemental Data Formats (SupplementalDataType) [RFC5878] 152 This is not a universal change, as some registries originally defined 153 with "IETF Consensus" are undergoing other changes either as a result 154 of this document or [RFC8422]. 156 IANA [SHALL update/has updated] the reference for these two 157 registries to also refer to this document. 159 5. Adding "Recommended" Column 161 The instructions in this document update the Recommended column, 162 originally added in [RFC8447] to add a third value, "D", indicating 163 that a value is "Discouraged". The permitted values are: 165 * Y: Indicates that the IETF has consensus that the item is 166 RECOMMENDED. This only means that the associated mechanism is fit 167 for the purpose for which it was defined. Careful reading of the 168 documentation for the mechanism is necessary to understand the 169 applicability of that mechanism. The IETF could recommend 170 mechanisms that have limited applicability, but will provide 171 applicability statements that describe any limitations of the 172 mechanism or necessary constraints on its use. 174 * N: Indicates that the item has not been evaluated by the IETF and 175 that the IETF has made no statement about the suitability of the 176 associated mechanism. This does not necessarily mean that the 177 mechanism is flawed, only that no consensus exists. The IETF 178 might have consensus to leave an items marked as "N" on the basis 179 of it having limited applicability or usage constraints. 181 * D: Indicates that the item is discouraged and SHOULD NOT or MUST 182 NOT be used. This marking could be used to identify mechanisms 183 that might result in problems if they are used, such as a weak 184 cryptographic algorithm or a mechanism that might cause 185 interoperability problems in deployment. 187 Setting the Recommended item to "Y" or "D" or changing a item whose 188 current value is "Y" or "D" requires standards action. Not all items 189 defined in standards track documents need to be marked as 190 Recommended. Changing the Recommended status of a standards track 191 item requires standards action. 193 [Note: the registries in the rest of the document will need to have 194 the recommended column updated appropriately, specifically to 195 deprecate MD5 and SHA-1, etc.] 197 6. Session Ticket TLS Extension 199 The nomenclature for the registry entries in the TLS ExtensionType 200 Values registry correspond to the presentation language field name 201 except for entry 35. To ensure that the values in the registry are 202 consistently identified in the registry, IANA: 204 * [SHALL rename/has renamed] entry 35 to "session_ticket (renamed 205 from "SessionTicket TLS")" [RFC5077]. 207 * [SHALL add/has added] a reference to this document in the 208 "Reference" column for entry 35. 210 7. TLS ExtensionType Values 212 Experience has shown that the IETF Review registry policy for TLS 213 extensions was too strict. Based on WG consensus, the decision was 214 taken to change the registration policy to Specification Required 215 [RFC8126] while reserving a small part of the code space for private 216 use. Therefore, IANA [SHALL update/has updated] the TLS 217 ExtensionType Values registry as follows: 219 * Changed the registry policy to: 221 Values with the first byte in the range 0-254 (decimal) are 222 assigned via Specification Required [RFC8126]. Values with the 223 first byte 255 (decimal) are reserved for Private Use [RFC8126]. 225 * Updated the "Reference" to also refer to this document. 227 See Section 17 for additional information about the designated expert 228 pool. 230 Despite wanting to "loosen" the registration policies for TLS 231 extensions, it is still useful to indicate in the IANA registry which 232 extensions the WG recommends be supported. Therefore, IANA [SHALL 233 update/has updated] the TLS ExtensionType Values registry as follows: 235 * Add a "Recommended" column with the contents as listed below. 236 This table has been generated by marking Standards Track RFCs as 237 "Y" and all others as "N". The "Recommended" column is assigned a 238 value of "N" unless explicitly requested, and adding a value with 239 a "Recommended" value of "Y" requires Standards Action [RFC8126]. 240 IESG Approval is REQUIRED for a Y->N transition. 242 +========================================+=============+ 243 | Extension | Recommended | 244 +========================================+=============+ 245 | server_name | Y | 246 +----------------------------------------+-------------+ 247 | max_fragment_length | N | 248 +----------------------------------------+-------------+ 249 | client_certificate_url | Y | 250 +----------------------------------------+-------------+ 251 | trusted_ca_keys | Y | 252 +----------------------------------------+-------------+ 253 | truncated_hmac | Y | 254 +----------------------------------------+-------------+ 255 | status_request | Y | 256 +----------------------------------------+-------------+ 257 | user_mapping | Y | 258 +----------------------------------------+-------------+ 259 | client_authz | N | 260 +----------------------------------------+-------------+ 261 | server_authz | N | 262 +----------------------------------------+-------------+ 263 | cert_type | N | 264 +----------------------------------------+-------------+ 265 | supported_groups | Y | 266 +----------------------------------------+-------------+ 267 | ec_point_formats | Y | 268 +----------------------------------------+-------------+ 269 | srp | N | 270 +----------------------------------------+-------------+ 271 | signature_algorithms | Y | 272 +----------------------------------------+-------------+ 273 | use_srtp | Y | 274 +----------------------------------------+-------------+ 275 | heartbeat | Y | 276 +----------------------------------------+-------------+ 277 | application_layer_protocol_negotiation | Y | 278 +----------------------------------------+-------------+ 279 | status_request_v2 | Y | 280 +----------------------------------------+-------------+ 281 | signed_certificate_timestamp | N | 282 +----------------------------------------+-------------+ 283 | client_certificate_type | Y | 284 +----------------------------------------+-------------+ 285 | server_certificate_type | Y | 286 +----------------------------------------+-------------+ 287 | padding | Y | 288 +----------------------------------------+-------------+ 289 | encrypt_then_mac | Y | 290 +----------------------------------------+-------------+ 291 | extended_master_secret | Y | 292 +----------------------------------------+-------------+ 293 | cached_info | Y | 294 +----------------------------------------+-------------+ 295 | session_ticket | Y | 296 +----------------------------------------+-------------+ 297 | renegotiation_info | Y | 298 +----------------------------------------+-------------+ 300 Table 1 302 IANA [SHALL update/has added] the following notes: 304 Note: The role of the designated expert is described in [RFC8447] 305 The designated expert [RFC8126] ensures that the specification is 306 publicly available. It is sufficient to have an Internet-Draft 307 (that is posted and never published as an RFC) or a document from 308 another standards body, industry consortium, university site, etc. 309 The expert may provide more in-depth reviews, but their approval 310 should not be taken as an endorsement of the extension. 312 Note: As specified in [RFC8126], assignments made in the Private Use 313 space are not generally useful for broad interoperability. It is 314 the responsibility of those making use of the Private Use range to 315 ensure that no conflicts occur (within the intended scope of use). 316 For widespread experiments, temporary reservations are available. 318 Note: If an item is not marked as "Recommended", it does not 319 necessarily mean that it is flawed; rather, it indicates that the 320 item either has not been through the IETF consensus process, has 321 limited applicability, or is intended only for specific use cases. 323 The extensions added by [RFC8446] are omitted from the above table; 324 additionally, token_binding is omitted, since 325 [I-D.ietf-tokbind-negotiation] specifies the value of the 326 "Recommended" column as for this extension. 328 [RFC8446] also uses the TLS ExtensionType Values registry originally 329 created in [RFC4366]. The following text is from [RFC8446] and is 330 included here to ensure alignment between these specifications. 332 * IANA [SHALL update/has updated] this registry to include the 333 "key_share", "pre_shared_key", "psk_key_exchange_modes", 334 "early_data", "cookie", "supported_versions", 335 "certificate_authorities", "oid_filters", "post_handshake_auth", 336 and "signature_algorithms_cert", extensions with the values 337 defined in [RFC8446] and the "Recommended" value of "Y". 339 * IANA [SHALL update/has updated] this registry to include a "TLS 340 1.3" column that lists the messages in which the extension may 341 appear. This column [SHALL be/has been] initially populated from 342 the table in Section 4.2 of [RFC8446] with any extension not 343 listed there marked as "-" to indicate that it is not used by TLS 344 1.3. 346 8. TLS Cipher Suites Registry 348 Experience has shown that the IETF Consensus registry policy for TLS 349 Cipher Suites was too strict. Based on WG consensus, the decision 350 was taken to change the TLS Cipher Suites registry's registration 351 policy to Specification Required [RFC8126] while reserving a small 352 part of the code space for experimental and private use. Therefore, 353 IANA [SHALL update/has updated] the TLS Cipher Suites registry's 354 policy as follows: 356 Values with the first byte in the range 0-254 (decimal) are 357 assigned via Specification Required {{RFC8126}} . Values with the 358 first byte 255 (decimal) are reserved for Private Use {{RFC8126}} . 360 See Section 17 for additional information about the designated expert 361 pool. 363 The TLS Cipher Suites registry has grown significantly and will 364 continue to do so. To better guide those not intimately involved in 365 TLS, IANA [shall update/has updated] the TLS Cipher Suites registry 366 as follows: 368 [The following text needs to be update to reflect the new recommended 369 policy] 371 * Added a "Recommended" column to the TLS Cipher Suites registry. 372 The cipher suites that follow in the two tables are marked as "Y". 373 All other cipher suites are marked as "N". The "Recommended" 374 column is assigned a value of "N" unless explicitly requested, and 375 adding a value with a "Recommended" value of "Y" requires 376 Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N 377 transition. 379 The cipher suites that follow are Standards Track server- 380 authenticated (and optionally client-authenticated) cipher suites 381 that are currently available in TLS 1.2. 383 RFC EDITOR: The previous paragraph is for document reviewers and is 384 not meant for the registry. 386 Cipher Suite Name | Value 387 ----------------------------------------------+------------ 388 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | {0x00,0x9E} 389 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | {0x00,0x9F} 390 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2B} 391 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x2C} 392 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2F} 393 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x30} 394 TLS_DHE_RSA_WITH_AES_128_CCM | {0xC0,0x9E} 395 TLS_DHE_RSA_WITH_AES_256_CCM | {0xC0,0x9F} 396 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA8} 397 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA9} 398 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAA} 400 The cipher suites that follow are Standards Track ephemeral pre- 401 shared key cipher suites that are available in TLS 1.2. 403 RFC EDITOR: The previous paragraph is for document reviewers and is 404 not meant for the registry. 406 Cipher Suite Name | Value 407 ----------------------------------------------+------------ 408 TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | {0x00,0xAA} 409 TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | {0x00,0xAB} 410 TLS_DHE_PSK_WITH_AES_128_CCM | {0xC0,0xA6} 411 TLS_DHE_PSK_WITH_AES_256_CCM | {0xC0,0xA7} 412 TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | {0xD0,0x01} 413 TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | {0xD0,0x02} 414 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | {0xD0,0x05} 415 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAC} 416 TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAD} 418 The TLS 1.3 cipher suites specified by [RFC8446] are not listed here; 419 that document provides for their "Recommended" status. 421 Despite the following behavior being misguided, experience has shown 422 that some customers use the IANA registry as a checklist against 423 which to measure an implementation's completeness, and some 424 implementers blindly implement cipher suites. Therefore, IANA [SHALL 425 add/has added] the following warning to the registry: 427 WARNING: Cryptographic algorithms and parameters will be broken or 428 weakened over time. Blindly implementing cipher suites listed 429 here is not advised. Implementers and users need to check that 430 the cryptographic algorithms listed continue to provide the 431 expected level of security. 433 IANA [SHALL add/has added] the following note to ensure that those 434 that focus on IANA registries are aware that TLS 1.3 [RFC8446] uses 435 the same registry but defines ciphers differently: 437 Note: Although TLS 1.3 uses the same cipher suite space as previous 438 versions of TLS, TLS 1.3 cipher suites are defined differently, 439 only specifying the symmetric ciphers and hash functions, and 440 cannot be used for TLS 1.2. Similarly, TLS 1.2 and lower cipher 441 suite values cannot be used with TLS 1.3. 443 IANA [SHALL add/has added] the following notes to document the rules 444 for populating the "Recommended" column: 446 Note: CCM_8 cipher suites are not marked as "Recommended". These 447 cipher suites have a significantly truncated authentication tag 448 that represents a security trade-off that may not be appropriate 449 for general environments. 451 Note: If an item is not marked as "Recommended", it does not 452 necessarily mean that it is flawed; rather, it indicates that the 453 item either has not been through the IETF consensus process, has 454 limited applicability, or is intended only for specific use cases. 456 IANA [SHALL add/has added] the following notes for additional 457 information: 459 Note: The role of the designated expert is described in [this-RFC]. 460 The designated expert [RFC8126] ensures that the specification is 461 publicly available. It is sufficient to have an Internet-Draft 462 (that is posted and never published as an RFC) or a document from 463 another standards body, industry consortium, university site, etc. 464 The expert may provide more in-depth reviews, but their approval 465 should not be taken as an endorsement of the cipher suite. 467 Note: As specified in [RFC8126], assignments made in the Private Use 468 space are not generally useful for broad interoperability. It is 469 the responsibility of those making use of the Private Use range to 470 ensure that no conflicts occur (within the intended scope of use). 471 For widespread experiments, temporary reservations are available. 473 IANA [SHALL update/has updated] the reference for this registry to 474 also refer to this document. 476 9. TLS Supported Groups 478 Similar to cipher suites, supported groups have proliferated over 479 time, and some use the registry to measure implementations. 480 Therefore, IANA [SHALL add/has added] a "Recommended" column with a 481 "Y" for secp256r1, secp384r1, x25519, and x448, while all others are 482 "N". These "Y" groups are taken from Standards Track RFCs; [RFC8422] 483 elevates secp256r1 and secp384r1 to Standards Track. Not all groups 484 from [RFC8422], which is Standards Track, are marked as "Y"; these 485 groups apply to TLS 1.3 [RFC8446] and previous versions of TLS. The 486 "Recommended" column is assigned a value of "N" unless explicitly 487 requested, and adding a value with a "Recommended" value of "Y" 488 requires Standards Action [RFC8126]. IESG Approval is REQUIRED for a 489 Y->N transition. 491 IANA [SHALL add/has added] the following notes: 493 Note: If an item is not marked as "Recommended" it does not 494 necessarily mean that it is flawed; rather, it indicates that the 495 item either has not been through the IETF consensus process, has 496 limited applicability, or is intended only for specific use cases. 498 Note: The role of the designated expert is described in [RFC8447] . 499 The designated expert [RFC8126] ensures that the specification is 500 publicly available. It is sufficient to have an Internet-Draft 501 (that is posted and never published as an RFC) or a document from 502 another standards body, industry consortium, university site, etc. 503 The expert may provide more in-depth reviews, but their approval 504 should not be taken as an endorsement of the supported groups. 506 Despite the following behavior being misguided, experience has shown 507 that some customers use the IANA registry as a checklist against 508 which to measure an implementation's completeness, and some 509 implementers blindly implement supported group. Therefore, IANA 510 [SHALL add/has added] the following warning to the registry: 512 WARNING: Cryptographic algorithms and parameters will be broken or 513 weakened over time. Blindly implementing supported groups listed 514 here is not advised. Implementers and users need to check that 515 the cryptographic algorithms listed continue to provide the 516 expected level of security. 518 IANA [SHALL update/has updated] the reference for this registry to 519 also refer to this document. 521 The value 0 (0x0000) has been marked as reserved. 523 10. TLS ClientCertificateType Identifiers 525 Experience has shown that the IETF Consensus registry policy for TLS 526 ClientCertificateType Identifiers is too strict. Based on WG 527 consensus, the decision was taken to change the registration policy 528 to Specification Required [RFC8126] while reserving some of the code 529 space for Standards Track usage and a small part of the code space 530 for private use. Therefore, IANA has updated the TLS 531 ClientCertificateType Identifiers registry's policy as follows: 533 Values in the range 0-63 are assigned via Standards Action. 534 Values 64-223 are assigned via Specification Required [RFC8126]. 535 Values 224-255 are reserved for Private Use. 537 See Section 17 for additional information about the designated expert 538 pool. 540 IANA [SHALL add/has added] the following notes: 542 Note: The role of the designated expert is described in [this-RFC]. 543 The designated expert [RFC8126] ensures that the specification is 544 publicly available. It is sufficient to have an Internet-Draft 545 (that is posted and never published as an RFC) or a document from 546 another standards body, industry consortium, university site, etc. 547 The expert may provide more in-depth reviews, but their approval 548 should not be taken as an endorsement of the identifier. 550 Note: As specified in [RFC8126], assignments made in the Private Use 551 space are not generally useful for broad interoperability. It is 552 the responsibility of those making use of the Private Use range to 553 ensure that no conflicts occur (within the intended scope of use). 554 For widespread experiments, temporary reservations are available. 556 11. New Session Ticket TLS Handshake Message Type 558 To align with TLS implementations and to align the naming 559 nomenclature with other Handshake message types, IANA: 561 * [SHALL rename/has renamed] entry 4 in the TLS HandshakeType 562 registry to "new_session_ticket (renamed from NewSessionTicket)" 563 [RFC5077]. 565 * [SHALL add/has added] a reference to this document in the 566 "Reference" column for entry 4 in the TLS HandshakeType registry. 568 12. TLS Exporter Labels Registry 570 To aid those reviewers who start with the IANA registry, IANA [SHALL 571 add/has added]: 573 * The following note to the TLS Exporter Labels registry: 575 Note: [RFC5705] defines keying material exporters for TLS in terms 576 of the TLS PRF. [RFC8446] replaced the PRF with HKDF, thus 577 requiring a new construction. The exporter interface remains the 578 same; however, the value is computed differently. 580 * A "Recommended" column to the TLS Exporter Labels registry. The 581 table that follows has been generated by marking Standards Track 582 RFCs as "Y" and all others as "N". The "Recommended" column is 583 assigned a value of "N" unless explicitly requested, and adding a 584 value with a "Recommended" value of "Y" requires Standards Action 585 [RFC8126]. IESG Approval is REQUIRED for a Y->N transition. 587 Exporter Value | Recommended | 588 --------------------------------|-------------| 589 client finished | Y | 590 server finished | Y | 591 master secret | Y | 592 key expansion | Y | 593 client EAP encryption | Y | 594 ttls keying material | N | 595 ttls challenge | N | 596 EXTRACTOR-dtls_srtp | Y | 597 EXPORTER_DTLS_OVER_SCTP | Y | 598 EXPORTER: teap session key seed | Y | 600 To provide additional information for the designated experts, IANA 601 [SHALL add/has added] the following notes: 603 Note: The role of the designated expert is described in [RFC8447] . 604 The designated expert [RFC8126] ensures that the specification is 605 publicly available. It is sufficient to have an Internet-Draft 606 (that is posted and never published as an RFC) or a document from 607 another standards body, industry consortium, university site, etc. 608 The expert may provide more in-depth reviews, but their approval 609 should not be taken as an endorsement of the exporter label. The 610 expert also verifies that the label is a string consisting of 611 printable ASCII characters beginning with "EXPORTER". IANA MUST 612 also verify that one label is not a prefix of any other label. 613 For example, labels "key" or "master secretary" are forbidden. 615 Note: If an item is not marked as "Recommended", it does not 616 necessarily mean that it is flawed; rather, it indicates that the 617 item either has not been through the IETF consensus process, has 618 limited applicability, or is intended only for specific use cases. 620 IANA [SHALL update/has updated] the reference for this registry to 621 also refer to this document. 623 13. Adding Missing Item to TLS Alerts Registry 625 IANA [SHALL add/has added] the following entry to the TLS Alerts 626 registry; the entry was omitted from the IANA instructions in 627 [RFC7301]: 629 120 no_application_protocol Y [RFC7301][RFC8447] 631 14. TLS Certificate Types 633 Experience has shown that the IETF Consensus registry policy for TLS 634 Certificate Types is too strict. Based on WG consensus, the decision 635 was taken to change registration policy to Specification Required 636 [RFC8126] while reserving a small part of the code space for private 637 use. Therefore, IANA [SHALL change/has changed] the TLS Certificate 638 Types registry as follows: 640 * Changed the registry policy to: 642 Values in the range 0-223 (decimal) are assigned via Specification 643 Required [RFC8126]. Values in the range 224-255 (decimal) are 644 reserved for Private Use [RFC8126]. 646 * Added a "Recommended" column to the registry. X.509 and Raw 647 Public Key are "Y". All others are "N". The "Recommended" column 648 is assigned a value of "N" unless explicitly requested, and adding 649 a value with a "Recommended" value of "Y" requires Standards 650 Action [RFC8126]. IESG Approval is REQUIRED for a Y->N 651 transition. 653 See Section 17 for additional information about the designated expert 654 pool. 656 IANA [SHALL add/has added] the following note: 658 Note: The role of the designated expert is described in [this-RFC]. 660 The designated expert [RFC8126] ensures that the specification is 661 publicly available. It is sufficient to have an Internet-Draft 662 (that is posted and never published as an RFC) or a document from 663 another standards body, industry consortium, university site, etc. 664 The expert may provide more in-depth reviews, but their approval 665 should not be taken as an endorsement of the certificate type. 667 Note: If an item is not marked as "Recommended", it does not 668 necessarily mean that it is flawed; rather, it indicates that the 669 item either has not been through the IETF consensus process, has 670 limited applicability, or is intended only for specific use cases. 672 IANA [SHALL update/has updated] the reference for this registry to 673 also refer this document. 675 15. Orphaned Registries 677 To make it clear that (D)TLS 1.3 has orphaned certain registries 678 (i.e., they are only applicable to version of (D)TLS protocol 679 versions prior to 1.3), IANA: 681 * [SHALL add/has added] the following to the TLS Compression Method 682 Identifiers registry [RFC3749]: 684 Note: Value 0 (NULL) is the only value in this registry applicable 685 to (D)TLS protocol version 1.3 or later. 687 * [SHALL add/has added] the following to the TLS HashAlgorithm 688 [RFC5246] and TLS SignatureAlgorithm registries [RFC5246]: 690 Note: The values in this registry are only applicable to (D)TLS 691 protocol versions prior to 1.3. (D)TLS 1.3 and later versions' 692 values are registered in the TLS SignatureScheme registry. 694 * [SHALL update/has updated] the "Reference" field in the TLS 695 Compression Method Identifiers, TLS HashAlgorithm and TLS 696 SignatureAlgorithm registries to also refer to this document. 698 * [SHALL update/has updated] the TLS HashAlgorithm registry to list 699 values 7 and 9-223 as "Reserved" and the TLS SignatureAlgorithm 700 registry to list values 4-6 and 9-223 as "Reserved". 702 * has added the following to the TLS ClientCertificateType 703 Identifiers registry [RFC5246]: 705 Note: The values in this registry are only applicable to (D)TLS 706 protocol versions prior to 1.3. 708 Despite the fact that the TLS HashAlgorithm and SignatureAlgorithm 709 registries are orphaned, it is still important to warn implementers 710 of pre-TLS1.3 implementations about the dangers of blindly 711 implementing cryptographic algorithms. Therefore, IANA has added the 712 following warning to the TLS HashAlgorithm and SignatureAlgorithm 713 registries: 715 WARNING: Cryptographic algorithms and parameters will be broken or 716 weakened over time. Blindly implementing the cryptographic 717 algorithms listed here is not advised. Implementers and users 718 need to check that the cryptographic algorithms listed continue to 719 provide the expected level of security. 721 16. Additional Notes 723 IANA has added the following warning and note to the TLS 724 SignatureScheme registry: 726 WARNING: Cryptographic algorithms and parameters will be broken or 727 weakened over time. Blindly implementing signature schemes listed 728 here is not advised. Implementers and users need to check that 729 the cryptographic algorithms listed continue to provide the 730 expected level of security. 732 Note: As specified in [RFC8126], assignments made in the Private Use 733 space are not generally useful for broad interoperability. It is 734 the responsibility of those making use of the Private Use range to 735 ensure that no conflicts occur (within the intended scope of use). 736 For widespread experiments, temporary reservations are available. 738 IANA has added the following notes to the TLS PskKeyExchangeMode 739 registry: 741 Note: If an item is not marked as "Recommended", it does not 742 necessarily mean that it is flawed; rather, it indicates that the 743 item either has not been through the IETF consensus process, has 744 limited applicability, or is intended only for specific use cases. 746 Note: The role of the designated expert is described in RFC 8447. 747 The designated expert [RFC8126] ensures that the specification is 748 publicly available. It is sufficient to have an Internet-Draft 749 (that is posted and never published as an RFC) or a document from 750 another standards body, industry consortium, university site, etc. 751 The expert may provide more in depth reviews, but their approval 752 should not be taken as an endorsement of the key exchange mode. 754 17. Designated Expert Pool 756 Specification Required [RFC8126] registry requests are registered 757 after a three-week review period on the tls-reg-review@ietf.org 758 (mailto:tls-reg-review@ietf.org) mailing list, on the advice of one 759 or more designated experts. However, to allow for the allocation of 760 values prior to publication, the designated experts may approve 761 registration once they are satisfied that such a specification will 762 be published. 764 Registration requests sent to the mailing list for review SHOULD use 765 an appropriate subject (e.g., "Request to register value in TLS bar 766 registry"). 768 Within the review period, the designated experts will either approve 769 or deny the registration request, communicating this decision to the 770 review list and IANA. Denials SHOULD include an explanation and, if 771 applicable, suggestions as to how to make the request successful. 772 Registration requests that are undetermined for a period longer than 773 21 days can be brought to the IESG's attention (using the 774 iesg@ietf.org (mailto:iesg@ietf.org) mailing list) for resolution. 776 Criteria that SHOULD be applied by the designated experts includes 777 determining whether the proposed registration duplicates existing 778 functionality, whether it is likely to be of general applicability or 779 useful only for a single application, and whether the registration 780 description is clear. 782 IANA MUST only accept registry updates from the designated experts 783 and SHOULD direct all requests for registration to the review mailing 784 list. 786 It is suggested that multiple designated experts be appointed who are 787 able to represent the perspectives of different applications using 788 this specification, in order to enable broadly informed review of 789 registration decisions. In cases where a registration decision could 790 be perceived as creating a conflict of interest for a particular 791 Expert, that Expert SHOULD defer to the judgment of the other 792 Experts. 794 18. Security Considerations 796 The change to Specification Required from IETF Review lowers the 797 amount of review provided by the WG for cipher suites and supported 798 groups. This change reflects reality in that the WG essentially 799 provided no cryptographic review of the cipher suites or supported 800 groups. This was especially true of national cipher suites. 802 Recommended algorithms are regarded as secure for general use at the 803 time of registration; however, cryptographic algorithms and 804 parameters will be broken or weakened over time. It is possible that 805 the "Recommended" status in the registry lags behind the most recent 806 advances in cryptanalysis. Implementers and users need to check that 807 the cryptographic algorithms listed continue to provide the expected 808 level of security. 810 Designated experts ensure the specification is publicly available. 811 They may provide more in-depth reviews. Their review should not be 812 taken as an endorsement of the cipher suite, extension, supported 813 group, etc. 815 19. IANA Considerations 817 This document is entirely about changes to TLS-related IANA 818 registries. 820 20. References 822 20.1. Normative References 824 [I-D.ietf-tls-tls13] 825 Rescorla, E., "The Transport Layer Security (TLS) Protocol 826 Version 1.3", Work in Progress, Internet-Draft, draft- 827 ietf-tls-tls13-28, 20 March 2018, 828 . 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, 833 DOI 10.17487/RFC2119, March 1997, 834 . 836 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 837 Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 838 2004, . 840 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 841 Data", RFC 4680, DOI 10.17487/RFC4680, October 2006, 842 . 844 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 845 "Transport Layer Security (TLS) Session Resumption without 846 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 847 January 2008, . 849 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 850 (TLS) Protocol Version 1.2", RFC 5246, 851 DOI 10.17487/RFC5246, August 2008, 852 . 854 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 855 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 856 March 2010, . 858 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 859 Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878, 860 May 2010, . 862 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 863 Layer Security (TLS) and Datagram Transport Layer Security 864 (DTLS) Heartbeat Extension", RFC 6520, 865 DOI 10.17487/RFC6520, February 2012, 866 . 868 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 869 "Transport Layer Security (TLS) Application-Layer Protocol 870 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 871 July 2014, . 873 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 874 Writing an IANA Considerations Section in RFCs", BCP 26, 875 RFC 8126, DOI 10.17487/RFC8126, June 2017, 876 . 878 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 879 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 880 May 2017, . 882 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 883 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 884 . 886 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 887 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 888 . 890 20.2. Informative References 892 [I-D.ietf-tokbind-negotiation] 893 Popov, A., Nyström, M., Balfanz, D., and A. Langley, 894 "Transport Layer Security (TLS) Extension for Token 895 Binding Protocol Negotiation", Work in Progress, Internet- 896 Draft, draft-ietf-tokbind-negotiation-14, 23 May 2018, 897 . 900 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 901 and T. Wright, "Transport Layer Security (TLS) 902 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 903 . 905 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 906 Multiple Certificate Status Request Extension", RFC 6961, 907 DOI 10.17487/RFC6961, June 2013, 908 . 910 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 911 Curve Cryptography (ECC) Cipher Suites for Transport Layer 912 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 913 DOI 10.17487/RFC8422, August 2018, 914 . 916 Authors' Addresses 918 Joe Salowey 919 Salesforce 920 Email: joe@salowey.net 922 Sean Turner 923 sn3rd 924 Email: sean@sn3rd.com