TLS Application-Layer Protocol Settings ExtensionGooglevasilvv@google.com
General
TLS Working GroupInternet-DraftThis document describes a Transport Layer Security (TLS) extension for
negotiating application-layer protocol settings (ALPS) within the TLS handshake.
Any application-layer protocol operating over TLS can use this mechanism to
indicate its settings to the peer in parallel with the TLS handshake
completion.Discussion VenuesDiscussion of this document takes place on the
TLS Working Group mailing list (tls@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/tls/.Source for this draft and an issue tracker can be found at
https://github.com/vasilvv/tls-alps.IntroductionAn application-layer protocol often starts with both parties negotiating
parameters under which the protocol operates; for instance, HTTP/2
uses a SETTINGS frame to exchange the list of protocol parameters supported by
each endpoint. This is usually achieved by waiting for TLS handshake
to complete and then performing the application-layer handshake
within the application protocol itself. This approach, despite its apparent
simplicity at first, has multiple drawbacks:
While the server is technically capable of sending configuration to the peer
as soon as it sends its Finished message, most TLS implementations do not
allow any application data to be sent until the Finished message is received
from the client. This adds an extra round-trip to the time of when the
server settings are available to the client.
In QUIC, any settings delivered within the application layer can arrive
after other application data; thus, the application has to operate under the
assumption that peer's settings are not always available.
If the application needs to be aware of the server settings in order to send
0-RTT data, the application has to manually integrate with the TLS stack to
associate the settings with TLS session tickets.
This document introduces a new TLS extension, application_settings, that
allows applications to exchange settings within the TLS handshake. Through
doing that, the settings can be made available to the application as soon as the
handshake completes, and can be associated with TLS session tickets
automatically at the TLS layer. This approach allows the application protocol
to be designed with the assumption that it has access to the peer's settings
whenever it is able to send data.Conventions and DefinitionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14
when, and only when, they appear in all capitals, as shown here.SemanticsSettings are defined to be an opaque blob that is specified by the application
when initiating a TLS connection. The settings are meant to be a declaration
of the protocol parameters supported by the sender. While in this version of
the extension the server settings are always sent first, this may change in
future versions; thus, the application MUST NOT vary client settings based on
the ones received from the server.ALPS is not a negotiation mechanism: there is no notion of rejecting peer's
settings, and the settings are not responses to one another. Nevertheless, it
is possible for parties to coordinate behavior by, for instance, requiring a
certain parameter to be present in both client and server settings. This makes
ALPS mechanism similar to QUIC transport parameters
or HTTP/2 SETTINGS frame , but puts it
in contrast to similar mechanisms in TLS.Settings are exchanged as a part of the TLS handshake that is encrypted with the
handshake keys. When the server settings are sent, the identity of the client
has not been yet established; therefore, an application MUST NOT use ALPS if it
requires the settings to be available only to the authenticated clients.The ALPS model provides applications with a guarantee that the settings are
available before any application data can be written. Note that this implies
that when the full handshake is performed, the server can no longer send data
immediately after sending its Finished message; it has to wait for the client
to respond with its settings. This may negatively impact the latency of the
protocols where the server sends the first message, however it should be noted
that sending application data before receiving has not been widely supported by
TLS implementations, nor has it been allowed in situations when establishing
client identity through TLS is required.ALPS can only be used in conjunction with Application-Layer Protocol
Negotiation: the client MUST offer ALPN if advertising ALPS
support, and the server MUST NOT reply with ALPS unless it is also negotiating
ALPN. The ALPS payload is protocol-dependent, and as such it MUST be specified
with respect to a selected ALPN.For application protocols that support 0-RTT data, both the client and the
server have to remember the settings provided by the both sides during the
original connection. If the client sends 0-RTT data and the server accepts it,
the ALPS values SHALL be the same values as were during the original
connection. In all other cases (including session resumption that does not
result in server accepting early data), new ALPS values SHALL be negotiated.If the client wishes to send different client settings for the 0-RTT session,
it MUST NOT offer 0-RTT. Conversely, if the server would send different server
settings, it MUST reject 0-RTT. Note that the ALPN itself is similarly
required to match the one in the original connection, thus the settings
only need to be remembered or checked for a single application protocol.Wire protocolALPS is only supported in TLS version 1.3 or later, as the earlier versions do
not provide any confidentiality protections for the handshake data. The
exchange is performed in three steps:
The client sends an extension in ClientHello that enumerates all ALPN values
for which ALPS is supported.
The server sends an encrypted extension containing the server settings.
The client sends a new handshake message containing the client settings.
A TLS client can enable ALPS by specifying an application_settings extension.
The value of the extension_data field for the ALPS extension SHALL be a
ApplicationSettingsSupport struct:;
} ApplicationSettingsSupport;
]]>Here, the supported_protocols field indicates the names of the protocols (as
defined in ) for which ALPS exchange is supported; this is necessary
for the situations when the client offers multiple ALPN values but only supports
ALPS in some of them.If the server chooses an ALPN value for which the client has offered ALPS
support, the server MAY send an application_settings extension in the
EncryptedExtensions. The value of the extension_data field in that case SHALL
be an opaque blob containing the server settings as specified by the application
protocol.If the client receives an EncryptedExtensions message containing an
application_settings extension from the server, after receiving server's
Finished message it MUST send a ClientApplicationSettings handshake message
before sending the Finished message:;
} ClientApplicationSettings;
]]>The value of the application_settings field SHALL be an opaque blob containing
the client settings as specified by the application protocol. If the client is
providing a client certificate, the ClientApplicationSettings message MUST
precede the Certificate message sent by the client.If the ClientApplicationSettings message is sent or received during the
handshake, it SHALL be appended to the end of client's Handshake Context
context as defined in Section 4.4 of . In addition, for
Post-Handshake Handshake Context, it SHALL be appended after the client
Finished message.When performing session resumption with 0-RTT data, the settings are carried
over from the original connection. The server SHALL send an empty
application_settings extension if it accepts 0-RTT, and the client SHALL NOT
send a ClientApplicationSettings message.Security ConsiderationsALPS is protected using the handshake keys, which are the secret keys derived
as a result of (EC)DHE between the client and the server.In order to ensure that the ALPS values are authenticated, the TLS
implementation MUST NOT reveal the contents of peer's ALPS until peer's
Finished message is received, with exception of cases where the ALPS has been
carried over from the previous connection.IANA ConsiderationsIANA will update the "TLS ExtensionType Values" registry to include
application_settings with the value of TBD; the list of messages in which
this extension may appear is CH, SH.IANA will also update the "TLS HandshakeType" registry to include
client_application_settings message with value TBD, and "DTLS-OK" set to "Y".ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Transport Layer Security (TLS) Application-Layer Protocol Negotiation ExtensionThis document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.Informative ReferencesHypertext Transfer Protocol Version 2 (HTTP/2)This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.QUIC: A UDP-Based Multiplexed and Secure TransportThis document defines the core of the QUIC transport protocol. Accompanying documents describe QUIC's loss detection and congestion control and the use of TLS for key negotiation. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-transport.AcknowledgmentsThis document has benefited from contributions and suggestions from David
Benjamin, Nick Harper, David Schinazi, Renjie Tang and many others.