Transport Layer Security (TLS) Application&nbhy;Layer Protocol Negotiation Extension

Increasingly, application-layer protocols are encapsulated in the TLS protocol . This encapsulation enables applications to use the existing, secure communications links already present on port 443 across virtually the entire global IP infrastructure. When multiple application protocols are supported on a single server-side port number, such as port 443, the client and the server need to negotiate an application protocol for use with each connection. It is desirable to accomplish this negotiation without adding network round-trips between the client and the server, as each round-trip will degrade an end-user's experience. Further, it would be advantageous to allow certificate selection based on the negotiated application protocol. This document specifies a TLS extension that permits the application layer to negotiate protocol selection within the TLS handshake. This work was requested by the HTTPbis WG to address the negotiation of HTTP/2 () over TLS; however, ALPN facilitates negotiation of arbitrary application-layer protocols. With ALPN, the client sends the list of supported application protocols as part of the TLS ClientHello message. The server chooses a protocol and sends the selected protocol as part of the TLS ServerHello message. The application protocol negotiation can thus be accomplished within the TLS handshake, without adding network round-trips, and allows the server to associate a different certificate with each application protocol, if desired.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

A new extension type ("application_layer_protocol_negotiation(16)") is defined and MAY be included by the client in its "ClientHello" message.

The "extension_data" field of the ("application_layer_protocol_negotiation(16)") extension SHALL contain a "ProtocolNameList" value.

; struct { ProtocolName protocol_name_list<2..2^16-1> } ProtocolNameList; ]]> "ProtocolNameList" contains the list of protocols advertised by the client, in descending order of preference. Protocols are named by IANA-registered, opaque, non-empty byte strings, as described further in ("IANA Considerations") of this document. Empty strings MUST NOT be included and byte strings MUST NOT be truncated. Servers that receive a ClientHello containing the "application_layer_protocol_negotiation" extension MAY return a suitable protocol selection response to the client. The server will ignore any protocol name that it does not recognize. A new ServerHello extension type ("application_layer_protocol_negotiation(16)") MAY be returned to the client within the extended ServerHello message. The "extension_data" field of the ("application_layer_protocol_negotiation(16)") extension is structured the same as described above for the client "extension_data", except that the "ProtocolNameList" MUST contain exactly one "ProtocolName". Therefore, a full handshake with the "application_layer_protocol_negotiation" extension in the ClientHello and ServerHello messages has the following flow (contrast with Section 7.3 of ):

ServerHello (ALPN extension & (ALPN extension & list of protocols) selected protocol) Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data ]]> * Indicates optional or situation-dependent messages that are not always sent. An abbreviated handshake with the "application_layer_protocol_negotiation" extension has the following flow:

ServerHello (ALPN extension & (ALPN extension & list of protocols) selected protocol) [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data ]]> Unlike many other TLS extensions, this extension does not establish properties of the session, only of the connection. When session resumption or session tickets are used, the previous contents of this extension are irrelevant, and only the values in the new handshake messages are considered.

It is expected that a server will have a list of protocols that it supports, in preference order, and will only select a protocol if the client supports it. In that case, the server SHOULD select the most highly preferred protocol that it supports and that is also advertised by the client. In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal "no_application_protocol" alert.

The protocol identified in the "application_layer_protocol_negotiation" extension type in the ServerHello SHALL be definitive for the connection, until renegotiated. The server SHALL NOT respond with a selected protocol and subsequently use a different protocol for application data exchange.

The ALPN extension is intended to follow the typical design of TLS protocol extensions. Specifically, the negotiation is performed entirely within the client/server hello exchange in accordance with the established TLS architecture. The "application_layer_protocol_negotiation" ServerHello extension is intended to be definitive for the connection (until the connection is renegotiated) and is sent in plaintext to permit network elements to provide differentiated service for the connection when the TCP or UDP port number is not definitive for the application-layer protocol to be used in the connection. By placing ownership of protocol selection on the server, ALPN facilitates scenarios in which certificate selection or connection rerouting may be based on the negotiated protocol. Finally, by managing protocol selection in the clear as part of the handshake, ALPN avoids introducing false confidence with respect to the ability to hide the negotiated protocol in advance of establishing the connection. If hiding the protocol is required, then renegotiation after connection establishment, which would provide true TLS security guarantees, would be a preferred methodology.

The ALPN extension does not impact the security of TLS session establishment or application data exchange. ALPN serves to provide an externally visible marker for the application-layer protocol associated with the TLS connection. Historically, the application-layer protocol associated with a connection could be ascertained from the TCP or UDP port number in use. Implementers and document editors who intend to extend the protocol identifier registry by adding new protocol identifiers should consider that in TLS versions 1.2 and below the client sends these identifiers in the clear. They should also consider that, for at least the next decade, it is expected that browsers would normally use these earlier versions of TLS in the initial ClientHello. Care must be taken when such identifiers may leak personally identifiable information, or when such leakage may lead to profiling or to leaking of sensitive information. If any of these apply to this new protocol identifier, the identifier SHOULD NOT be used in TLS configurations where it would be visible in the clear, and documents specifying such protocol identifiers SHOULD recommend against such unsafe use.

The IANA has updated its "ExtensionType Values" registry to include the following entry: 16 application_layer_protocol_negotiation This document establishes a registry for protocol identifiers entitled "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" under the existing "Transport Layer Security (TLS) Extensions" heading. Entries in this registry require the following fields: Protocol: The name of the protocol. Identification Sequence: The precise set of octet values that identifies the protocol. This could be the UTF-8 encoding of the protocol name. Reference: A reference to a specification that defines the protocol. This registry operates under the "Expert Review" policy as defined in . The designated expert is advised to encourage the inclusion of a reference to a permanent and readily available specification that enables the creation of interoperable implementations of the identified protocol. The initial set of registrations for this registry is as follows: HTTP/1.1 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1") SPDY/1 0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1") http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1 SPDY/2 0x73 0x70 0x64 0x79 0x2f 0x32 ("spdy/2") http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2 SPDY/3 0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3") http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3

This document benefitted specifically from the Next Protocol Negotiation (NPN) extension document authored by Adam Langley and from discussions with Tom Wesselman and Cullen Jennings, both of Cisco.