< draft-vvv-tls-alps-00.txt		draft-vvv-tls-alps-01.txt >
	TLS Working Group V. Vasiliev		TLS Working Group D. Benjamin
	Internet-Draft Google		Internet-Draft V. Vasiliev
	Intended status: Standards Track 26 June 2020		Intended status: Standards Track Google
	Expires: 28 December 2020		Expires: 25 March 2021 21 September 2020
	TLS Application-Layer Protocol Settings Extension		TLS Application-Layer Protocol Settings Extension
	draft-vvv-tls-alps-00		draft-vvv-tls-alps-01
	Abstract		Abstract
	This document describes a Transport Layer Security (TLS) extension		This document describes a Transport Layer Security (TLS) extension
	for negotiating application-layer protocol settings (ALPS) within the		for negotiating application-layer protocol settings (ALPS) within the
	TLS handshake. Any application-layer protocol operating over TLS can		TLS handshake. Any application-layer protocol operating over TLS can
	use this mechanism to indicate its settings to the peer in parallel		use this mechanism to indicate its settings to the peer in parallel
	with the TLS handshake completion.		with the TLS handshake completion.
	Discussion Venues		Discussion Venues
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 28 December 2020.		This Internet-Draft will expire on 25 March 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3		2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
	3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Wire protocol . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Wire Protocol . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4.1. Client Encrypted Extensions . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		4.2. 0-RTT Handshakes . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7.2. Informative References . . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8		7.1. Normative References . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		7.2. Informative References . . . . . . . . . . . . . . . . . 8
			Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	An application-layer protocol often starts with both parties		An application-layer protocol often starts with both parties
	negotiating parameters under which the protocol operates; for		negotiating parameters under which the protocol operates; for
	instance, HTTP/2 [RFC7540] uses a SETTINGS frame to exchange the list		instance, HTTP/2 [RFC7540] uses a SETTINGS frame to exchange the list
	of protocol parameters supported by each endpoint. This is usually		of protocol parameters supported by each endpoint. This is usually
	achieved by waiting for TLS handshake [RFC8446] to complete and then		achieved by waiting for TLS handshake [RFC8446] to complete and then
	performing the application-layer handshake within the application		performing the application-layer handshake within the application
	protocol itself. This approach, despite its apparent simplicity at		protocol itself. This approach, despite its apparent simplicity at
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 28 ¶
	sending application data before receiving has not been widely		sending application data before receiving has not been widely
	supported by TLS implementations, nor has it been allowed in		supported by TLS implementations, nor has it been allowed in
	situations when establishing client identity through TLS is required.		situations when establishing client identity through TLS is required.
	ALPS can only be used in conjunction with Application-Layer Protocol		ALPS can only be used in conjunction with Application-Layer Protocol
	Negotiation: the client MUST offer ALPN [RFC7301] if advertising ALPS		Negotiation: the client MUST offer ALPN [RFC7301] if advertising ALPS
	support, and the server MUST NOT reply with ALPS unless it is also		support, and the server MUST NOT reply with ALPS unless it is also
	negotiating ALPN. The ALPS payload is protocol-dependent, and as		negotiating ALPN. The ALPS payload is protocol-dependent, and as
	such it MUST be specified with respect to a selected ALPN.		such it MUST be specified with respect to a selected ALPN.
	For application protocols that support 0-RTT data, both the client		4. Wire Protocol
	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.
	4. Wire protocol
	ALPS is only supported in TLS version 1.3 or later, as the earlier		ALPS is only supported in TLS version 1.3 or later, as the earlier
	versions do not provide any confidentiality protections for the		versions do not provide any confidentiality protections for the
	handshake data. The exchange is performed in three steps:		handshake data. The exchange is performed in three steps:
	1. The client sends an extension in ClientHello that enumerates all		1. The client sends an extension in ClientHello that enumerates all
	ALPN values for which ALPS is supported.		ALPN values for which ALPS is supported.
	2. The server sends an encrypted extension containing the server		2. The server sends an encrypted extension containing the server
	settings.		settings.
	3. The client sends a new handshake message containing the client		3. The client sends an encrypted extension containing the client
	settings.		settings.
	Client Server		Client Server
	ClientHello		ClientHello
	+ alpn		+ alpn
	+ alps -------->		+ alps -------->
	ServerHello		ServerHello
	{EncryptedExtensions}		{EncryptedExtensions}
	+ {alpn}		+ alpn
	+ {alps}		+ alps
	...		...
	<-------- {Finished}		<-------- {Finished}
	{ClientApplicationSettings}		{EncryptedExtensions}
			+ alps
	{Certificate*}		{Certificate*}
	{CertificateVerify*}		{CertificateVerify*}
	{Finished} -------->		{Finished} -------->
	+ Indicates extensions sent in the		+ Indicates extensions sent in the
	previously noted message.		previously noted message.
	{} Indicates messages protected using		{} Indicates messages protected using
	the handshake keys.		the handshake keys.
	* Indicates optional messages that are		* Indicates optional messages that are
	not related to ALPS.		not related to ALPS.
	Figure 1: ALPS exchange in a full TLS handshake		Figure 1: ALPS exchange in a full TLS handshake
	A TLS client can enable ALPS by specifying an "application_settings"		A TLS client can enable ALPS by specifying an "application_settings"
	extension. The value of the "extension_data" field for the ALPS		extension in the ClientHello message. The value of the
	extension SHALL be a ApplicationSettingsSupport struct:		"extension_data" field for this extension SHALL be a
			ApplicationSettingsSupport struct:
	struct {		struct {
	ProtocolName supported_protocols<2..2^16-1>;		ProtocolName supported_protocols<2..2^16-1>;
	} ApplicationSettingsSupport;		} ApplicationSettingsSupport;
	Here, the "supported_protocols" field indicates the names of the		Here, the "supported_protocols" field indicates the names of the
	protocols (as defined in [RFC7301]) for which ALPS exchange is		protocols (as defined in [RFC7301]) for which ALPS exchange is
	supported; this is necessary for the situations when the client		supported; this is necessary for the situations when the client
	offers multiple ALPN values but only supports ALPS in some of them.		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		If the server chooses an ALPN value for which the client has offered
	ALPS support, the server MAY send an "application_settings" extension		ALPS support, the server MAY negotiate ALPS by sending an
	in the EncryptedExtensions. The value of the "extension_data" field		"application_settings" extension in its EncryptedExtensions message.
	in that case SHALL be an opaque blob containing the server settings		The value of the "extension_data" field in that case SHALL be an
	as specified by the application protocol.		opaque blob containing the server settings as specified by the
			application protocol.
	If the client receives an EncryptedExtensions message containing an		If the client receives an EncryptedExtensions message containing an
	"application_settings" extension from the server, after receiving		"application_settings" extension from the server, it MUST send an
	server's Finished message it MUST send a ClientApplicationSettings		EncryptedExtensions message (see Section 4.1) containing an
	handshake message before sending the Finished message:		"application_extensions" extension. The value of the
			"extension_data" in this extension SHALL be an opaque blob containing
			the client settings as specified by the application protocol. A
			server which negotiates ALPS MUST abort the handshake with a
			"missing_extension" alert if the client's EncryptedExtensions is
			missing this extension.
	enum {		4.1. Client Encrypted Extensions
	client_application_settings(TBD), (255)
	} HandshakeType;
	struct {		This specification introduces the client EncryptedExtensions message.
	opaque application_settings<0..2^16-1>;		The format and HandshakeType code point match the server
	} ClientApplicationSettings;		EncryptedExtensions message. When sent, it is encrypted with
			handshake traffic keys and sent by the client after receiving the
			server Finished message and before the client sends the Certificate,
			CertificateVerify (if any), and Finished messages. It SHALL be
			appended to the Client Handshake Context, as defined Section 4.4 of
			[RFC8446]. It additionally SHALL be inserted after the server
			Finished in the Post-Handshake Handshake Context.
	The value of the "application_settings" field SHALL be an opaque blob		The client MUST send the EncryptedExtensions message if any extension
	containing the client settings as specified by the application		sent in the server EncryptedExtension message contains the CEE token
	protocol. If the client is providing a client certificate, the		in the TLS 1.3 column of the TLS ExtensionType Values registry.
	ClientApplicationSettings message MUST precede the Certificate		Otherwise, the client MUST NOT send the message. The server MUST
	message sent by the client.		abort the handshake with a "unexpected_message" alert if the message
			was sent or omitted incorrectly.
	If the ClientApplicationSettings message is sent or received during		The client MAY send an extension in the client EncryptedExtension
	the handshake, it SHALL be appended to the end of client's Handshake		message if that extension's entry in the registry contains a CEE
	Context context as defined in Section 4.4 of [RFC8446]. In addition,		token and the server EncryptedExtensions message included the
	for Post-Handshake Handshake Context, it SHALL be appended after the		extension. Otherwise, the client MUST NOT send the extension. If a
	client Finished message.		server receives an extension which does not meet this criteria, it
			MUST abort the handshake with an "unsupported_extension" alert.
	When performing session resumption with 0-RTT data, the settings are		Future extensions MAY use the client EncryptedExtensions message by
	carried over from the original connection. The server SHALL send an		including the CEE token in the TLS 1.3 registry. The above rules
	empty "application_settings" extension if it accepts 0-RTT, and the		ensure clients will not send EncryptedExtensions messages to older
	client SHALL NOT send a ClientApplicationSettings message.		servers, but will send EncryptedExtensions when some negotiated
			extension uses it.
			[[TODO: Section 4.6.1 of RFC8446 allows the server to predict the
			client Finished flight and send a ticket early. This is still
			possible with 0-RTT handshakes here because we omit rather than
			repeat the redudant ALPS information, but, in the general extension
			case, client EncryptedExtensions breaks this. Extension order is
			unpredictable. We should resolve this conflict, either by dropping
			that feature or removing flexibility here.]]
			4.2. 0-RTT Handshakes
			ALPS ensures settings are available before reading and writing
			application data, so handshakes which negotiate early data instead
			use application settings from the PSK. To use early data with a PSK,
			the TLS implementation MUST associate both client and server
			application settings, if any, with the PSK. For a resumption PSK,
			these values are determined from the original connection. For an
			external PSK, this values should be configured with it. Existing
			PSKs are considered to not have application settings.
			If the server accepts early data, the server SHALL NOT send an
			"application_settings" extension, and thus the client SHALL NOT send
			a "application_settings" extension in its EncryptedExtensions
			message. Unless the server has sent some other extension which uses
			client EncryptedExtensions, the client SHALL NOT send an
			EncryptedExtensions message. Instead, the connection implicitly uses
			the PSK's application settings, if any.
			If the server rejects early data, application settings are negotiated
			independently of the PSK, as if early data were not offered.
			If the client wishes to send different client settings for the
			connection, it MUST NOT offer 0-RTT. Conversely, if the server
			wishes to use 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. Implementations are
			RECOMMENDED to first determine the desired application protocol and
			settings independent of early data, and then decline to offer or
			accept early data if the values do not match the PSK. This preserves
			any ALPN and ALPS configuration specified by the calling application.
	5. Security Considerations		5. Security Considerations
	ALPS is protected using the handshake keys, which are the secret keys		ALPS is protected using the handshake keys, which are the secret keys
	derived as a result of (EC)DHE between the client and the server.		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		In order to ensure that the ALPS values are authenticated, the TLS
	implementation MUST NOT reveal the contents of peer's ALPS until		implementation MUST NOT reveal the contents of peer's ALPS until
	peer's Finished message is received, with exception of cases where		peer's Finished message is received, with exception of cases where
	the ALPS has been carried over from the previous connection.		the ALPS has been carried over from the previous connection.
	6. IANA Considerations		6. IANA Considerations
	IANA will update the "TLS ExtensionType Values" registry to include		IANA will update the "TLS ExtensionType Values" registry to include
	"application_settings" with the value of TBD; the list of messages in		"application_settings" with the value of TBD; the list of messages in
	which this extension may appear is "CH, SH".		which this extension may appear is "CH, EE, CEE".
	IANA will also update the "TLS HandshakeType" registry to include
	"client_application_settings" message with value TBD, and "DTLS-OK"
	set to "Y".
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 7, line 42 ¶		skipping to change at page 8, line 43 ¶
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", Work in Progress, Internet-Draft,		and Secure Transport", Work in Progress, Internet-Draft,
	draft-ietf-quic-transport-29, 9 June 2020,		draft-ietf-quic-transport-30, 9 September 2020,
	<http://www.ietf.org/internet-drafts/draft-ietf-quic-		<http://www.ietf.org/internet-drafts/draft-ietf-quic-
	transport-29.txt>.		transport-30.txt>.
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext		[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,		Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015,		DOI 10.17487/RFC7540, May 2015,
	<https://www.rfc-editor.org/info/rfc7540>.		<https://www.rfc-editor.org/info/rfc7540>.
	Acknowledgments		Acknowledgments
	This document has benefited from contributions and suggestions from		This document has benefited from contributions and suggestions from
	David Benjamin, Nick Harper, David Schinazi, Renjie Tang and many		Nick Harper, David Schinazi, Renjie Tang and many others.
	others.
	Author's Address		Authors' Addresses
			David Benjamin
			Google
			Email: davidben@google.com
	Victor Vasiliev		Victor Vasiliev
	Google		Google
	Email: vasilvv@google.com		Email: vasilvv@google.com
End of changes. 21 change blocks.
	73 lines changed or deleted		116 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/