draft-ietf-tls-cached-info-15.txt		draft-ietf-tls-cached-info-16.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: April 20, 2014 Nokia Solutions and Networks		Expires: August 18, 2014 ARM Ltd.
	October 17, 2013		February 14, 2014
	Transport Layer Security (TLS) Cached Information Extension		Transport Layer Security (TLS) Cached Information Extension
	draft-ietf-tls-cached-info-15.txt		draft-ietf-tls-cached-info-16.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 chain (i.e., the certificates of
	certificates up to the trust anchor public key).		intermediate CAs up to the root CA).
	This document defines an extension that omits the exchange of already		This document defines an extension that allows a TLS client to inform
	available information. The TLS client informs a server of cached		a server of cached information, allowing the server to omit already
	information, for example from a previous TLS handshake, allowing the		available information.
	server to omit the already available information.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 April 20, 2014.		This Internet-Draft will expire on August 18, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Cached Information Extension . . . . . . . . . . . . . . . . 3		3. Cached Information Extension . . . . . . . . . . . . . . . . 3
	4. Exchange Specification . . . . . . . . . . . . . . . . . . . 4		4. Exchange Specification . . . . . . . . . . . . . . . . . . . 4
	4.1. Omitting the Certificate Chain . . . . . . . . . . . . . 5		4.1. Omitting the Certificate Chain . . . . . . . . . . . . . 5
	4.2. Omitting the Trusted CAs . . . . . . . . . . . . . . . . 6		4.2. Omitting the Trusted CAs . . . . . . . . . . . . . . . . 5
	5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7.1. New Entry to the TLS ExtensionType Registry . . . . . . . 8		7.1. New Entry to the TLS ExtensionType Registry . . . . . . . 8
	7.2. New Registry for CachedInformationType . . . . . . . . . 8		7.2. New Registry for CachedInformationType . . . . . . . . . 8
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . 9
	9.2. Informative References . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	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 chain (i.e., the certificates of
	certificates up to the trust anchor public key).		intermediate CAs up to the root CA).
	Optimizing the exchange of information to a minimum helps to improve		Optimizing the exchange of information to a minimum helps to improve
	performance in environments where devices are connected to a network		performance in environments where devices are connected to a network
	with characteristics like low bandwidth, high latency and high loss		with a low bandwidth, and lossy radio technology. These types of
	rate. These types of networks exist, for example, when smart objects		environments exist, for example, when smart objects are connected
	are connected using a low power IEEE 802.15.4 radio. For more		using a low power IEEE 802.15.4 radio or via Bluetooth Low Energy.
	information about the challenges with smart object deployments please		For more information about the challenges with smart object
	see [RFC6574].		deployments please 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
	client and the server executes the usual TLS handshake. The client		client and the server executes the usual TLS handshake. The client
	may, for example, decide to cache the certificate provided by the		may, for example, decide to cache the certificate provided by the
	server. When the TLS client connects to the TLS server some time in		server. When the TLS client connects to the TLS server some time in
	the 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 complete
	certificate to the client again. In case the information had		certificate chain 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 its state information.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Cached Information Extension		3. Cached Information Extension
	This document defines a new extension type (cached_information(TBD)),		This document defines a new extension type (cached_information(TBD)),
	skipping to change at page 9, line 41		skipping to change at page 9, line 29
	[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., Tschofenig, H., Gilmore, J., Weiler, S., and		Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
	T. Kivinen, "Out-of-Band Public Key Validation for		T. Kivinen, "Using Raw Public Keys in Transport Layer
	Transport Layer Security (TLS)", draft-ietf-tls-oob-		Security (TLS) and Datagram Transport Layer Security
	pubkey-09 (work in progress), July 2013.		(DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress),
			January 2014.
	[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
	skipping to change at page 10, line 14		skipping to change at page 10, line 4
	Authors' Addresses		Authors' Addresses
	Stefan Santesson		Stefan Santesson
	3xA Security AB		3xA Security AB
	Scheelev. 17		Scheelev. 17
	Lund 223 70		Lund 223 70
	Sweden		Sweden
	Email: sts@aaa-sec.com		Email: sts@aaa-sec.com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Solutions and Networks		ARM Ltd.
	Linnoitustie 6		110 Fulbourn Rd
	Espoo 02600		Cambridge CB1 9NJ
	Finland		Great Britain
	Phone: +358 (50) 4871445		Email: Hannes.tschofenig@gmx.net
	Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
End of changes. 17 change blocks.
	34 lines changed or deleted		32 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/