idnits 2.17.1 draft-ietf-tls-applayerprotoneg-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 3, 2014) is 3705 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: 'ChangeCipherSpec' is mentioned on line 186, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-10 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Friedl 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track A. Popov 5 Expires: September 4, 2014 Microsoft Corp. 6 A. Langley 7 Google Inc. 8 E. Stephan 9 Orange 10 March 3, 2014 12 Transport Layer Security (TLS) Application Layer Protocol Negotiation 13 Extension 14 draft-ietf-tls-applayerprotoneg-05 16 Abstract 18 This document describes a Transport Layer Security (TLS) extension 19 for application layer protocol negotiation within the TLS handshake. 20 For instances in which the TLS connection is established over a well 21 known TCP or UDP port not associated with the desired application 22 layer protocol, this extension allows the application layer to 23 negotiate which protocol will be used within the TLS connection. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 4, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Application Layer Protocol Negotiation . . . . . . . . . . . 3 62 3.1. The Application Layer Protocol Negotiation Extension . . 3 63 3.2. Protocol Selection . . . . . . . . . . . . . . . . . . . 5 64 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Increasingly, application layer protocols are encapsulated in the TLS 76 security protocol [RFC5246]. This encapsulation enables applications 77 to use the existing, secure communications links already present on 78 port 443 across virtually the entire global IP infrastructure. 80 When multiple application protocols are supported on a single server- 81 side port number, such as port 443, the client and the server need to 82 negotiate an application protocol for use with each connection. It 83 is desirable to accomplish this negotiation without adding network 84 round-trips between the client and the server, as each round-trip 85 will degrade an end-user's experience. Further, it would be 86 advantageous to allow certificate selection based on the negotiated 87 application protocol. 89 This document specifies a TLS extension which permits the application 90 layer to negotiate protocol selection within the TLS handshake. This 91 work was requested by the HTTPbis WG to address the negotiation of 92 HTTP version ([RFC2616], [I-D.ietf-httpbis-http2]) over TLS, however 93 ALPN facilitates negotiation of arbitrary application layer 94 protocols. 96 With ALPN, the client sends the list of supported application 97 protocols as part of the TLS ClientHello message. The server chooses 98 a protocol and sends the selected protocol as part of the TLS 99 ServerHello message. The application protocol negotiation can thus 100 be accomplished within the TLS handshake, without adding network 101 round-trips, and allows the server to associate a different 102 certificate with each application protocol, if desired. 104 2. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Application Layer Protocol Negotiation 112 3.1. The Application Layer Protocol Negotiation Extension 114 A new extension type ("application_layer_protocol_negotiation(16)") 115 is defined and MAY be included by the client in its "ClientHello" 116 message. 118 enum { 119 application_layer_protocol_negotiation(16), (65535) 120 } ExtensionType; 122 The "extension_data" field of the 123 ("application_layer_protocol_negotiation(16)") extension SHALL 124 contain a "ProtocolNameList" value. 126 opaque ProtocolName<1..2^8-1>; 128 struct { 129 ProtocolName protocol_name_list<2..2^16-1> 130 } ProtocolNameList; 132 "ProtocolNameList" contains the list of protocols advertised by the 133 client, in descending order of preference. Protocols are named by 134 IANA registered, opaque, non-empty byte strings, as described further 135 in Section 6 "IANA Considerations" of this document. Empty strings 136 MUST NOT be included and byte strings MUST NOT be truncated . 138 Servers that receive a client hello containing the 139 "application_layer_protocol_negotiation" extension, MAY return a 140 suitable protocol selection response to the client. The server will 141 ignore any protocol name that it does not recognize. A new 142 ServerHello extension type 143 ("application_layer_protocol_negotiation(16)") MAY be returned to the 144 client within the extended ServerHello message. The "extension_data" 145 field of the ("application_layer_protocol_negotiation(16)") extension 146 is structured the same as described above for the client 147 "extension_data", except that the "ProtocolNameList" MUST contain 148 exactly one "ProtocolName". 150 Therefore, a full handshake with the 151 "application_layer_protocol_negotiation" extension in the ClientHello 152 and ServerHello messages has the following flow (contrast with 153 section 7.3 of [RFC5246]): 155 Client Server 157 ClientHello --------> ServerHello 158 (ALPN extension & (ALPN extension & 159 list of protocols) selected protocol) 160 Certificate* 161 ServerKeyExchange* 162 CertificateRequest* 163 <-------- ServerHelloDone 164 Certificate* 165 ClientKeyExchange 166 CertificateVerify* 167 [ChangeCipherSpec] 168 Finished --------> 169 [ChangeCipherSpec] 170 <-------- Finished 171 Application Data <-------> Application Data 173 Figure 1 175 An abbreviated handshake with the 176 "application_layer_protocol_negotiation" extension has the following 177 flow: 179 Client Server 181 ClientHello --------> ServerHello 182 (ALPN extension & (ALPN extension & 183 list of protocols) selected protocol) 184 [ChangeCipherSpec] 185 <-------- Finished 186 [ChangeCipherSpec] 187 Finished --------> 188 Application Data <-------> Application Data 190 Figure 2 192 Unlike many other TLS extensions, this extension does not establish 193 properties of the session, only of the connection. When session 194 resumption or session tickets [RFC5077] are used, the previous 195 contents of this extension are irrelevant and only the values in the 196 new handshake messages are considered. 198 3.2. Protocol Selection 200 It is expected that a server will have a list of protocols that it 201 supports, in preference order, and will only select a protocol if the 202 client supports it. In that case, the server SHOULD select the most 203 highly preferred protocol it supports which is also advertised by the 204 client. In the event that the server supports no protocols that the 205 client advertises, then the server SHALL respond with a fatal 206 "no_application_protocol" alert. 208 enum { 209 no_application_protocol(120), 210 (255) 211 } AlertDescription; 213 The protocol identified in the 214 "application_layer_protocol_negotiation" extension type in the 215 ServerHello SHALL be definitive for the connection, until 216 renegotiated. The server SHALL NOT respond with a selected protocol 217 and subsequently use a different protocol for application data 218 exchange. 220 4. Design Considerations 222 The ALPN extension is intended to follow the typical design of TLS 223 protocol extensions. Specifically, the negotiation is performed 224 entirely within the client/server hello exchange in accordance with 225 established TLS architecture. The 226 "application_layer_protocol_negotiation" ServerHello extension is 227 intended to be definitive for the connection (until the connection is 228 renegotiated) and is sent in plaintext to permit network elements to 229 provide differentiated service for the connection when the TCP or UDP 230 port number is not definitive for the application layer protocol to 231 be used in the connection. By placing ownership of protocol 232 selection on the server, ALPN facilitates scenarios in which 233 certificate selection or connection rerouting may be based on the 234 negotiated protocol. 236 Finally, by managing protocol selection in the clear as part of the 237 handshake, ALPN avoids introducing false confidence with respect to 238 the ability to hide the negotiated protocol in advance of 239 establishing the connection. If hiding the protocol is required, 240 then renegotiation after connection establishment, which would 241 provide true TLS security guarantees, would be a preferred 242 methodology. 244 5. Security Considerations 246 The ALPN extension does not impact the security of TLS session 247 establishment or application data exchange. ALPN serves to provide 248 an externally visible marker for the application layer protocol 249 associated with the TLS connection. Historically, the application 250 layer protocol associated with a connection could be ascertained from 251 the TCP or UDP port number in use. 253 Implementers and document editors who intend to extend the protocol 254 identifier registry by adding new protocol identifiers should 255 consider that in TLS versions 1.2 and below the client sends these 256 identifiers in the clear, and should also consider that for at least 257 the next decade, it is expected that browsers would normally use 258 these earlier versions of TLS in the initial ClientHello. 260 Care must be taken when such identifiers may leak personally 261 identifiable information, or when such leakage may lead to profiling, 262 or to leaking of sensitive information. If any of these apply to 263 this new protocol identifier, the identifier SHOULD NOT be used in 264 TLS configurations where it would be visible in the clear, and 265 documents specifying such protocol identifiers SHOULD recommend 266 against such unsafe use. 268 6. IANA Considerations 270 The IANA has updated its Registry of TLS ExtensionType Values to 271 include the following entry: 273 16 application_layer_protocol_negotiation 275 This document establishes a registry for protocol identifiers 276 entitled "Application Layer Protocol Negotiation (ALPN) Protocol IDs" 277 under the existing "Transport Layer Security (TLS)" heading. 279 Entries in this registry require the following fields: 281 o Protocol: The name of the protocol. 283 o Identification Sequence: The precise set of octet values that 284 identifies the protocol. This could be the UTF-8 encoding 285 [RFC3629] of the protocol name. 287 o Specification: A reference to a specification that defines the 288 protocol. 290 This registry operates under the "Expert Review" policy as defined in 291 [RFC5226]. The designated expert is advised to encourage the 292 inclusion of a reference to a permanent and readily available 293 specification that enables the creation of interoperable 294 implementations of the identified protocol. 296 An initial set of registrations for this registry follows: 298 Protocol: HTTP/1.1 300 Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 301 ("http/1.1") 303 Specification: http://tools.ietf.org/html/rfc2616 305 Protocol: SPDY/1 307 Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1") 309 Specification: http://dev.chromium.org/spdy/spdy-protocol/spdy- 310 protocol-draft1 312 Protocol: SPDY/2 314 Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x32 ("spdy/2") 316 Specification: http://dev.chromium.org/spdy/spdy-protocol/spdy- 317 protocol-draft2 319 Protocol: SPDY/3 321 Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3") 323 Specification: http://dev.chromium.org/spdy/spdy-protocol/spdy- 324 protocol-draft3 326 7. Acknowledgements 328 This document benefitted specifically from the NPN extension draft 329 authored by Adam Langley and from discussions with Tom Wesselman and 330 Cullen Jennings both of Cisco. 332 8. References 334 8.1. Normative References 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, March 1997. 339 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 340 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 341 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 343 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 344 10646", STD 63, RFC 3629, November 2003. 346 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 347 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 348 May 2008. 350 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 351 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 353 8.2. Informative References 355 [I-D.ietf-httpbis-http2] 356 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 357 Protocol version 2", draft-ietf-httpbis-http2-10 (work in 358 progress), February 2014. 360 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 361 "Transport Layer Security (TLS) Session Resumption without 362 Server-Side State", RFC 5077, January 2008. 364 Authors' Addresses 366 Stephan Friedl 367 Cisco Systems, Inc. 368 170 West Tasman Drive 369 San Jose, CA 95134 370 USA 372 Phone: (720)562-6785 373 Email: sfriedl@cisco.com 374 Andrei Popov 375 Microsoft Corp. 376 One Microsoft Way 377 Redmond, WA 98052 378 USA 380 Email: andreipo@microsoft.com 382 Adam Langley 383 Google Inc. 384 USA 386 Email: agl@google.com 388 Emile Stephan 389 Orange 390 2 avenue Pierre Marzin 391 Lannion F-22307 392 France 394 Email: emile.stephan@orange.com