draft-ietf-tls-cached-info-00.txt		draft-ietf-tls-cached-info-01.txt
	INTERNET-DRAFT S. Santesson (3xA Security)		INTERNET-DRAFT S. Santesson (3xA Security)
	Intended Status: Proposed Standard Q. Dang (NIST)		Intended Status: Proposed Standard Q. Dang (NIST)
	Transport Layer Security (TLS) Cached Information Extension		Transport Layer Security (TLS) Cached Information Extension
	<draft-ietf-tls-cached-info-00.txt>		<draft-ietf-tls-cached-info-01.txt>
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 2, line 32		skipping to change at page 2, line 32
	2 Cached Information Extension		2 Cached Information Extension
	A new extension type (cached_information(TBD)) is defined and used in		A new extension type (cached_information(TBD)) is defined and used in
	both the client hello and server hello messages. The extension type		both the client hello and server hello messages. The extension type
	is specified as follows.		is specified as follows.
	enum {		enum {
	cached_information(TBD), (65535)		cached_information(TBD), (65535)
	} ExtensionType;		} ExtensionType;
	The "extension_data" field of this extension SHALL contain		The "extension_data" field of this extension, when included in the
	"CachedInformation" according to the following structure:		client hello, SHALL contain "CachedInformation" according to the
			following structure:
	enum {		enum {
	certificate_chain(1), trusted_cas(2), (255)		certificate_chain(1), trusted_cas(2), (255)
	} CachedInformationType;		} CachedInformationType;
	struct {		struct {
	HashAlgorithm hash;		HashAlgorithm hash;
	opaque hash_value<1..255>;		opaque hash_value<1..255>;
	} CachedInformationHash;		} CachedInformationHash;
	skipping to change at page 3, line 21		skipping to change at page 3, line 21
	When CachedInformationType identifies certificate_chain, then		When CachedInformationType identifies certificate_chain, then
	hash_value MUST include at least one hash value calculated over the		hash_value MUST include at least one hash value calculated over the
	certificate_list element of a server side Certificate message.		certificate_list element of a server side Certificate message.
	When CachedInformationType identifies trusted_cas, then hash_value		When CachedInformationType identifies trusted_cas, then hash_value
	MUST include at least one hash value calculated over the		MUST include at least one hash value calculated over the
	certificate_authorities element of a server side CertificateRequest		certificate_authorities element of a server side CertificateRequest
	message.		message.
			The client MUST NOT include hashes for multiple objects in the same
			CachedObject structure. If more than one hash is present in the
			CachedObject structure, they MUST be hashes over the same information
			object using different hash algorithms.
	Other specifications MAY define more CachedInformationType types.		Other specifications MAY define more CachedInformationType types.
	4 Message flow		4 Message flow
	Clients MAY include an extension of type "cached_information" in the		Clients MAY include an extension of type "cached_information" in the
	(extended) client hello, which SHALL contain at least one		(extended) client hello, which SHALL contain at least one
	CachedObject as specified in section 2.		CachedObject as specified in section 2. Clients MAY need the ability
			to cache different values depending on other information in the
			Client Hello that modify what values the server uses, in particular
			the Server Name Indication [RFC4366] value.
	Servers that receive an extended client hello containing a		Servers that receive an extended client hello containing a
	"cached_information" extension, MAY indicate that they support one or		"cached_information" extension, MAY indicate that they support
	more of the cached information objects by including an extension of		caching of information objects by including an extension of type
	type "cached_information" in the (extended) server hello, which SHALL		"cached_information" with an empty extension_data field in their
	contain at least one CachedObject received from the client. The		(extended) server hello.
	CachedObject's returned by the server MUST include the types the
	server supports and has accepted to replace with a hash of the cached
	data.
	After negotiation of the use of cached certificates has been		Following a successful exchange of "cached_information" extensions,
	successfully completed (by exchanging hello messages including		the server may replace data objects identified through the client
	"cached_certs" extensions), the server MUST replace agreed cached		extension with any of the CachedInformationHash values received from
	information objects in its handshake messages with a corresponding		the client, which matches the replaced object.
	hash_value from CachedInformationHash that was included in the
	cached_information extension of the server hello message.
	The handshake protocol will proceed using the cached data as if it		The handshake protocol will proceed using the cached data as if it
	they were provided in the handshake protocol. The finished message		was provided in the handshake protocol. The finished message will
	will however be calculated over the actual data exchanged in the		however be calculated over the actual data exchanged in the handshake
	handshake protocol. That is, the finished message will be calculated		protocol. That is, the finished message will be calculated over the
	over the hash values of cached information objects and not over the		hash values of cached information objects and not over the cached
	cached objects that were omitted from transmission.		objects that were omitted from transmission.
	5 Security Considerations		5 Security Considerations
	Hash algorithms used in this specification are required to have		Hash algorithms used in this specification are required to have
	reasonable random properties in order to provide reasonably unique		reasonable random properties in order to provide reasonably unique
	identifiers. Failure of a provided hash to correctly and uniquely		identifiers. Failure of a provided hash to correctly and uniquely
	identify the correct set of hashed parameters may at most lead to a		identify the correct set of hashed parameters may at most lead to a
	failed TLS handshake followed by a new attempt without the cached		failed TLS handshake followed by a new attempt without the cached
	information extension. No serious security threat requires selected		information extension. No serious security threat requires selected
	hash algorithms to have strong collision resistance.		hash algorithms to have strong collision resistance.
	skipping to change at page 4, line 26		skipping to change at page 4, line 30
	1) Create an entry, cached_information(TBD), in the existing registry		1) Create an entry, cached_information(TBD), in the existing registry
	for ExtensionType (defined in RFC 5246 [RFC5246]).		for ExtensionType (defined in RFC 5246 [RFC5246]).
	2) Establish a registry for TLS CachedInformationType values. The		2) Establish a registry for TLS CachedInformationType values. The
	first entries in the registry are certificate_chain(1) and		first entries in the registry are certificate_chain(1) and
	trusted_cas(2). TLS CachedInformationType values in the inclusive		trusted_cas(2). TLS CachedInformationType values in the inclusive
	range 0-63 (decimal) are assigned via RFC 5226 [RFC5226] Standards		range 0-63 (decimal) are assigned via RFC 5226 [RFC5226] Standards
	Action. Values from the inclusive range 64-223 (decimal) are		Action. Values from the inclusive range 64-223 (decimal) are
	assigned via RFC 5226 Specification Required. Values from the		assigned via RFC 5226 Specification Required. Values from the
	inclusive range 224-255 (decimal) are reserved for RFC 5226 Private		inclusive range 224-255 (decimal) are reserved for RFC 5226
	Use.		Private Use.
	7 Normative References		7 Normative References
	[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate		[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an		[RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 5226,		IANA Considerations Section in RFCs", RFC 5226,
	May 2008.
	[RFC5246] T. Dierks, E. Rescorla, "The Transport Layer Security		[RFC5246] T. Dierks, E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008		(TLS) Protocol Version 1.2", RFC 5246, August 2008
			[RFC4366] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
			T. Wright, "Transport Layer Security (TLS) Extensions",
	Authors' Addresses		Authors' Addresses
	Stefan Santesson		Stefan Santesson
	3xA Security AB		3xA Security AB
	Bjornstorp 744		Bjornstorp 744
	247 98 Genarp		247 98 Genarp
	Sweden		Sweden
	EMail: sts@aaa-sec.com		EMail: sts@aaa-sec.com
	skipping to change at page 5, line 45		skipping to change at page 6, line 25
	All IETF Documents and the information contained therein are provided		All IETF Documents and the information contained therein are provided
	on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY		WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE		WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS		ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	FOR A PARTICULAR PURPOSE.		FOR A PARTICULAR PURPOSE.
	Expires January 2009		Expires December 2009
End of changes. 12 change blocks.
	28 lines changed or deleted		31 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/