idnits 2.17.1 draft-sandj-tls-iana-registry-updates-01.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 175 characters in excess of 72. -- 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 (October 20, 2016) is 2745 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) == Missing Reference: 'RFC6655' is mentioned on line 225, but not defined == Unused Reference: 'RFC4680' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'RFC5705' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC5878' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC6520' is defined on line 396, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-14 ** 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-08 -- 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: 5 errors (**), 0 flaws (~~), 8 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 October 20, 2016 7 Expires: April 23, 2017 9 D/TLS IANA Registry Updates 10 draft-sandj-tls-iana-registry-updates-01 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 April 23, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . 4 59 7. TLS ClientCertificateType Identifiers . . . . . . . . . . . . 6 60 8. New Session Ticket TLS Handshake Message Type . . . . . . . . 7 61 9. Session Ticket TLS Extension . . . . . . . . . . . . . . . . 7 62 10. TLS Exporter Label Registry . . . . . . . . . . . . . . . . . 7 63 11. Add Missing Item to TLS Alert Registry . . . . . . . . . . . 7 64 12. Orphaned Extensions . . . . . . . . . . . . . . . . . . . . . 7 65 13. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . 8 66 14. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 16.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 16.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 more relaxes 94 rules are more condusive to TBD. 96 o Add the designated expert intructions as a note to the TLS 97 ExtensionType Values, TLS Cipher Suite, and TLS 98 ClientCertificateType Identifiers registries to inform IANA- 99 registry-focused, non-RFC-reading what's expected from the 100 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 TLS Alert 118 [I-D.ietf-tls-tls13], TLS ContentType [I-D.ietf-tls-tls13], TLS 119 HandshakeType, [I-D.ietf-tls-tls13] and TLS Certificate Status Types 120 [RFC6961]; Standards Action, for the 1st three, and IETF Review, for 121 the last, are appropriate for these one-byte code points because of 122 their scarcity. 124 This document proposes no changes to the EC Curve Type, EC Point 125 Format registries , and Supported Groups Registry (see 126 [I-D.ietf-tls-rfc4492bis]). 128 The lengthy updates header is a result of requests for IANA to refer 129 to this draft in addition to the original RFC that defined a 130 particular registry. 132 3. Add "TLS" to Registry Names 134 IANA is to update the names of the following registries to add "TLS" 135 to for consistency with the other TLS-related extensions: 137 o Application-Layer Protocol Negotiation (ALPN) Protocol IDs, 139 o ExtensionType Values, 141 o Heartbeat Message Types, 143 o Heartbeat Modes, and 144 o Supported Groups. 146 IANA is also to add a reference to this document for the registry 147 whose names have been updated as a result of the above change. 149 NOTE: Henceforth in this document the registries will be referred to 150 using the "TLS" prefix. 152 4. Aligning with RFC 5226 154 Many of the TLS-related IANA registries were defined prior to 155 [RFC5226] where "IETF Consensus" was used instead of the 156 RFC5226-defined "IETF Review". To align with the new terminology, 157 IANA is to update to use "IETF Review" in place of "IETF Consensus" 158 in the following registries: 160 o TLS Authorization Data Formats 162 o TLS Supplemental Data Formats (SupplementalDataType) 164 NOTE: Not that this is not a universal change as some registries 165 originally defined with "IETF Consensus" are undergoing other changes 166 either as a result of this document or [I-D.ietf-tls-rfc4492bis]. 168 5. TLS ExtensionType Values 170 IANA is to update the TLS ExtensionType Values registry as follows: 172 o Change the registry policy to: 174 Values with the first byte in the range 0-254 (decimal) are 175 assigned via Specification Required [RFC5226]. Values with the 176 first byte 255 (decimal) are reserved for Private Use [RFC5226]. 178 o Update the "References" to also refer to this document. 180 o Add the following note: 182 Note: Experts are to verify that there is in fact a publicly 183 available standard. 185 6. TLS Cipher Suite Registry 187 IANA is to update the TLS Cipher Suite registry as follows: 189 o Change the registry policy to: 191 Values with the first byte in the range 0-254 (decimal) are 192 assigned via Specification Required [RFC5226]. Values with the 193 first byte 255 (decimal) are reserved for Private Use [RFC2434]. 195 o Add a "Recommended" column to the cipher suite registry. The 196 cipher suites that follow in the two tables are marked as "Yes". 197 All other cipher suites are marked as "No". 199 NOTE: The cipher suites that follow are standards track server- 200 authenticated (and optionally client-authenticated) cipher suites 201 which are currently available in TLS 1.2. The notable exception are 202 the ECDHE AES GCM cipher suites which are not yet standards track 203 prior to the publication of this specification, but this document 204 promotes those 4 cipher suites to standards track (see TO-DO insert 205 reference). 207 Cipher Suite Name | Value 208 ----------------------------------------------+------------ 209 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | {0x00,0x9E} 210 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | {0x00,0x9F} 211 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2B} 212 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x2C} 213 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2F} 214 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x30} 215 TLS_DHE_RSA_WITH_AES_128_CCM | {0xC0,0x9E} 216 TLS_DHE_RSA_WITH_AES_256_CCM | {0xC0,0x9F} 217 TLS_DHE_RSA_WITH_AES_128_CCM_8 | {0xC0,0xA2} 218 TLS_DHE_RSA_WITH_AES_256_CCM_8 | {0xC0,0xA3} 219 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA8} 220 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA9} 221 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAA} 223 NOTE: The cipher suites that follow are standards track ephemeral 224 pre-shared key cipher suites which are available in TLS 1.2. 225 [RFC6655] is inconsistent with respect to the ordering of components 226 within PSK AES CCM cipher suite names; those names are used here 227 without modification. 229 Cipher Suite Name | Value 230 ----------------------------------------------+------------ 231 TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | {0x00,0xAA} 232 TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | {0x00,0xAB} 233 TLS_DHE_PSK_WITH_AES_128_CCM | {0xC0,0xA6} 234 TLS_DHE_PSK_WITH_AES_256_CCM | {0xC0,0xA7} 235 TLS_PSK_DHE_WITH_AES_128_CCM_8 | {0xC0,0xAA} 236 TLS_PSK_DHE_WITH_AES_256_CCM_8 | {0xC0,0xAB} 237 TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | {TBD} 238 TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | {TBD} 239 TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 | {TBD} 240 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | {TBD} 241 TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 | {TBD} 242 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAC} 243 TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAD} 245 o Add the following: 247 Notes: 249 Although TLS 1.3 uses the same cipher suite space as previous 250 versions of TLS, TLS 1.3 cipher suites are defined differently, 251 only specifying the symmetric ciphers, and cannot it be used for 252 TLS 1.2. Similarly, TLS 1.2 and lower cipher suites cannot be 253 used with TLS 1.3. 255 Cipher suites marked as "Yes" are those allocated via Standards 256 Track RFCs. Cipher suites marked as "No" are not; cipher suites 257 marked "No" range from "good" to "bad" from a cryptographic 258 standpoint. 260 The designated expert [RFC5226] only ensures that the 261 specification is publically available. 263 7. TLS ClientCertificateType Identifiers 265 IANA is to update the TLS ClientCertificateType Identifiers registry 266 as follows: 268 o Change the registry policy to: 270 Values in the range 0-223 are assigned via Specification Required 271 [RFC5226]. Values 224-255 are are reserved for Private Use. 273 o Add the following: 275 Note: 277 The designated expert [RFC5226] only ensures that the 278 specification is publically available. 280 8. New Session Ticket TLS Handshake Message Type 282 To align with TLS implementations and to align the naming 283 nomenclature for other Handshake message types, IANA is to rename 284 entry 4 in the TLS HandshakeType registry to "new_session_ticket 285 (renamed from NewSessionTicket)". IANA is to also add a reference to 286 this document in the Reference column for entry 4 in the TLS 287 HandshakeType registry. 289 9. Session Ticket TLS Extension 291 The nomenclature for the registry entries in the TLS ExtensionType 292 Values registry correspond to the presentation language field name 293 except for entry 35. To ensure that the values in the registry are 294 consistently identified in the registry, IANA is to rename entry 35 295 to "session_ticket (renamed from "SessionTicket TLS")". 297 10. TLS Exporter Label Registry 299 IANA is to add the following note to the TLS Exporter Label Registry: 301 {{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. 303 11. Add Missing Item to TLS Alert Registry 305 IANA is to add the following entry to the TLS Alert Registry (the 306 entry was omitted from the IANA instructions in [RFC7301]): 308 120 no_application_protocol Y [RFC7301] 310 12. Orphaned Extensions 312 To make it clear that (D)TLS 1.3 has orphaned certain extensions 313 (i.e., they are only applicable to version of (D)TLS prior to 1.3), 314 IANA is to add the following to the TLS ExtensionType Values 315 registry: 317 Note: 319 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 are not applicable to TLS 1.3. 321 13. Orphaned Registries 323 To make it clear that (D)TLS 1.3 has orphaned certain registries 324 (i.e., they are only applicable to version of (D)TLS protocol 325 versions prior to 1.3), IANA is to: 327 o Add the following to the TLS Compression Method Identifiers 328 registry [RFC3749]: 330 Note: 332 Value 0 (NULL) is the only value in this registry applicable to 333 (D)TLS protocol version 1.3 or later. 335 o Add the following to the TLS Hash Algorithm [RFC5246] and TLS 336 SignatureAlgorithm registries [RFC5246]: 338 Note: 340 The values in this registry are only applicable to (D)TLS protocol 341 versions prior to 1.3. 343 o Update the "References" in the TLS Compression Method Identifiers, 344 TLS Hash Algorithm [RFC5246] and TLS SignatureAlgorithm registries 345 to also refer to this document. 347 14. Security Considerations 349 TBSL 351 15. IANA Considerations 353 This document is entirely about changes to TLS-related IANA 354 registries. 356 16. References 358 16.1. Normative References 360 [I-D.ietf-tls-tls13] 361 Rescorla, E., "The Transport Layer Security (TLS) Protocol 362 Version 1.3", draft-ietf-tls-tls13-14 (work in progress), 363 July 2016. 365 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 366 Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 367 2004, . 369 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 370 Data", RFC 4680, DOI 10.17487/RFC4680, October 2006, 371 . 373 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 374 "Transport Layer Security (TLS) Session Resumption without 375 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 376 January 2008, . 378 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 379 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 380 DOI 10.17487/RFC5226, May 2008, 381 . 383 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 384 (TLS) Protocol Version 1.2", RFC 5246, 385 DOI 10.17487/RFC5246, August 2008, 386 . 388 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 389 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 390 March 2010, . 392 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 393 Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878, 394 May 2010, . 396 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 397 Layer Security (TLS) and Datagram Transport Layer Security 398 (DTLS) Heartbeat Extension", RFC 6520, 399 DOI 10.17487/RFC6520, February 2012, 400 . 402 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 403 "Transport Layer Security (TLS) Application-Layer Protocol 404 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 405 July 2014, . 407 16.2. Informative References 409 [I-D.ietf-tls-rfc4492bis] 410 Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 411 Curve Cryptography (ECC) Cipher Suites for Transport Layer 412 Security (TLS) Versions 1.2 and Earlier", draft-ietf-tls- 413 rfc4492bis-08 (work in progress), July 2016. 415 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 416 IANA Considerations Section in RFCs", RFC 2434, 417 DOI 10.17487/RFC2434, October 1998, 418 . 420 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 421 Multiple Certificate Status Request Extension", RFC 6961, 422 DOI 10.17487/RFC6961, June 2013, 423 . 425 Authors' Addresses 427 Joe Salowey 428 Tableau Software 430 Email: joe@salowey.net 432 Sean Turner 433 sn3rd 435 Email: sean@sn3rd.com