< draft-ietf-tls-cached-info-21.txt		draft-ietf-tls-cached-info-22.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: June 23, 2016 ARM Ltd.		Expires: July 29, 2016 ARM Ltd.
	December 21, 2015		January 26, 2016
	Transport Layer Security (TLS) Cached Information Extension		Transport Layer Security (TLS) Cached Information Extension
	draft-ietf-tls-cached-info-21.txt		draft-ietf-tls-cached-info-22.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 chain (i.e., the certificates of		with a complete certificate chain (i.e., the certificates of
	intermediate CAs up to the root CA).		intermediate CAs up to the root CA).
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 June 23, 2016.		This Internet-Draft will expire on July 29, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	skipping to change at page 3, line 26 ¶		skipping to change at page 3, line 26 ¶
	This document refers to the TLS protocol but the description is		This document refers to the TLS protocol but the description is
	equally applicable to DTLS as well.		equally applicable to DTLS as well.
	3. Cached Information Extension		3. Cached Information Extension
	This document defines a new extension type (cached_info(TBD)), which		This document defines a new extension type (cached_info(TBD)), which
	is used in client hello and server hello messages. The extension		is used in client hello and server hello messages. The extension
	type is specified as follows.		type is specified as follows.
	enum {		enum {
	cached_info(TBD), (65535)		cached_info(TBD), (65535)
	} ExtensionType;		} ExtensionType;
	The extension_data field of this extension, when included in the		The extension_data field of this extension, when included in the
	client hello, MUST contain the CachedInformation structure. The		client hello, MUST contain the CachedInformation structure. The
	client MAY send multiple CachedObjects of the same		client MAY send multiple CachedObjects of the same
	CachedInformationType. This may, for example, be the case when the		CachedInformationType. This may, for example, be the case when the
	client has cached multiple certificates from a server.		client has cached multiple certificates from a server.
	enum {		enum {
	cert(1), cert_req(2) (255)		cert(1), cert_req(2) (255)
	} CachedInformationType;		} CachedInformationType;
	struct {		struct {
	select (type) {		select (type) {
	case client:		case client:
	CachedInformationType type;		CachedInformationType type;
	opaque hash_value<1..255>;		opaque hash_value[4];
	case server:		case server:
	CachedInformationType type;		CachedInformationType type;
	} body;		};
	} CachedObject;		} CachedObject;
	struct {		struct {
	CachedObject cached_info<1..2^8-1>;		CachedObject cached_info<1..255>;
	} CachedInformation;		} CachedInformation;
	This document defines the following two types:		This document defines the following two types:
	'cert' Type for not sending the complete Server Certificate Message:		'cert' Type for not sending the complete Server Certificate Message:
	With the type field set to 'cert', the client MUST include the		With the type field set to 'cert', the client MUST include the
	fingerprint of the Certificate message in the hash_value field.		fingerprint of the Certificate message in the hash_value field.
	For this type the fingerprint MUST be calculated using the		For this type the fingerprint MUST be calculated using the
	procedure described in Section 5 with the Certificate message as		procedure described in Section 5 with the Certificate message as
	input data.		input data.
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 43 ¶
	'cert_req' Type for not sending the complete CertificateRequest		'cert_req' Type for not sending the complete CertificateRequest
	Message:		Message:
	With the type set to 'cert_req', the client MUST include the		With the type set to 'cert_req', the client MUST include the
	fingerprint of the CertificateRequest message in the hash_value		fingerprint of the CertificateRequest message in the hash_value
	field. For this type the fingerprint MUST be calculated using the		field. For this type the fingerprint MUST be calculated using the
	procedure described in Section 5 with the CertificateRequest		procedure described in Section 5 with the CertificateRequest
	message as input data.		message as input data.
	New cached info types can be added following the policy described in		New cached info types can be added following the policy described in
	the IANA considerations section, see Section 8. New message digest		the IANA considerations section, see Section 8. New hash algorithms
	algorithms for use with these types can also be added by registering		can also be added by registering a new type. For practical reasons
	a new type that makes use of the updated message digest algorithm.		we recommend to re-use hash algorithms already available with TLS
	There are no specific requirements for the use of specific hash		ciphersuites to avoid additional code and to keep the collision
	algorithms but for practical reason it is useful to re-use algorithms		probably low new hash algorithms MUST NOT have a collision resistance
	already available with TLS ciphersuites to avoid additional code and		worse than SHA-256 when truncated to 4 bytes.
	to keep the collision probably low.
	4. Exchange Specification		4. Exchange Specification
	Clients supporting this extension MAY include the "cached_info"		Clients supporting this extension MAY include the "cached_info"
	extension in the (extended) client hello. If the client includes the		extension in the (extended) client hello. If the client includes the
	extension then it MUST contain one or more CachedObject attributes.		extension then it MUST contain one or more CachedObject attributes.
	A server supporting this extension MAY include the "cached_info"		A server supporting this extension MAY include the "cached_info"
	extension in the (extended) server hello. By returning the		extension in the (extended) server hello. By returning the
	"cached_info" extension the server indicates that it supports the		"cached_info" extension the server indicates that it supports the
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 35 ¶
	Note: We assume that the server implementation is able to select the		Note: We assume that the server implementation is able to select the
	appropriate certificate or SubjectPublicKeyInfo from the received		appropriate certificate or SubjectPublicKeyInfo from the received
	hash value. If the SNI extension is used by the client then the		hash value. If the SNI extension is used by the client then the
	server has additional information to guide the selection of the		server has additional information to guide the selection of the
	appropriate cached info.		appropriate cached info.
	When the cached info specification is used then a modified version of		When the cached info specification is used then a modified version of
	the Certificate message is exchanged. The modified structure is		the Certificate message is exchanged. The modified structure is
	shown in Figure 1.		shown in Figure 1.
	struct {		struct {
	opaque hash_value[1..255];		opaque hash_value[4];
	} Certificate;		} Certificate;
	Figure 1: Cached Info Certificate Message.		Figure 1: Cached Info Certificate Message.
	4.2. CertificateRequest Message		4.2. CertificateRequest Message
	When a fingerprint for an object of type 'cert_req' is provided in		When a fingerprint for an object of type 'cert_req' is provided in
	the client hello, the server MAY send the CertificateRequest message		the client hello, the server MAY send the CertificateRequest message
	shown in Figure 2 message under the following conditions:		shown in Figure 2 message under the following conditions:
	o The server software implements the "cached_info" extension defined		o The server software implements the "cached_info" extension defined
	skipping to change at page 7, line 18 ¶		skipping to change at page 7, line 18 ¶
	check ensures that the information cached by the client is		check ensures that the information cached by the client is
	current. The procedure for calculating the fingerprint is		current. The procedure for calculating the fingerprint is
	described in Section 5.		described in Section 5.
	o The server wants to request a certificate from the client.		o The server wants to request a certificate from the client.
	The original CertificateRequest handshake message syntax is defined		The original CertificateRequest handshake message syntax is defined
	in [RFC5246]. The modified structure of the CertificateRequest		in [RFC5246]. The modified structure of the CertificateRequest
	message is shown in Figure 2.		message is shown in Figure 2.
	struct {		struct {
	opaque hash_value<1..255>;		opaque hash_value[4];
	} CertificateRequest;		} CertificateRequest;
	Figure 2: Cached Info CertificateRequest Message.		Figure 2: Cached Info CertificateRequest Message.
	The CertificateRequest payload is the input parameter to the		The CertificateRequest payload is the input parameter to the
	fingerprint calculation described in Section 5.		fingerprint calculation described in Section 5.
	5. Fingerprint Calculation		5. Fingerprint Calculation
	The fingerprint MUST be computed as follows:		The fingerprint MUST be computed as follows:
	skipping to change at page 11, line 27 ¶		skipping to change at page 11, line 27 ¶
	o Ilari Liusvaara, Adam Langley, and Eric Rescorla (July 2014)		o Ilari Liusvaara, Adam Langley, and Eric Rescorla (July 2014)
	o Sean Turner (August 2014)		o Sean Turner (August 2014)
	o Martin Thomson (August 2015)		o Martin Thomson (August 2015)
	o Jouni Korhonen (November 2015)		o Jouni Korhonen (November 2015)
	o Matt Miller (December 2015)		o Matt Miller (December 2015)
			o Dave Garrett (December 2015)
	We would also to thank Martin Thomson, Karthikeyan Bhargavan, Sankalp		We would also to thank Martin Thomson, Karthikeyan Bhargavan, Sankalp
	Bagaria and Eric Rescorla for their feedback regarding the		Bagaria and Eric Rescorla for their feedback regarding the
	fingerprint calculation.		fingerprint calculation.
	Finally, we would like to thank the TLS working group chairs, Sean		Finally, we would like to thank the TLS working group chairs, Sean
	Turner and Joe Salowey, as well as the responsible security area		Turner and Joe Salowey, as well as the responsible security area
	director, Stephen Farrell, for their support and their reviews.		director, Stephen Farrell, for their support and their reviews.
	10. References		10. References
	skipping to change at page 17, line 47 ¶		skipping to change at page 17, line 47 ¶
	9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 54		9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 54
	2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 42		2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 42
	49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 45		49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 45
	Figure 7: Hex Encoding of the Example Certificate.		Figure 7: Hex Encoding of the Example Certificate.
	Applying the SHA-256 hash function to the Certificate message, which		Applying the SHA-256 hash function to the Certificate message, which
	is starts with 0b 00 02 and ends with 9E 57 45, produces		is starts with 0b 00 02 and ends with 9E 57 45, produces
	0x086eefb4859adfe977defac494fff6b73033b4ce1f86b8f2a9fc0c6bf98605af.		0x086eefb4859adfe977defac494fff6b73033b4ce1f86b8f2a9fc0c6bf98605af.
	Subsequently, this output is truncated to 32 bits, which leads to a		Subsequently, this output is truncated to 32 bits, which leads to a
	fingerpint of 0x086eefb4.		fingerprint of 0x086eefb4.
	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
End of changes. 13 change blocks.
	37 lines changed or deleted		38 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/