Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension

Currently, the Next Protocol Negotiation extension (NPN) is used to establish a SPDY protocol session within a TLS RFC 5246 session on port 443. NPN is not specific to SPDY and can be used to negotiate sessions for a wide variety of protocols within the TLS handshake. NPN seeks to provide a reliable mechanism for application developers to establish secure sessions for arbitrary protocols without interference from firewalls, HTTP proxies and MITM proxies. It addresses this goal by introducing a protocol negotiation process into the TLS handshake under the constraints that no additional roundtrips be added to the handshake and that the final protocol selection be opaque to the network carrying the TLS session. Within the NPN extension, it is the server that first generates and transmits an offer of supported protocols to the client. The offer is sent as part of the TLS ServerHello message before the [ChangeCipherSpec] subprotocol has been started, therefore the list of protocols supported by the server is transmitted in plaintext. The client chooses a protocol which may or may not appear in the offer from the server and then responds with the definitive protocol selection answer. The client response is sent after the [ChangeCipherSpec] subprotocol has been initiated, so the protocol selected is encrypted in the client response. In many other application layer protocol negotiation processes, it is the client that first sends an offer of protocols it supports to the server. The server then selects the protocol to be used in the session and includes this answer in the response. RFC 3264 describes a SDP based offer/answer model which is not proscriptive in terms of which party generates the offer, however in practice it is typically the client generating the offer and the server replying with the answer. This permits the server to act as the definitive entity for selection of the application layer protocol. This draft proposes an alternative formulation of the NPN protocol which 1) brings the offer/answer negotiation into alignment with the majority of other application layer protocol negotiation standards, 2) allows certificate selection based on the application protocol and 3) makes the definitive protocol selection answer from the server visible to the network, when the parties so desire.

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 RFC 2119.

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. Implementations MUST ensure that an empty string is not included and that no byte strings are truncated. Experimental protocol names, which are not registered by IANA, will start with the following sequence of bytes: 0x65, 0x78, 0x70 ("exp"). Servers that receive a client hello 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 SHALL be structured the same as described above for the client "extension_data", except that the "ProtocolNameList" MUST contain exactly one "ProtocolName". The additional content associated with this extension MUST be included in the hash calculations associated with the "Finished" messages. 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 RFC 5246):

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 ]]> 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 RFC 5077 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 it supports which 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 "no_application_protocol" fatal alert is only defined for the "application_layer_protocol_negotiation" extension and MUST NOT be sent unless the server has received a ClientHello message containing this extension. The protocol identified in the "application_layer_protocol_negotiation" extension type in the ServerHello SHALL be definitive for the connection. 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 established TLS architecture. The "application_layer_protocol_negotiation" ServerHello extension is intended to be definitive for the connection and is sent in plaintext to permit network elements to provide differentiated service for the connection when the TCP/IP 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 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. A namespace will be assigned for experimental protocols, comprising byte strings which start with the following sequence of bytes: 0x65, 0x78, 0x70 ("exp"). Assignments in this namespace do not need IANA registration.

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/IP port number in use. Encrypting the selected application protocol information and sending it before the Finished messages are exchanged, as done in NPN, does not provide confidentiality guarantees due to the possibility of man-in-the-middle attacks.

The IANA has updated its Registry of TLS ExtensionType Values to include the following entry: - 16 application_layer_protocol_negotiation This document also requires the IANA to create a registry of Application Layer Protocol Negotiation protocol byte strings, initially containing the following entries: - "http/1.1": HTTP/1.1 [RFC2616]; - "http/2.0": HTTP/2.0; - "spdy/1": (obsolete) SPDY version 1; - "spdy/2": SPDY version 2; - "spdy/3": SPDY version 3. We propose that this new registry be created in a new page entitled: "Application Layer Protocol Negotiation (ALPN) Protocol IDs" beneath the existing heading of "Transport Layer Security (TLS)".

This document benefitted specifically from the NPN extension draft authored by Adam Langley of Google and from discussions with Tom Wesselman and Cullen Jennings both of Cisco.