< draft-ietf-tls-cached-info-13.txt		draft-ietf-tls-cached-info-14.txt >
	TLS S. Santesson		TLS S. Santesson
	Internet-Draft 3xA Security AB		Internet-Draft 3xA Security AB
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: March 16, 2013 Nokia Siemens Networks		Expires: September 29, 2013 Nokia Siemens Networks
	September 12, 2012		March 28, 2013
	Transport Layer Security (TLS) Cached Information Extension		Transport Layer Security (TLS) Cached Information Extension
	draft-ietf-tls-cached-info-13.txt		draft-ietf-tls-cached-info-14.txt
	Abstract		Abstract
	Transport Layer Security (TLS) handshakes often include fairly static		Transport Layer Security (TLS) handshakes often include fairly static
	information, such as the server certificate and a list of trusted		information, such as the server certificate and a list of trusted
	Certification Authorities (CAs). This information can be of		Certification Authorities (CAs). This information can be of
	considerable size, particularly if the server certificate is bundled		considerable size, particularly if the server certificate is bundled
	with a complete certificate path (including all intermediary		with a complete certificate path (including all intermediary
	certificates up to the trust anchor public key).		certificates up to the trust anchor public key).
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 March 16, 2013.		This Internet-Draft will expire on September 29, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Cached Information Extension . . . . . . . . . . . . . . . . . 5		3. Cached Information Extension . . . . . . . . . . . . . . . . . 5
	4. Exchange Specification . . . . . . . . . . . . . . . . . . . . 7		4. Exchange Specification . . . . . . . . . . . . . . . . . . . . 7
	4.1. Fingerprint of the Certificate Chain . . . . . . . . . . . 7		4.1. Omitting the Certificate Chain . . . . . . . . . . . . . . 7
	4.2. Fingerprint for Trusted CAs . . . . . . . . . . . . . . . 8		4.2. Omitting the Trusted CAs . . . . . . . . . . . . . . . . . 8
	5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7.1. New Entry to the TLS ExtensionType Registry . . . . . . . 13		7.1. New Entry to the TLS ExtensionType Registry . . . . . . . 12
	7.2. New Registry for CachedInformationType . . . . . . . . . . 13		7.2. New Registry for CachedInformationType . . . . . . . . . . 12
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 15		9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	Transport Layer Security (TLS) handshakes often include fairly static		Transport Layer Security (TLS) handshakes often include fairly static
	information, such as the server certificate and a list of trusted		information, such as the server certificate and a list of trusted
	Certification Authorities (CAs). This information can be of		Certification Authorities (CAs). This information can be of
	considerable size, particularly if the server certificate is bundled		considerable size, particularly if the server certificate is bundled
	with a complete certificate path (including all intermediary		with a complete certificate path (including all intermediary
	certificates up to the trust anchor public key).		certificates up to the trust anchor public key).
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 27 ¶
	rate. These types of networks exist, for example, when smart objects		rate. These types of networks exist, for example, when smart objects
	are connected using a low power IEEE 802.15.4 radio. For more		are connected using a low power IEEE 802.15.4 radio. For more
	information about the challenges with smart object deployments please		information about the challenges with smart object deployments please
	see [RFC6574].		see [RFC6574].
	This specification defines a TLS extension that allows a client and a		This specification defines a TLS extension that allows a client and a
	server to exclude transmission of cached information from the TLS		server to exclude transmission of cached information from the TLS
	handshake.		handshake.
	A typical example exchange may therefore look as follows. First, the		A typical example exchange may therefore look as follows. First, the
	TLS exchange executes the usual TLS handshake. It may decide to		client and the server executes the usual TLS handshake. The client
	store the certificate provided by the server for a future exchange.		may, for example, decide to cache the certificate provided by the
	When the TLS client then connects to the TLS server some time in the		server. When the TLS client connects to the TLS server some time in
	future, without using session resumption, it then attaches the		the future, without using session resumption, it then attaches the
	cached_information extension defined in this document to the client		cached_information extension defined in this document to the client
	hello message to indicate that it had cached the certificate, and it		hello message to indicate that it had cached the certificate, and it
	provides the fingerprint of it. If the server's certificate had not		provides the fingerprint of it. If the server's certificate had not
	changed then the TLS server does not need to send the full		changed then the TLS server does not need to send the full
	certificate to the client again. In case the information had		certificate to the client again. In case the information had
	changed, the certificate payload is transmitted to the client to		changed, the certificate payload is transmitted to the client to
	allow the client to update it's state information.		allow the client to update it's state information.
	2. Terminology		2. Terminology
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 11 ¶
	This document establishes a registry for CachedInformationType types		This document establishes a registry for CachedInformationType types
	and additional values can be added following the policy described in		and additional values can be added following the policy described in
	Section 7.		Section 7.
	4. Exchange Specification		4. Exchange Specification
	Clients supporting this extension MAY include the		Clients supporting this extension MAY include the
	"cached_information" extension in the (extended) client hello, which		"cached_information" extension in the (extended) client hello, which
	MAY contain zero or more CachedObject attributes.		MAY contain zero or more CachedObject attributes.
	Server supporting this extension MAY include the "cached_information"		A server supporting this extension MAY include the
	extension in the (extended) server hello, which MAY contain one or		"cached_information" extension in the (extended) server hello, which
	more CachedObject attributes. By returning the "cached_information"		MAY contain one or more CachedObject attributes it supports. By
	extension the server indicates that it supports caching of each		returning the "cached_information" extension the server indicates
	present CachedObject that matches the specified hash value. The		that it supports caching of each present CachedObject that matches
	server MAY support other cached objects that are not present in the		the specified hash value. The server MAY support other cached
	extension.		objects that are not present in the extension.
	Note: Clients may need the ability to cache different values		Note: If clients make use of the Server Name Indication [RFC6066]
	depending on other information in the Client Hello that modify what		then clients may need to cache multiple data items for a single
	values the server uses, in particular the Server Name Indication		server since servers may host multiple 'virtual' servers at a single
	[RFC6066] value.		underlying network address.
	Following a successful exchange of "cached_information" extensions,		Following a successful exchange of the "cached_information"
	the server MAY send fingerprints of the cached information in the		extensions in the client and server hello, the server omits sending
	handshake exchange as a replacement for the exchange of the full		the corresponding handshake message. How information is omitted from
	data. Section 4.1 and Section 4.2 defines the syntax of the		the handshake message is defined per cached info type. Section 4.1
	fingerprinted information.		and Section 4.2 defines the syntax of the fingerprinted information.
	The handshake protocol MUST proceed using the information as if it		The handshake protocol MUST proceed using the information as if it
	was provided in the handshake protocol. The Finished message MUST be		was provided in the handshake protocol. The Finished message MUST be
	calculated over the actual data exchanged in the handshake protocol.		calculated over the actual data exchanged in the handshake protocol.
	That is, the Finished message will be calculated over the hash values		That is, the Finished message will be calculated over the information
	of cached information objects and not over the cached information		that was omitted from transmission by means of its present hash in
	that were omitted from transmission.		the client hello and not through its presence in the handshake
			exchange.
	The server MUST NOT include more than one fingerprint for a single		The server MUST NOT include more than one fingerprint for a single
	information element, i.e., at maximum only one CachedObject structure		information element, i.e., at maximum only one CachedObject structure
	per replaced information is provided.		per replaced information is provided.
	4.1. Fingerprint of the Certificate Chain		4.1. Omitting the Certificate Chain
	When an object of type 'certificate_chain' is provided in the client		When an object of type 'certificate_chain' is provided in the client
	hello, the server MAY send a fingerprint instead of the complete		hello, the server MAY replace the sequence of certificates with an
	certificate chain as shown below.		empty sequence with an actual length field of zero (=empty vector).
	The original handshake message syntax is defined in RFC 5246		The original handshake message syntax is defined in RFC 5246
	[RFC5246] and has the following structure:		[RFC5246] and has the following structure:
	opaque ASN.1Cert<1..2^24-1>;		opaque ASN.1Cert<1..2^24-1>;
	struct {		struct {
	ASN.1Cert certificate_list<0..2^24-1>;		ASN.1Cert certificate_list<0..2^24-1>;
	} Certificate;		} Certificate;
	By using the extension defined in this document the following		Note that [I-D.ietf-tls-oob-pubkey] allows the certificate payload to
	information is sent:		contain only the SubjectPublicKeyInfo instead of the full information
	struct {
	CachedObject cached_objects<1..2^24-1>;
	} Certificate;
	The certificate_list vector of opaque ASN.1Cert elements in the
	original syntax is replaced with a vector holding CachedObject
	structures as defined in this document.
	Note: [I-D.ietf-tls-oob-pubkey] allows a PKIX certificate containing
	only the SubjectPublicKeyInfo instead of the full information
	typically found in a certificate. Hence, when this specification is		typically found in a certificate. Hence, when this specification is
	used in combination with [I-D.ietf-tls-oob-pubkey] and the negotiated		used in combination with [I-D.ietf-tls-oob-pubkey] and the negotiated
	certificate type is a raw public key then the TLS server sends the		certificate type is a raw public key then the TLS server omits
	hashed Certificate payload that contains a ASN.1Cert structure of the		sending a Certificate payload that contains an ASN.1Cert structure of
	SubjectPublicKeyInfo.		the SubjectPublicKeyInfo.
	4.2. Fingerprint for Trusted CAs		4.2. Omitting the Trusted CAs
	When a hash for an object of type 'trusted_cas' is provided in the		When a fingerprint for an object of type 'trusted_cas' is provided in
	client hello, the server MAY send a fingerprint instead of the		the client hello, the server MAY send a DistinguishedName in the
	complete certificate authorities information as shown below.		Certificate Request message with an actual length field of zero
			(=empty vector).
	The original handshake message syntax is defined in RFC 5246		The original handshake message syntax is defined in RFC 5246
	[RFC5246] and has the following structure:		[RFC5246] and has the following structure:
	opaque DistinguishedName<1..2^16-1>;		opaque DistinguishedName<1..2^16-1>;
	struct {		struct {
	ClientCertificateType certificate_types<1..2^8-1>;		ClientCertificateType certificate_types<1..2^8-1>;
	SignatureAndHashAlgorithm		SignatureAndHashAlgorithm
	supported_signature_algorithms<2^16-1>;		supported_signature_algorithms<2^16-1>;
	DistinguishedName certificate_authorities<0..2^16-1>;		DistinguishedName certificate_authorities<0..2^16-1>;
	} CertificateRequest;		} CertificateRequest;
	By using the extension defined in this document the following
	information is sent:
	struct {
	ClientCertificateType certificate_types<1..2^8-1>;
	SignatureAndHashAlgorithm
	supported_signature_algorithms<2^16-1>;
	CachedObject cached_objects<1..2^16-1>;
	} CertificateRequest;
	The certificate_authorities vector of opaque DistinguishedName
	elements in the original syntax is replaced with a vector holding
	CachedObject structures as defined in this document.
	5. Example		5. Example
	Figure 1 illustrates an example exchange using the TLS cached info		Figure 1 illustrates an example exchange using the TLS cached info
	extension. In the normal TLS handshake exchange shown in flow (A)		extension. In the normal TLS handshake exchange shown in flow (A)
	the TLS server provides its certificate in the Certificate payload to		the TLS server provides its certificate in the Certificate payload to
	the client, see step [1]. This allows the client to store the		the client, see step [1]. This allows the client to store the
	certificate for future use. After some time the TLS client again		certificate for future use. After some time the TLS client again
	interacts with the same TLS server and makes use of the TLS cached		interacts with the same TLS server and makes use of the TLS cached
	info extension, as shown in flow (B). The TLS client indicates		info extension, as shown in flow (B). The TLS client indicates
	support for this specification via the cached_information extension,		support for this specification via the cached_information extension,
	see [2], and indicates that it has stored the certificate_chain from		see [2], and indicates that it has stored the certificate_chain from
	the earlier exchange. With [3] the TLS server indicates that it also		the earlier exchange. With [3] the TLS server indicates that it also
	supports this specification and informs the client that it also		supports this specification and informs the client that it also
	supports caching of other objects beyond the 'certificate_chain',		supports caching of other objects beyond the 'certificate_chain',
	namely 'trusted_cas' (also defined in this document), and the 'foo-		namely 'trusted_cas' (also defined in this document), and the 'foo-
	bar' extension (i.e., an imaginary extension that yet needs to be		bar' extension (i.e., an imaginary extension that yet needs to be
	defined). With [4] the TLS server provides the fingerprint of the		defined). With [4] the TLS server omits sending the certificate
	certificate chain as described in Section 4.1.		chain, as described in Section 4.1.
	(A) Initial (full) Exchange		(A) Initial (full) Exchange
	client_hello ->		client_hello ->
	<- server_hello,		<- server_hello,
	certificate, // [1]		certificate, // [1]
	server_key_exchange,		server_key_exchange,
	server_hello_done		server_hello_done
	client_key_exchange,		client_key_exchange,
	change_cipher_spec,		change_cipher_spec,
	finished ->		finished ->
	<- change_cipher_spec,		<- change_cipher_spec,
	finished		finished
	Application Data <-------> Application Data		Application Data <-------> Application Data
	(B) TLS Cached Extension Usage		(B) TLS Cached Extension Usage
	client_hello,		client_hello,
	cached_information=(certificate_chain) -> // [2]		cached_information=(certificate_chain) -> // [2]
	<- server_hello,		<- server_hello,
	cached_information= // [3]		cached_information= // [3]
	(certificate_chain, trusted_cas, foo-bar)		(certificate_chain, trusted_cas, foo-bar)
	certificate, // [4]		certificate, // [4]
	server_key_exchange,		server_key_exchange,
	server_hello_done		server_hello_done
	client_key_exchange,		client_key_exchange,
	change_cipher_spec,		change_cipher_spec,
	finished ->		finished ->
	<- change_cipher_spec,		<- change_cipher_spec,
	finished		finished
	Application Data <-------> Application Data		Application Data <-------> Application Data
	Figure 1: Example Message Exchange		Figure 1: Example Message Exchange
	6. Security Considerations		6. Security Considerations
	This specification defines a mechanism to reference stored state		This specification defines a mechanism to reference stored state
	using a fingerprint. The hash algorithm used in this specification		using a fingerprint. Sending a fingerprint of cached information in
	is required to have reasonable random properties in order to provide		an unencrypted handshake, as the client and server hello is, may
	reasonably unique identifiers. There is no requirement that this		allow an attacker or observer to correlate independent TLS exchanges.
	hash algorithm must have strong collision resistance.		While some information elements used in this specification, such as
			server certificates, are public objects and usually not sensitive in
			this regard, others may be. Those who implement and deploy this
			specification should therefore make an informed decision whether the
			cached information is inline with their security and privacy goals.
			In case of concerns, it is advised to avoid sending the fingerprint
			of the data objects in clear.
	Caching information in an encrypted handshake (such as a renegotiated		The hash algorithm used in this specification is required to have
	handshake) and sending a hash of that cached information in an		reasonable random properties in order to provide reasonably unique
	unencrypted handshake might introduce integrity or data disclosure		identifiers. There is no requirement that this hash algorithm must
	issues as it enables an attacker to identify if a known object (such		have strong collision resistance.
	as a known server certificate) has been used in previous encrypted
	handshakes. Information object types defined in this specification,
	such as server certificates, are public objects and usually not
	sensitive in this regard, but implementers should be aware if any
	cached information are subject to such security concerns and in such
	case SHOULD NOT send a hash over encrypted data in unencrypted
	handshake.
	7. IANA Considerations		7. IANA Considerations
	7.1. New Entry to the TLS ExtensionType Registry		7.1. New Entry to the TLS ExtensionType Registry
	IANA is requested to add an entry to the existing TLS ExtensionType		IANA is requested to add an entry to the existing TLS ExtensionType
	registry, defined in RFC 5246 [RFC5246], for cached_information(TBD)		registry, defined in RFC 5246 [RFC5246], for cached_information(TBD)
	defined in this document.		defined in this document.
	7.2. New Registry for CachedInformationType		7.2. New Registry for CachedInformationType
	skipping to change at page 14, line 14 ¶		skipping to change at page 13, line 14 ¶
	8. Acknowledgments		8. Acknowledgments
	We would like to thank the following persons for your detailed		We would like to thank the following persons for your detailed
	document reviews:		document reviews:
	o Paul Wouters and Nikos Mavrogiannopoulos (December 2011)		o Paul Wouters and Nikos Mavrogiannopoulos (December 2011)
	o Rob Stradling (February 2012)		o Rob Stradling (February 2012)
	o Ondrej Mikle in March 2012)		o Ondrej Mikle (in March 2012)
	Additionally, we would like to thank the TLS working group chairs,		Additionally, we would like to thank the TLS working group chairs,
	Eric Rescorla and Joe Salowey, as well as the security area		Eric Rescorla and Joe Salowey, as well as the security area
	directors, Sean Turner and Stephen Farrell, for their feedback and		directors, Sean Turner and Stephen Farrell, for their feedback and
	support.		support.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	skipping to change at page 15, line 24 ¶		skipping to change at page 14, line 24 ¶
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:		[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
	Extension Definitions", RFC 6066, January 2011.		Extension Definitions", RFC 6066, January 2011.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-tls-oob-pubkey]		[I-D.ietf-tls-oob-pubkey]
	Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H.		Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
	Tschofenig, "Out-of-Band Public Key Validation for		T. Kivinen, "Out-of-Band Public Key Validation for
	Transport Layer Security", draft-ietf-tls-oob-pubkey-04		Transport Layer Security (TLS)",
	(work in progress), July 2012.		draft-ietf-tls-oob-pubkey-07 (work in progress),
			February 2013.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object		[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object
	Workshop", RFC 6574, April 2012.		Workshop", RFC 6574, April 2012.
	Authors' Addresses		Authors' Addresses
End of changes. 32 change blocks.
	126 lines changed or deleted		103 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/