idnits 2.17.1 draft-ietf-tls-iana-registry-updates-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 180 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 183: '...o". Future extensions MUST define the...' -- 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 (January 02, 2017) is 2670 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) == Unused Reference: 'RFC4680' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC5705' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'RFC5878' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'RFC6520' is defined on line 451, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Experimental RFC: RFC 5878 == Outdated reference: A later version (-17) exists of draft-ietf-tls-rfc4492bis-09 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS WG J. Salowey 3 Internet-Draft Tableau Software 4 Updates: 3749, 5077, 4680, 5246, 5878, S. Turner 5 6520, 7301 (if approved) sn3rd 6 Intended status: Standards Track January 02, 2017 7 Expires: July 6, 2017 9 D/TLS IANA Registry Updates 10 draft-ietf-tls-iana-registry-updates-00 12 Abstract 14 This document changes the IANA registry policy for a number of 15 registries related to DTLS and TLS, renames some of the registries 16 for consistency, and adds notes to many of the registries. As a 17 result, this document updates many RFCs (see updates header). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 6, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Process Note . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Add "TLS" to Registry Names . . . . . . . . . . . . . . . . . 3 56 4. Aligning with RFC 5226 . . . . . . . . . . . . . . . . . . . 4 57 5. TLS ExtensionType Values . . . . . . . . . . . . . . . . . . 4 58 6. TLS Cipher Suite Registry . . . . . . . . . . . . . . . . . . 6 59 7. TLS ClientCertificateType Identifiers . . . . . . . . . . . . 7 60 8. New Session Ticket TLS Handshake Message Type . . . . . . . . 8 61 9. Session Ticket TLS Extension . . . . . . . . . . . . . . . . 8 62 10. TLS Exporter Label Registry . . . . . . . . . . . . . . . . . 8 63 11. Add Missing Item to TLS Alert Registry . . . . . . . . . . . 8 64 12. Orphaned Extensions . . . . . . . . . . . . . . . . . . . . . 8 65 13. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . 9 66 14. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 16.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 16.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Process Note 75 As the authors of this draft are also the WG chairs, the responsible 76 Area Director has agreed to judge consensus. 78 RFC EDITOR: Please delete section prior to publication. 80 2. Introduction 82 This document requests that IANA make changes to a number of DTLS- 83 and TLS-related IANA registries. 85 In this document, we use the term "(D)TLS" to refer to registries 86 that apply to both TLS and DTLS. 88 o Add "TLS" to registries' names for consistency with other TLS- 89 related registries. 91 o Change the IANA registry policy [RFC5226] for the TLS 92 ExtensionType Values, TLS Cipher Suite, and TLS 93 ClientCertificateType Identifiers registries. These changes 94 register a small part of these code spaces for experimentation and 95 private use. 97 o Add the designated expert intructions as a note to the TLS 98 ExtensionType Values, TLS Cipher Suite, and TLS 99 ClientCertificateType Identifiers registries to inform users of 100 the registry. 102 o Add notes to indicate whether an extension, certain values of an 103 extension, or an entire registry is only applicable pre-(D)TLS 104 1.3. 106 o Rename the NewSessionTicket TLS HandshakeType message registry 107 entry [RFC5077] to new_session_ticket to match the naming 108 nomenclature for the other Handshake type names and to match with 109 existing implementations. 111 o Rename the SessionTicket TLS to session_ticket to match the 112 nomenclature for the other extensions' names. 114 o Add missing entry to the TLS Alert Registry for the 115 no_application_protocol alert defined in [RFC7301] 117 This document proposes no changes to the registration policies for 118 TLS Alert [I-D.ietf-tls-tls13], TLS ContentType [I-D.ietf-tls-tls13], 119 TLS HandshakeType, [I-D.ietf-tls-tls13] and TLS Certificate Status 120 Types [RFC6961]; the existing policies (Standards Action for the 121 first three; IETF Review for the last), are appropriate for these 122 one-byte code points because of their scarcity. 124 This document proposes no changes to the EC Curve Type, EC Point 125 Format, and Supported Groups Registries (see 126 [I-D.ietf-tls-rfc4492bis]). 128 3. Add "TLS" to Registry Names 130 IANA is to update the names of the following registries to add "TLS" 131 to for consistency with the other TLS-related extensions: 133 o Application-Layer Protocol Negotiation (ALPN) Protocol IDs, 135 o ExtensionType Values, 137 o Heartbeat Message Types, 139 o Heartbeat Modes, and 141 o Supported Groups. 143 IANA is also to add a reference to this document for the registry 144 whose names have been updated as a result of the above change. The 145 remainder of this document will use the registry names with the "TLS" 146 prefix. 148 4. Aligning with RFC 5226 150 Many of the TLS-related IANA registries were defined prior to 151 [RFC5226] where "IETF Consensus" was used instead of the 152 RFC5226-defined "IETF Review". To align with the new terminology, 153 IANA is to update to use "IETF Review" in place of "IETF Consensus" 154 in the following registries: 156 o TLS Authorization Data Formats 158 o TLS Supplemental Data Formats (SupplementalDataType) 160 This is not a universal change as some registries originally defined 161 with "IETF Consensus" are undergoing other changes either as a result 162 of this document or [I-D.ietf-tls-rfc4492bis]. 164 5. TLS ExtensionType Values 166 IANA is to update the TLS ExtensionType Values registry as follows: 168 o Change the registry policy to: 170 Values with the first byte in the range 0-254 (decimal) are 171 assigned via Specification Required [RFC5226]. Values with the 172 first byte 255 (decimal) are reserved for Private Use [RFC5226]. 174 o Update the "References" to also refer to this document. 176 o Add the following note: 178 Note: Experts are to verify that there is in fact a publicly 179 available standard. 181 o Add a "Recommended" column with the contents as listed below. 182 This table has been generated by marking Standards Track RFCs as 183 "Yes" and all others as "No". Future extensions MUST define the 184 value of this column. A Standards Track document [RFC5226] is 185 required to register an extension with the value "Yes". 187 +----------------------------------------+-------------+ 188 | Extension | Recommended | 189 +----------------------------------------+-------------+ 190 | server_name | Yes | 191 | | | 192 | max_fragment_length | Yes | 193 | | | 194 | client_certificate_url | Yes | 195 | | | 196 | trusted_ca_keys | Yes | 197 | | | 198 | truncated_hmac | Yes | 199 | | | 200 | status_request | Yes | 201 | | | 202 | user_mapping | Yes | 203 | | | 204 | client_authz | No | 205 | | | 206 | server_authz | No | 207 | | | 208 | cert_type | Yes | 209 | | | 210 | supported_groups | Yes | 211 | | | 212 | ec_point_formats | Yes | 213 | | | 214 | srp | No | 215 | | | 216 | signature_algorithms | Yes | 217 | | | 218 | use_srtp | Yes | 219 | | | 220 | heartbeat | Yes | 221 | | | 222 | application_layer_protocol_negotiation | Yes | 223 | | | 224 | status_request_v2 | Yes | 225 | | | 226 | signed_certificate_timestamp | No | 227 | | | 228 | client_certificate_type | Yes | 229 | | | 230 | server_certificate_type | Yes | 231 | | | 232 | padding | Yes | 233 | | | 234 | encrypt_then_mac | Yes | 235 | | | 236 | extended_master_secret | Yes | 237 | | | 238 | SessionTicket TLS | Yes | 239 | | | 240 | renegotiation_info | Yes | 241 +----------------------------------------+-------------+ 243 6. TLS Cipher Suite Registry 245 IANA is to update the TLS Cipher Suite registry as follows: 247 o Change the registry policy to: 249 Values with the first byte in the range 0-254 (decimal) are 250 assigned via Specification Required [RFC5226]. Values with the 251 first byte 255 (decimal) are reserved for Private Use [RFC2434]. 253 o Add a "Recommended" column to the cipher suite registry. The 254 cipher suites that follow in the two tables are marked as "Yes". 255 All other cipher suites are marked as "No". 257 The cipher suites that follow are standards track server- 258 authenticated (and optionally client-authenticated) cipher suites 259 which are currently available in TLS 1.2. The notable exception are 260 the ECDHE AES GCM cipher suites which are not yet standards track 261 prior to the publication of this specification, but this document 262 promotes those 4 cipher suites to standards track (see TO-DO insert 263 reference). 265 Cipher Suite Name | Value 266 ----------------------------------------------+------------ 267 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | {0x00,0x9E} 268 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | {0x00,0x9F} 269 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2B} 270 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x2C} 271 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2F} 272 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x30} 273 TLS_DHE_RSA_WITH_AES_128_CCM | {0xC0,0x9E} 274 TLS_DHE_RSA_WITH_AES_256_CCM | {0xC0,0x9F} 275 TLS_DHE_RSA_WITH_AES_128_CCM_8 | {0xC0,0xA2} 276 TLS_DHE_RSA_WITH_AES_256_CCM_8 | {0xC0,0xA3} 277 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA8} 278 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA9} 279 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAA} 281 The cipher suites that follow are standards track ephemeral pre- 282 shared key cipher suites which are available in TLS 1.2. [RFC6655] 283 is inconsistent with respect to the ordering of components within PSK 284 AES CCM cipher suite names; those names are used here without 285 modification. 287 Cipher Suite Name | Value 288 ----------------------------------------------+------------ 289 TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | {0x00,0xAA} 290 TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | {0x00,0xAB} 291 TLS_DHE_PSK_WITH_AES_128_CCM | {0xC0,0xA6} 292 TLS_DHE_PSK_WITH_AES_256_CCM | {0xC0,0xA7} 293 TLS_PSK_DHE_WITH_AES_128_CCM_8 | {0xC0,0xAA} 294 TLS_PSK_DHE_WITH_AES_256_CCM_8 | {0xC0,0xAB} 295 TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | {TBD} 296 TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | {TBD} 297 TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 | {TBD} 298 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | {TBD} 299 TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 | {TBD} 300 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAC} 301 TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAD} 303 o Add the following: 305 WARNING: Cryptographic algorithms will be broken or weakened over 306 time. Blindly implementing cipher suites listed here is not 307 advised. Implementers and users need to check that the 308 cryptographic algorithms listed continue to provide the expected 309 level of security. 311 Note(1): Although TLS 1.3 uses the same cipher suite space as 312 previous versions of TLS, TLS 1.3 cipher suites are defined 313 differently, only specifying the symmetric ciphers, and cannot it 314 be used for TLS 1.2. Similarly, TLS 1.2 and lower cipher suites 315 cannot be used with TLS 1.3. 317 Note(2): Cipher suites marked as "Yes" are those allocated via 318 Standards Track RFCs. Cipher suites marked as "No" are not; 319 cipher suites marked "No" range from "good" to "bad" from a 320 cryptographic standpoint. 322 Note(3): The designated expert [RFC5226] only ensures that the 323 specification is publically available. 325 7. TLS ClientCertificateType Identifiers 327 IANA is to update the TLS ClientCertificateType Identifiers registry 328 as follows: 330 o Change the registry policy to: 332 Values in the range 0-223 are assigned via Specification Required 333 [RFC5226]. Values 224-255 are are reserved for Private Use. 335 o Add the following: 337 Note: The designated expert [RFC5226] only ensures that the 338 specification is publically available. 340 8. New Session Ticket TLS Handshake Message Type 342 To align with TLS implementations and to align the naming 343 nomenclature for other Handshake message types, IANA is to rename 344 entry 4 in the TLS HandshakeType registry to "new_session_ticket 345 (renamed from NewSessionTicket)". IANA is to also add a reference to 346 this document in the Reference column for entry 4 in the TLS 347 HandshakeType registry. 349 9. Session Ticket TLS Extension 351 The nomenclature for the registry entries in the TLS ExtensionType 352 Values registry correspond to the presentation language field name 353 except for entry 35. To ensure that the values in the registry are 354 consistently identified in the registry, IANA is to rename entry 35 355 to "session_ticket (renamed from "SessionTicket TLS")". 357 10. TLS Exporter Label Registry 359 IANA is to add the following note to the TLS Exporter Label Registry: 361 Note: {{RFC5705}} defines keying material exporters for TLS in terms of the TLS PRF. {{I-D.ietf-tls-tls13}} replaced the PRF with HKDF, thus requiring a new construction. The exporter interface remains the same, however the value is computed different. 363 11. Add Missing Item to TLS Alert Registry 365 IANA is to add the following entry to the TLS Alert Registry (the 366 entry was omitted from the IANA instructions in [RFC7301]): 368 120 no_application_protocol Y [RFC7301] 370 12. Orphaned Extensions 372 To make it clear that (D)TLS 1.3 has orphaned certain extensions 373 (i.e., they are only applicable to version of (D)TLS prior to 1.3), 374 IANA is to add the following to the TLS ExtensionType Values 375 registry: 377 Note: The following extensions are only applicable to (D)TLS protocol vesions prior to 1.3: truncated_hmac, srp, encrypt_then_mac, extended_master_secret, session_ticket, and renegotiation_info. These are not applicable to DTLS 1.3. 379 13. Orphaned Registries 381 To make it clear that (D)TLS 1.3 has orphaned certain registries 382 (i.e., they are only applicable to version of (D)TLS protocol 383 versions prior to 1.3), IANA is to: 385 o Add the following to the TLS Compression Method Identifiers 386 registry [RFC3749]: 388 Note: Value 0 (NULL) is the only value in this registry applicable 389 to (D)TLS protocol version 1.3 or later. 391 o Add the following to the TLS Hash Algorithm [RFC5246] and TLS 392 SignatureAlgorithm registries [RFC5246]: 394 Note: The values in this registry are only applicable to (D)TLS 395 protocol versions prior to 1.3. 397 o Update the "References" in the TLS Compression Method Identifiers, 398 TLS Hash Algorithm [RFC5246] and TLS SignatureAlgorithm registries 399 to also refer to this document. 401 14. Security Considerations 403 The authors are fairly certain that there are no security 404 considerations for this document. 406 15. IANA Considerations 408 This document is entirely about changes to TLS-related IANA 409 registries. 411 16. References 413 16.1. Normative References 415 [I-D.ietf-tls-tls13] 416 Rescorla, E., "The Transport Layer Security (TLS) Protocol 417 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 418 October 2016. 420 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 421 Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 422 2004, . 424 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 425 Data", RFC 4680, DOI 10.17487/RFC4680, October 2006, 426 . 428 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 429 "Transport Layer Security (TLS) Session Resumption without 430 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 431 January 2008, . 433 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 434 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 435 DOI 10.17487/RFC5226, May 2008, 436 . 438 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 439 (TLS) Protocol Version 1.2", RFC 5246, 440 DOI 10.17487/RFC5246, August 2008, 441 . 443 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 444 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 445 March 2010, . 447 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 448 Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878, 449 May 2010, . 451 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 452 Layer Security (TLS) and Datagram Transport Layer Security 453 (DTLS) Heartbeat Extension", RFC 6520, 454 DOI 10.17487/RFC6520, February 2012, 455 . 457 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 458 Transport Layer Security (TLS)", RFC 6655, 459 DOI 10.17487/RFC6655, July 2012, 460 . 462 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 463 "Transport Layer Security (TLS) Application-Layer Protocol 464 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 465 July 2014, . 467 16.2. Informative References 469 [I-D.ietf-tls-rfc4492bis] 470 Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 471 Curve Cryptography (ECC) Cipher Suites for Transport Layer 472 Security (TLS) Versions 1.2 and Earlier", draft-ietf-tls- 473 rfc4492bis-09 (work in progress), October 2016. 475 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 476 IANA Considerations Section in RFCs", RFC 2434, 477 DOI 10.17487/RFC2434, October 1998, 478 . 480 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 481 Multiple Certificate Status Request Extension", RFC 6961, 482 DOI 10.17487/RFC6961, June 2013, 483 . 485 Authors' Addresses 487 Joe Salowey 488 Tableau Software 490 Email: joe@salowey.net 492 Sean Turner 493 sn3rd 495 Email: sean@sn3rd.com