< draft-ietf-tls-cached-info-16.txt		draft-ietf-tls-cached-info-17.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: August 18, 2014 ARM Ltd.		Expires: May 17, 2015 ARM Ltd.
	February 14, 2014		November 13, 2014
	Transport Layer Security (TLS) Cached Information Extension		Transport Layer Security (TLS) Cached Information Extension
	draft-ietf-tls-cached-info-16.txt		draft-ietf-tls-cached-info-17.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 August 18, 2014.		This Internet-Draft will expire on May 17, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	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		3.1. Certificate_list Fingerprint . . . . . . . . . . . . . . 4
	4.1. Omitting the Certificate Chain . . . . . . . . . . . . . 5		3.2. Certificate_authorities Fingerprint . . . . . . . . . . . 4
	4.2. Omitting the Trusted CAs . . . . . . . . . . . . . . . . 5		3.3. Fingerprint Hash Algorithm . . . . . . . . . . . . . . . 4
			4. Exchange Specification . . . . . . . . . . . . . . . . . . . 5
			4.1. Omitting the Certificate List . . . . . . . . . . . . . . 5
			4.2. Omitting the Trusted Certificate Authorities . . . . . . 6
	5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7.1. New Entry to the TLS ExtensionType Registry . . . . . . . 8		7.1. New Entry to the TLS ExtensionType Registry . . . . . . . 9
	7.2. New Registry for CachedInformationType . . . . . . . . . 8		7.2. New Registry for CachedInformationType . . . . . . . . . 9
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Transport Layer Security (TLS) handshakes often include fairly static		Reducing the amount of information exchanged during a Transport Layer
	information, such as the server certificate and a list of trusted		Security handshake to a minimum helps to improve performance in
	Certification Authorities (CAs). This information can be of		environments where devices are connected to a network with a low
	considerable size, particularly if the server certificate is bundled		bandwidth, and lossy radio technology. With Internet of Things such
	with a complete certificate chain (i.e., the certificates of
	intermediate CAs up to the root CA).
	Optimizing the exchange of information to a minimum helps to improve
	performance in environments where devices are connected to a network
	with a low bandwidth, and lossy radio technology. These types of
	environments exist, for example, when smart objects are connected		environments exist, for example, when smart objects are connected
	using a low power IEEE 802.15.4 radio or via Bluetooth Low Energy.		using a low power IEEE 802.15.4 radio or via Bluetooth Smart. For
	For more information about the challenges with smart object		more information about the challenges with smart object deployments
	deployments please see [RFC6574].		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 information cached in an earlier 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_info extension defined in this document to the client hello
	hello message to indicate that it had cached the certificate, and it		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 has not
	changed then the TLS server does not need to send the complete		changed then the TLS server does not need to send its' certificate
	certificate chain to the client again. In case the information had		and the corresponding certificate list again. In case information
	changed, the certificate payload is transmitted to the client to		has changed, which can be seen from the fingerprint provided by the
	allow the client to update its state information.		client, the certificate payload is transmitted to the client to allow
			the client to update the cache.
	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].
			This document refers to the TLS protocol but the description is
			equally applicable to DTLS as well.
	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_info(TBD)), which
	which is used in client hello and server hello messages. The		is used in client hello and server hello messages. The extension
	extension type is specified as follows.		type is specified as follows.
	enum {		enum {
	cached_information(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.		client hello, MUST contain the CachedInformation structure. The
			client MUST NOT send multiple CachedObjects with the same
			CachedInformationType.
	enum {		enum {
	certificate_chain(1), trusted_cas(2) (255)		certificate_list(1), certificate_authorities(2) (255)
	} CachedInformationType;		} CachedInformationType;
	struct {		struct {
	CachedInformationType type;		select (type) {
	HashAlgorithm hash;		case client:
	opaque hash_value<1..255>;		CachedInformationType type;
			HashAlgorithm hash;
			opaque hash_value<1..255>;
			case server:
			CachedInformationType type;
			} body;
	} CachedObject;		} CachedObject;
	struct {		struct {
	CachedObject cached_info<1..2^16-1>;		CachedObject cached_info<1..2^16-1>;
	} CachedInformation;		} CachedInformation;
	When the CachedInformationType identifies a certificate_chain, then		This document establishes a registry for CachedInformationType types;
			additional values can be added following the policy described in
			Section 7.
			3.1. Certificate_list Fingerprint
			When the CachedInformationType identifies a certificate_list, then
	the hash_value field MUST include the hash calculated over the		the hash_value field MUST include the hash calculated over the
	certificate_list element of the Certificate payload provided by the		certificate_list element of the Certificate payload provided by the
	TLS server in an earlier exchange, excluding the three length bytes		TLS server in an earlier exchange, excluding the three length bytes
	of the certificate_list vector.		of the certificate_list vector.
	When the CachedInformationType identifies a trusted_cas, then the		3.2. Certificate_authorities Fingerprint
	hash_value MUST include a hash calculated over the
	certificate_authorities element of the CertificateRequest payload		When the CachedInformationType identifies a certificate_authorities,
	provided by the TLS server in an earlier exchange, excluding the two		then the hash_value MUST include a hash calculated over
	length bytes of the certificate_authorities vector.		CertificateRequest payload provided by the TLS server in an earlier
			exchange, excluding the msg_type and length field.
			3.3. Fingerprint Hash Algorithm
	The hash algorithm used to calculate hash values is conveyed in the		The hash algorithm used to calculate hash values is conveyed in the
	'hash' field of the CachedObject element. The list of registered		'hash' field of the CachedObject element. The list of registered
	hash algorithms can be found in the TLS HashAlgorithm Registry, which		hash algorithms can be found in the TLS HashAlgorithm Registry, which
	was created by RFC 5246 [RFC5246]. The value zero (0) for 'none' is		was created by RFC 5246 [RFC5246]. The value zero (0) for 'none' and
	not an allowed choice for a hash algorithm and MUST NOT be used.		one (1) for 'md5' is not an allowed choice for a hash algorithm and
			MUST NOT be used.
	This document establishes a registry for CachedInformationType types
	and additional values can be added following the policy described in
	Section 7.
	4. Exchange Specification		4. Exchange Specification
	Clients supporting this extension MAY include the		Clients supporting this extension MAY include the "cached_info"
	"cached_information" extension in the (extended) client hello, which		extension in the (extended) client hello. If the client includes the
	MAY contain zero or more CachedObject attributes.		extension then it MUST contain one or more CachedObject attributes.
			Clients and servers MUST NOT include more than one CachedObject
			attribute per info type.
	A server supporting this extension MAY include the		A server supporting this extension MAY include the "cached_info"
	"cached_information" extension in the (extended) server hello, which		extension in the (extended) server hello. By returning the
	MAY contain one or more CachedObject attributes it supports. By		"cached_info" extension the server indicates that it supports the
	returning the "cached_information" extension the server indicates		cached info types. For each indicated cached info type the server
	that it supports caching of each present CachedObject that matches		MUST alters the transmission of respective payloads, as specified for
	the specified hash value. The server MAY support other cached		each type. If the server includes the extension it MUST only include
	objects that are not present in the extension.		CachedObjects of a type also supported by the client (as expressed in
			the client hello).
	Note: If clients make use of the Server Name Indication [RFC6066]		Note that the client includes a fingerprint of the cached information
	then clients may need to cache multiple data items for a single		to give the server enough information to determine whether cached
	server since servers may host multiple 'virtual' servers at a single		information is stale. If the server supports this specification and
	underlying network address.		notices a mismatch between the data cached by the client and its own
			information then the server MUST include the information in full and
			MUST NOT list the respective item in the "cached_info" extension.
	Following a successful exchange of the "cached_information"		Note: Clients may cache multiple data items for a single server if
	extensions in the client and server hello, the server omits sending		those servers are part of a hosting environment. To allow the client
	the corresponding handshake message. How information is omitted from		to select the appropriate information from the cached it is
	the handshake message is defined per cached info type. Section 4.1		RECOMMENDED that the client uses information from the Server Name
	and Section 4.2 defines the syntax of the fingerprinted information.		Indication [RFC6066].
	The handshake protocol MUST proceed using the information as if it		Following a successful exchange of the "cached_info" extensions in
	was provided in the handshake protocol. The Finished message MUST be		the client and server hello, the server alters sending the
	calculated over the actual data exchanged in the handshake protocol.		corresponding handshake message. How information is altered from the
	That is, the Finished message will be calculated over the information		handshake messages is defined per cached info type. Section 4.1 and
	that was omitted from transmission by means of its present hash in		Section 4.2 defines the syntax of the fingerprinted information.
	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 handshake protocol MUST proceed using the information as if it
	information element, i.e., at maximum only one CachedObject structure		was provided in the handshake protocol. Since the Finished message
	per replaced information is provided.		is calculated over the exchanged data it will also include the hash
			of the cached data.
	4.1. Omitting the Certificate Chain		4.1. Omitting the Certificate List
	When an object of type 'certificate_chain' is provided in the client		When an object of type 'certificate_list' is provided in the client
	hello, the server MAY replace the sequence of certificates with an		hello, the server MAY replace the list of certificates with an empty
	empty sequence with an actual length field of zero (=empty vector).		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;
	Note that [I-D.ietf-tls-oob-pubkey] allows the certificate payload to		Note that [RFC7250] allows the certificate payload to contain only
	contain only the SubjectPublicKeyInfo instead of the full information		the SubjectPublicKeyInfo instead of the full information typically
	typically found in a certificate. Hence, when this specification is		found in a certificate. Hence, when this specification is used in
	used in combination with [I-D.ietf-tls-oob-pubkey] and the negotiated		combination with [RFC7250] and the negotiated certificate type is a
	certificate type is a raw public key then the TLS server omits		raw public key then the TLS server omits sending a Certificate
	sending a Certificate payload that contains an ASN.1Cert structure of		payload that contains an ASN.1Cert structure of the
	the SubjectPublicKeyInfo.		SubjectPublicKeyInfo.
	4.2. Omitting the Trusted CAs		4.2. Omitting the Trusted Certificate Authorities
	When a fingerprint for an object of type 'trusted_cas' is provided in		When a fingerprint for an object of type 'certificate_authorities' is
	the client hello, the server MAY send a DistinguishedName in the		provided in the client hello, the server MAY replace the
	Certificate Request message with an actual length field of zero		CertificateRequest message with an empty sequence with an actual
	(=empty vector).		length field of zero.
	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>;
	skipping to change at page 6, line 23 ¶		skipping to change at page 6, line 50 ¶
	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_info" extension, see
	see [2], and indicates that it has stored the certificate_chain from
	the earlier exchange. With [3] the TLS server indicates that it also		[2], and indicates that it has stored the 'certificate_list' from the
	supports this specification and informs the client that it also		earlier exchange. With [3] the TLS server acknowledges the supports
	supports caching of other objects beyond the 'certificate_chain',		of this specification and informs the client that it alterned the
	namely 'trusted_cas' (also defined in this document), and the 'foo-		content of the certificate payload (see [4], as described in
	bar' extension (i.e., an imaginary extension that yet needs to be		Section 4.1).
	defined). With [4] the TLS server omits sending the certificate
	chain, as described in Section 4.1.
	(A) Initial (full) Exchange		(A) Initial (full) Exchange
	client_hello ->		ClientHello ->
	<- server_hello,		<- ServerHello
	certificate, // [1]		Certificate* // [1]
	server_key_exchange,		ServerKeyExchange*
	server_hello_done		CertificateRequest*
			ServerHelloDone
	client_key_exchange,		Certificate*
	change_cipher_spec,		ClientKeyExchange
	finished ->		CertificateVerify*
			[ChangeCipherSpec]
			Finished ->
	<- change_cipher_spec,		<- [ChangeCipherSpec]
	finished		Finished
	Application Data <-------> Application Data		Application Data <-------> Application Data
	(B) TLS Cached Extension Usage		(B) TLS Cached Extension Usage
	client_hello,		ClientHello
	cached_information=(certificate_chain) -> // [2]		cached_info=(certificate_list) -> // [2]
	<- server_hello,		<- ServerHello
	cached_information= // [3]		cached_info=
	(certificate_chain, trusted_cas, foo-bar)		(certificate_list) // [3]
	certificate, // [4]		Certificate* // [4]
	server_key_exchange,		ServerKeyExchange*
	server_hello_done		CertificateRequest*
			ServerHelloDone
	client_key_exchange,		Certificate*
	change_cipher_spec,		ClientKeyExchange
	finished ->		CertificateVerify*
			[ChangeCipherSpec]
			Finished ->
	<- change_cipher_spec,		<- [ChangeCipherSpec]
	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. Sending a fingerprint of cached information in		using a fingerprint. Sending a fingerprint of cached information in
	an unencrypted handshake, as the client and server hello is, may		an unencrypted handshake, as the client and server hello is, may
	allow an attacker or observer to correlate independent TLS exchanges.		allow an attacker or observer to correlate independent TLS exchanges.
	While some information elements used in this specification, such as		While some information elements used in this specification, such as
	server certificates, are public objects and usually not sensitive in		server certificates, are public objects and usually not sensitive in
	this regard, others may be. Those who implement and deploy this		this regard, others may be. Those who implement and deploy this
	specification should therefore make an informed decision whether the		specification should therefore make an informed decision whether the
	cached information is inline with their security and privacy goals.		cached information is inline with their security and privacy goals.
	In case of concerns, it is advised to avoid sending the fingerprint		In case of concerns, it is advised to avoid sending the fingerprint
	of the data objects in clear.		of the data objects in clear.
	The hash algorithm used in this specification is required to have		The hash algorithm used in this specification is required to have
	reasonable random properties in order to provide reasonably unique
	identifiers. There is no requirement that this hash algorithm must
	have strong collision resistance.		have strong collision resistance.
	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_info(TBD) defined
	defined in this document.		in this document.
	7.2. New Registry for CachedInformationType		7.2. New Registry for CachedInformationType
	IANA is requested to establish a registry for TLS		IANA is requested to establish a registry for TLS
	CachedInformationType values. The first entries in the registry are		CachedInformationType values. The first entries in the registry are
	o certificate_chain(1)		o certificate_list(1)
	o trusted_cas(2)		o certificate_authorities(2)
	The policy for adding new values to this registry, following the		The policy for adding new values to this registry, following the
	terminology defined in RFC 5226 [RFC5226], is as follows:		terminology defined in RFC 5226 [RFC5226], is as follows:
	o 0-63 (decimal): Standards Action		o 0-63 (decimal): Standards Action
	o 64-223 (decimal): Specification Required		o 64-223 (decimal): Specification Required
	o 224-255 (decimal): reserved for Private Use		o 224-255 (decimal): reserved for Private Use
	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)
			o Ilari Liusvaara, Adam Langley, and Eric Rescorla (in July 2014)
	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		Sean Turner and Joe Salowey, as well as the responsible security area
	directors, Sean Turner and Stephen Farrell, for their feedback and		director, Stephen Farrell, for his support.
	support.
	9. References		9. References
	9.1. Normative References		9.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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224",		[RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224",
	RFC 3874, September 2004.		RFC 3874, September 2004.
	[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]
	Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
	T. Kivinen, "Using Raw Public Keys in Transport Layer
	Security (TLS) and Datagram Transport Layer Security
	(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		[RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
			T. Kivinen, "Using Raw Public Keys in Transport Layer
			Security (TLS) and Datagram Transport Layer Security
			(DTLS)", RFC 7250, June 2014.
			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
	ARM Ltd.		ARM Ltd.
	110 Fulbourn Rd		Hall in Tirol 6060
	Cambridge CB1 9NJ		Austria
	Great Britain
	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. 47 change blocks.
	155 lines changed or deleted		174 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/