< draft-ietf-dice-profile-08.txt		draft-ietf-dice-profile-09.txt >
	dice H. Tschofenig, Ed.		dice H. Tschofenig, Ed.
	Internet-Draft ARM Ltd.		Internet-Draft ARM Ltd.
	Intended status: Standards Track T. Fossati		Intended status: Standards Track T. Fossati
	Expires: June 24, 2015 Alcatel-Lucent		Expires: July 23, 2015 Alcatel-Lucent
	December 21, 2014		January 19, 2015
	A TLS/DTLS 1.2 Profile for the Internet of Things		A TLS/DTLS 1.2 Profile for the Internet of Things
	draft-ietf-dice-profile-08.txt		draft-ietf-dice-profile-09.txt
	Abstract		Abstract
	A common design pattern in Internet of Things (IoT) deployments is		A common design pattern in Internet of Things (IoT) deployments is
	the use of a constrained device (typically providing sensor data)		the use of a constrained device (typically providing sensor data)
	that makes data available for home automation, industrial control		that makes data available for home automation, industrial control
	systems, smart cities and other IoT deployments.		systems, smart cities and other IoT deployments.
	This document defines a Transport Layer Security (TLS) and Datagram		This document defines a Transport Layer Security (TLS) and Datagram
	TLS 1.2 profile that offers communications security for this data		TLS 1.2 profile that offers communications security for this data
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 24, 2015.		This Internet-Draft will expire on July 23, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. TLS/DTLS Protocol Overview . . . . . . . . . . . . . . . . . 4		3. TLS/DTLS Protocol Overview . . . . . . . . . . . . . . . . . 4
	4. Communication Models . . . . . . . . . . . . . . . . . . . . 5		4. Communication Models . . . . . . . . . . . . . . . . . . . . 5
	4.1. Constrained TLS/DTLS Clients . . . . . . . . . . . . . . 5		4.1. Constrained TLS/DTLS Clients . . . . . . . . . . . . . . 5
	4.2. Constrained TLS/DTLS Servers . . . . . . . . . . . . . . 12		4.2. Constrained TLS/DTLS Servers . . . . . . . . . . . . . . 12
	5. The TLS/DTLS Ciphersuite Concept . . . . . . . . . . . . . . 14		5. The TLS/DTLS Ciphersuite Concept . . . . . . . . . . . . . . 16
	6. Credential Types . . . . . . . . . . . . . . . . . . . . . . 15		6. Credential Types . . . . . . . . . . . . . . . . . . . . . . 18
	6.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 15		6.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 18
	6.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 17		6.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 20
	6.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 19		6.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 22
	7. Signature Algorithm Extension . . . . . . . . . . . . . . . . 22		7. Signature Algorithm Extension . . . . . . . . . . . . . . . . 26
	8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 22		8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 26
	9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 23		9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 28
	10. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 24		10. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 29
	11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 24		11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 29
	12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 25		12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 30
	13. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 27		13. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	14. Random Number Generation . . . . . . . . . . . . . . . . . . 27		14. Random Number Generation . . . . . . . . . . . . . . . . . . 32
	15. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 28		15. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 33
	16. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 29		16. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 34
	17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 29		17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 34
	18. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 29		18. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 34
	19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 30		19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 35
	20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 30		20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 35
	21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 31		21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 36
	22. Key Length Recommendations . . . . . . . . . . . . . . . . . 32		22. Key Length Recommendations . . . . . . . . . . . . . . . . . 37
	23. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 33		23. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 38
	24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34		24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38
	25. Security Considerations . . . . . . . . . . . . . . . . . . . 34		25. Security Considerations . . . . . . . . . . . . . . . . . . . 39
	26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
	27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35		27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
	28. References . . . . . . . . . . . . . . . . . . . . . . . . . 35		28. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
	28.1. Normative References . . . . . . . . . . . . . . . . . . 35		28.1. Normative References . . . . . . . . . . . . . . . . . . 40
	28.2. Informative References . . . . . . . . . . . . . . . . . 36		28.2. Informative References . . . . . . . . . . . . . . . . . 41
	Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 41		Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 46
	A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 41		A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 47
	A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 42		A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 47
	A.3. Multiplexing Security Associations . . . . . . . . . . . 42		A.3. Multiplexing Security Associations . . . . . . . . . . . 48
	A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 43		A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 48
	Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 43		Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 49
	Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 44		Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 50
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
	1. Introduction		1. Introduction
	An engineer developing an Internet of Things (IoT) device needs to		An engineer developing an Internet of Things (IoT) device needs to
	investigate the security threats and decide about the security		investigate the security threats and decide about the security
	services that can be used to mitigate these threats.		services that can be used to mitigate these threats.
	Enabling IoT devices to make data available often requires		Enabling IoT devices to make data available often requires
	authentication of the two endpoints and the ability to provide		authentication of the two endpoints and the ability to provide
	integrity- and confidentiality-protection of exchanged data. While		integrity- and confidentiality-protection of exchanged data. While
	skipping to change at page 12, line 14 ¶		skipping to change at page 12, line 14 ¶
	G| Payload: \ T		G| Payload: \ T
	E| 25.5 --------> \ E		E| 25.5 --------> \ E
	T| \ D		T| \ D
	+--- ///+		+--- ///+
	Figure 4: DTLS/CoAP exchange using Resource Directory.		Figure 4: DTLS/CoAP exchange using Resource Directory.
	4.2. Constrained TLS/DTLS Servers		4.2. Constrained TLS/DTLS Servers
	Section 4.1 illustrates deployment models where the TLS/DTLS client		Section 4.1 illustrates a deployment model where the TLS/DTLS client
	is constrained and efforts need to be taken to improve memory		is constrained and efforts need to be taken to improve memory
	utilization, bandwidth consumption, reduce performance impacts, etc.		utilization, bandwidth consumption, reduce performance impacts, etc.
	In this section we look at cases where constrained devices run TLS/		In this section we look at cases where constrained devices run TLS/
	DTLS servers to secure access to an application layer protocol		DTLS servers to secure access to application layer services running
	server, like a CoAP or HTTP server. Running server functionality on		on top of CoAP, HTTP or other protocols. Running server
	a constrained node is typically more demanding since servers have to		functionality on a constrained node is typically more demanding since
	listen and wait for incoming requests. Therefore, they will have		servers have to wait for incoming requests. Therefore, they will
	fewer possibilities to enter sleeping cycles. Nevertheless, there		have fewer possibilities to enter sleep-cycles. Nevertheless, there
	are legitimate reasons to deploy servers as constrained devices.		are legitimate reasons for deploying servers as constrained devices.
			Figure 5 illustrates a possible deployment whereby a number of
			constrained servers are waiting for regular clients to access their
			resources. The entire process is likely to be controlled by a third
			party, the authentication and authorization server. This
			authentication and authorization server is responsible for holding
			authorization policies (in the form of access control policies) that
			govern the access to resources and distribution of keying material.
			+////////////////////////////////////+
			| Configuration |
			|////////////////////////////////////|
			| Credentials |
			| Client A -> Public Key |
			| Server S1 -> Symmetric Key ,|
			| Server S2 -> Certificate |
			| Server S3 -> Public Key |
			| Trust Anchor Store |
			| Access Control Lists |
			| Resource X: Client A / GET |
			| Resource Y: Client A / PUT |
			+------------------------------------+
			oo
			oooooo
			o
			+---------------+ +-----------+
			|Authentication | +-------->|TLS/DTLS |
			|& Authorization| | |Client A |
			|Server | | +-----------+
			+---------------+ ++
			^ | +-----------+
			\ | |Constrained|
			\ ,-------. | Server S1 |
			,' `. +-----------+
			/ Local \
			( Network )
			\ / +-----------+
			`. ,' |Constrained|
			'---+---' | Server S2 |
			| +-----------+
			|
			| +-----------+
			+-----------------> |Constrained|
			| Server S3 |
			+-----------+
			Figure 5: Constrained Server Profile.
			Figure 6 shows an example interaction whereby a device, a thermostat
			in our case, searches in the local network for discoverable resources
			and accesses those. The thermostat starts the procedure using a
			link-local discovery message using the "All CoAP Nodes" multicast
			address by utilizing the RFC 6690 [RFC6690] link format. The IPv6
			multicast address used for site-local discovery is FF02::FD. As a
			result, a temperature sensor and a fan respond. These responses
			allow the thermostat to subsequently read temperature information
			from the temperature sensor with a CoAP GET request issued to the
			previously learned endpoint. In this hypothetical example we assume
			that this temperature sensor provides this information to every party
			and no access control mechanism is enforced. However, when the
			thermostat subsequently uses the obtained temperature reading to
			control a fan, the fan requires authentication and authorization of
			the entity requesting changes and TLS is used to authenticate both
			endpointas and to secure the communication.
			Temperature
			Thermostat Sensor Fan
			---------- --------- ---
			Discovery
			-------------------->
			GET coap://[FF02::FD]/.well-known/core
			CoAP 2.05 Content
			<-------------------------------
			</3303/0/5700>;rt="temperature";
			if="sensor"
			CoAP 2.05 Content
			<--------------------------------------------------
			</fan>;rt="fan";if="actuation"
			Read Sensor Data (unauthenticated)
			------------------------------->
			GET /3303/0/5700
			CoAP 2.05 Content
			<-------------------------------
			22.5 C
			+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
			\ /
			\ Protocol steps to obtain authorization token / client /
			\ credentials for access to the fan-provided resources. /
			\ /
			+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
			Configure Actuator (with authorization credentials)
			--------------------------------------------------
			PUT /fan?on-off=true
			CoAP 2.04 Changed
			<-------------------------------------------------
			Figure 6: Local Discovery and Resouce Access.
	A deployment with constrained servers has to overcome several		A deployment with constrained servers has to overcome several
	challenges. Later we will explain how these challenges has been		challenges. Below we explain how these challenges have been solved
	solved using CoAP as an example. Other protocols may offer similar		with CoAP, as an example. Other protocols may offer similar
	capabilities. While the requirements for the TLS/DTLS protocol		capabilities. While the requirements for the TLS/DTLS protocol
	profile change only slightly when run on a constrained server (in		profile change only slightly when run on a constrained server (in
	comparison to running it on a constrained client) several other eco-		comparison to running it on a constrained client) several other eco-
	system factor will impact deployment.		system factor will impact deployment.
	The challenges are:		The challenges are:
	Discovery and Reachability:		Discovery and Reachability:
	Before initiating a connection to a constrained server a client		Before initiating a connection to a constrained server a client
	skipping to change at page 13, line 45 ¶		skipping to change at page 16, line 35 ¶
	infra-red communication in addition to WiFi)		infra-red communication in addition to WiFi)
	* Proximity-based information		* Proximity-based information
	More details about these different pairing/imprinting techniques		More details about these different pairing/imprinting techniques
	can be found in the smart object security workshop report		can be found in the smart object security workshop report
	[RFC7397] and various position papers submitted to that topic,		[RFC7397] and various position papers submitted to that topic,
	such as [ImprintingSurvey]. The use of a trusted third party		such as [ImprintingSurvey]. The use of a trusted third party
	follows a different approach and is subject to ongoing		follows a different approach and is subject to ongoing
	standardization efforts in the 'Authentication and Authorization		standardization efforts in the 'Authentication and Authorization
	for Constrained Environments (ACE)' working group.		for Constrained Environments (ACE)' working group [ACE-WG].
	Authorization		Authorization
	The last challenge is the ability for the constrained server to		The last challenge is the ability for the constrained server to
	make an authorization decision when clients access protected		make an authorization decision when clients access protected
	resources. Pre-provisioning access control information to		resources. Pre-provisioning access control information to
	constrained servers may be one option but works only in a small		constrained servers may be one option but works only in a small
	scale, less dynamic environment. For a more fine-grained and		scale, less dynamic environment. For a more fine-grained and
	dynamic access control the reader is referred to the ongoing work		dynamic access control the reader is referred to the ongoing work
	in the ACE working group.		in the ACE working group.
	skipping to change at page 15, line 30 ¶		skipping to change at page 18, line 22 ¶
	algorithm and the hash functions used with the TLS PRF.		algorithm and the hash functions used with the TLS PRF.
	6. Credential Types		6. Credential Types
	6.1. Pre-Shared Secret		6.1. Pre-Shared Secret
	The use of pre-shared secret credentials is one of the most basic		The use of pre-shared secret credentials is one of the most basic
	techniques for TLS/DTLS since it is both computational efficient and		techniques for TLS/DTLS since it is both computational efficient and
	bandwidth conserving. Pre-shared secret based authentication was		bandwidth conserving. Pre-shared secret based authentication was
	introduced to TLS with RFC 4279 [RFC4279]. The exchange shown in		introduced to TLS with RFC 4279 [RFC4279]. The exchange shown in
	Figure 5 illustrates the DTLS exchange including the cookie exchange.		Figure 7 illustrates the DTLS exchange including the cookie exchange.
	While the server is not required to initiate a cookie exchange with		While the server is not required to initiate a cookie exchange with
	every handshake, the client is required to implement and to react on		every handshake, the client is required to implement and to react on
	it when challenged. The cookie exchange allows the server to react		it when challenged. The cookie exchange allows the server to react
	to flooding attacks.		to flooding attacks.
	Client Server		Client Server
	------ ------		------ ------
	ClientHello -------->		ClientHello -------->
	<-------- HelloVerifyRequest		<-------- HelloVerifyRequest
	skipping to change at page 16, line 29 ¶		skipping to change at page 19, line 29 ¶
	Finished -------->		Finished -------->
	ChangeCipherSpec		ChangeCipherSpec
	<-------- Finished		<-------- Finished
	Application Data <-------> Application Data		Application Data <-------> Application Data
	Legend:		Legend:
	* indicates an optional message payload		* indicates an optional message payload
	Figure 5: DTLS PSK Authentication including the Cookie Exchange.		Figure 7: DTLS PSK Authentication including the Cookie Exchange.
	[RFC4279] does not mandate the use of any particular type of client		[RFC4279] does not mandate the use of any particular type of client
	identity and the client and server have to agree on the identities		identity and the client and server have to agree on the identities
	and keys to be used. The mandated encoding of identities in		and keys to be used. The mandated encoding of identities in
	Section 5.1 of RFC 4279 aims to improve interoperability for those		Section 5.1 of RFC 4279 aims to improve interoperability for those
	cases where the identity is configured by a person using some		cases where the identity is configured by a person using some
	management interface. Many IoT devices do, however, not have a user		management interface. Many IoT devices do, however, not have a user
	interface and most of their credentials are bound to the device		interface and most of their credentials are bound to the device
	rather than the user. Furthermore, credentials are often provisioned		rather than the user. Furthermore, credentials are often provisioned
	into trusted hardware modules or in the firmware by developers. As		into trusted hardware modules or in the firmware by developers. As
	skipping to change at page 17, line 46 ¶		skipping to change at page 20, line 46 ¶
	TLS_PSK_WITH_AES_128_CCM_8 and follow the guidance from this section.		TLS_PSK_WITH_AES_128_CCM_8 and follow the guidance from this section.
	6.2. Raw Public Key		6.2. Raw Public Key
	The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is		The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is
	the first entry point into public key cryptography without having to		the first entry point into public key cryptography without having to
	pay the price of certificates and a public key infrastructure (PKI).		pay the price of certificates and a public key infrastructure (PKI).
	The specification re-uses the existing Certificate message to convey		The specification re-uses the existing Certificate message to convey
	the raw public key encoded in the SubjectPublicKeyInfo structure. To		the raw public key encoded in the SubjectPublicKeyInfo structure. To
	indicate support two new extensions had been defined, as shown in		indicate support two new extensions had been defined, as shown in
	Figure 6, namely the server_certificate_type*' and the		Figure 8, namely the server_certificate_type*' and the
	client_certificate_type. To operate this mechanism securely it is		client_certificate_type. To operate this mechanism securely it is
	necessary to authenticate and authorize the public keys out-of-band.		necessary to authenticate and authorize the public keys out-of-band.
	This document therefore assumes that a client implementation comes		This document therefore assumes that a client implementation comes
	with one or multiple raw public keys of servers, it has to		with one or multiple raw public keys of servers, it has to
	communicate with, pre-provisioned. Additionally, a device will have		communicate with, pre-provisioned. Additionally, a device will have
	its own raw public key. To replace, delete, or add raw public key to		its own raw public key. To replace, delete, or add raw public key to
	this list requires a software update, for example using a firmware		this list requires a software update, for example using a firmware
	update mechanism.		update mechanism.
	Client Server		Client Server
	skipping to change at page 18, line 35 ¶		skipping to change at page 21, line 35 ¶
	CertificateVerify		CertificateVerify
	[ChangeCipherSpec]		[ChangeCipherSpec]
	Finished -------->		Finished -------->
	[ChangeCipherSpec]		[ChangeCipherSpec]
	<-------- Finished		<-------- Finished
	Note: Extensions marked with '*' were introduced with		Note: Extensions marked with '*' were introduced with
	RFC 7250.		RFC 7250.
	Figure 6: DTLS Raw Public Key Exchange including the Cookie Exchange.		Figure 8: DTLS Raw Public Key Exchange including the Cookie Exchange.
	The CoAP recommended ciphersuite for use with this credential type is		The CoAP recommended ciphersuite for use with this credential type is
	TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This elliptic curve		TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This elliptic curve
	cryptography (ECC) based AES-CCM TLS ciphersuite uses the Ephemeral		cryptography (ECC) based AES-CCM TLS ciphersuite uses the Ephemeral
	Elliptic Curve Diffie-Hellman (ECDHE) as the key establishment		Elliptic Curve Diffie-Hellman (ECDHE) as the key establishment
	mechanism and an Elliptic Curve Digital Signature Algorithm (ECDSA)		mechanism and an Elliptic Curve Digital Signature Algorithm (ECDSA)
	for authentication. Due to the use of Ephemeral Elliptic Curve		for authentication. Due to the use of Ephemeral Elliptic Curve
	Diffie-Hellman (ECDHE) the recently introduced named Diffie-Hellman		Diffie-Hellman (ECDHE) the recently introduced named Diffie-Hellman
	groups [I-D.ietf-tls-negotiated-dl-dhe] are not applicable to this		groups [I-D.ietf-tls-negotiated-dl-dhe] are not applicable to this
	profile. This ciphersuite make use of the AEAD capability in DTLS		profile. This ciphersuite make use of the AEAD capability in DTLS
	skipping to change at page 19, line 17 ¶		skipping to change at page 22, line 17 ¶
	methods that have been available in the literature for a long time		methods that have been available in the literature for a long time
	(i.e., 20 years and more).		(i.e., 20 years and more).
	A device compliant with the profile in this section MUST implement		A device compliant with the profile in this section MUST implement
	TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this		TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this
	section.		section.
	6.3. Certificates		6.3. Certificates
	The use of mutual certificate-based authentication is shown in		The use of mutual certificate-based authentication is shown in
	Figure 7, which makes use of the cached info extension		Figure 9, which makes use of the cached info extension
	[I-D.ietf-tls-cached-info]. Support of the cached info extension is		[I-D.ietf-tls-cached-info]. Support of the cached info extension is
	REQUIRED. Caching certificate chains allows the client to reduce the		REQUIRED. Caching certificate chains allows the client to reduce the
	communication overhead significantly since otherwise the server would		communication overhead significantly since otherwise the server would
	provide the end entity certificate, and the certificate chain.		provide the end entity certificate, and the certificate chain.
	Because certificate validation requires that root keys be distributed		Because certificate validation requires that root keys be distributed
	independently, the self-signed certificate that specifies the root		independently, the self-signed certificate that specifies the root
	certificate authority is omitted from the chain. Client		certificate authority is omitted from the chain. Client
	implementations MUST be provisioned with a trust anchor store that		implementations MUST be provisioned with a trust anchor store that
	contains the root certificates. The use of the Trust Anchor		contains the root certificates. The use of the Trust Anchor
	Management Protocol (TAMP) [RFC5934] is, however, not envisioned.		Management Protocol (TAMP) [RFC5934] is, however, not envisioned.
	Instead IoT devices using this profile MUST use a software update		Instead IoT devices using this profile MUST use a software update
	mechanism to populate the trust anchor store.		mechanism to populate the trust anchor store.
	Client Server		Client Server
	------ ------		------ ------
	ClientHello -------->		ClientHello -------->
	*cached_information*		*cached_info*
	ServerHello		ServerHello
	*cached_information*		*cached_info*
	Certificate		Certificate
	ServerKeyExchange		ServerKeyExchange
	CertificateRequest		CertificateRequest
	<-------- ServerHelloDone		<-------- ServerHelloDone
	Certificate		Certificate
	ClientKeyExchange		ClientKeyExchange
	CertificateVerify		CertificateVerify
	[ChangeCipherSpec]		[ChangeCipherSpec]
	Finished -------->		Finished -------->
	[ChangeCipherSpec]		[ChangeCipherSpec]
	<-------- Finished		<-------- Finished
	Note: Extensions marked with '*' were introduced with		Note: Extensions marked with '*' were introduced with
	[I-D.ietf-tls-cached-info].		[I-D.ietf-tls-cached-info].
	Figure 7: DTLS Mutual Certificate-based Authentication.		Figure 9: DTLS Mutual Certificate-based Authentication.
	When DTLS is used to secure CoAP messages then the server provided		Server certificates MUST contain the fully qualified DNS domain name
	certificates MUST contain the fully qualified DNS domain name or		or "FQDN" as dNSName. For CoAP, the coaps URI scheme is described in
	"FQDN" as dNSName. The coaps URI scheme is described in Section 6.2		Section 6.2 of [RFC7252]. This FQDN is stored in the SubjectAltName
	of [RFC7252]. This FQDN is stored in the SubjectAltName or in the		or in the leftmost CN component of subject name, as explained in
	leftmost CN component of subject name, as explained in
	Section 9.1.3.3 of [RFC7252], and used by the client to match it		Section 9.1.3.3 of [RFC7252], and used by the client to match it
	against the FQDN used during the look-up process, as described in RFC		against the FQDN used during the look-up process, as described in RFC
	6125 [RFC6125]. For the profile in this specification does not		6125 [RFC6125]. For other protocols, the appropriate URI scheme
	assume dynamic discovery of local servers.		specification has to be consulted.
			When constrained servers are used, for example in context of locally
			discoverable services as shown in Figure 6, then the rules of client
			certificates are applicable since these constrained servers are less
			likely to have an FQDN configured. Note that the Service Name
			Indication (SNI) extension cannot be used in this case since SNI does
			not offer the ability to convey EUI-64 identifiers.
	For client certificates the identifier used in the SubjectAltName or		For client certificates the identifier used in the SubjectAltName or
	in the CN MUST be an EUI-64 [EUI64], as mandated in Section 9.1.3.3		in the leftmost CN component of subject name MUST be an EUI-64
	of [RFC7252].		[EUI64], as mandated in Section 9.1.3.3 of [RFC7252].
	For certificate revocation neither the Online Certificate Status		For certificate revocation neither the Online Certificate Status
	Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used.		Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used.
	Instead, this profile relies on a software update mechanism. While		Instead, this profile relies on a software update mechanism. While
	multiple OCSP stapling [RFC6961] has recently been introduced as a		multiple OCSP stapling [RFC6961] has recently been introduced as a
	mechanism to piggyback OCSP request/responses inside the DTLS/TLS		mechanism to piggyback OCSP request/responses inside the DTLS/TLS
	handshake to avoid the cost of a separate protocol handshake further		handshake to avoid the cost of a separate protocol handshake further
	investigations are needed to determine its suitability for the IoT		investigations are needed to determine its suitability for the IoT
	environment.		environment.
	Regarding the ciphersuite choice the discussion in Section 6.2		Regarding the ciphersuite choice the discussion in Section 6.2
	applies. Further details about X.509 certificates can be found in		applies. Further details about X.509 certificates can be found in
	Section 9.1.3.3 of [RFC7252]. The TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8		Section 9.1.3.3 of [RFC7252]. The TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
	ciphersuite description in Section 6.2 is also applicable to this		ciphersuite description in Section 6.2 is also applicable to this
	section.		section.
	When using certificates, IoT devices MUST provide support for a		When using certificates, IoT devices MUST provide support for a
	server certificate chain of at least 3 not including the trust anchor		server certificate chain of at least 3 not including the trust anchor
	and MAY reject connections from servers offering chains longer than		and MAY reject connections from servers offering chains longer than
	3. IoT devices MAY have client certificate chains of any length.		3. IoT devices MAY have client certificate chains of any length.
	Obviously, longer chains require more resources to process, transmit		Obviously, longer chains require more digital signature verification
	or receive.		operations to perform and lead to larger certificate messages in the
			TLS handshake.
			Table 1 provides a summary of the elements in a certificate for use
			with this profile.
			+---------------+---------------------------------------------------+
			| Element | Notes |
			+---------------+---------------------------------------------------+
			| Version | This profile uses the X.509 v3 certificate |
			| | [RFC5280]. |
			| | |
			| Serial Number | Positive integer unique per certificate. |
			| | |
			| Issuer | This profile uses ecdsa-with-SHA256 or stronger |
			| Signature | [RFC5758]. |
			| Algorithms | |
			| | |
			| Issuer | Contains the DN of the issuing CA. |
			| Distinguished | |
			| Name | |
			| | |
			| Validity | Values expressed as UTC time. No validity period |
			| Period | mandated. |
			| | |
			| Subject | See rules outlined in this section. |
			| Distinguished | |
			| Name | |
			| | |
			| Subject | This element contains the ECDSA signature |
			| Public Key | certificate. The algorithm field in the |
			| Information | SubjectPublicKeyInfo structure indicates the |
			| | algorithm and any associated parameters for the |
			| | ECC public key. This profile uses the id- |
			| | ecPublicKey algorithm identifier. |
			| | |
			| Issuer's | Includes the ECDSA signature with ecdsa-with- |
			| Signature | SHA256 or stronger. |
			| | |
			| Extension: | See rules outlined in this section. |
			| Subject | |
			| Alternative | |
			| Name | |
			| | |
			| Extension: | Indicates whether the subject of the certificate |
			| Basic | is a CA. This extension is used for CA certs only |
			| Constraints | and then the value is set to TRUE. The default is |
			| | FALSE. |
			| | |
			| Extension: | digitalSignature or keyAgreement, keyCertSign for |
			| Key Usage | verifying signatures on public key certificates. |
			| | |
			| Extension: | id-kp-serverAuth for server authentication, id- |
			| Extended Key | kp-clientAuth for client authentication, id-kp- |
			| Usage | codeSigning for code signing (for software update |
			| | mechanism), id-kp-OCSPSigning for future OCSP |
			| | usage in TLS. |
			+---------------+---------------------------------------------------+
			Table 1: Certificate Content.
			All certificate elements listed in Table 1 are mandatory-to-
			implement. No other certificate elements are used by this
			specification.
	A device compliant with the profile in this section MUST implement		A device compliant with the profile in this section MUST implement
	TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this		TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this
	section.		section.
	6.3.1. Client Certificate URLs		6.3.1. Client Certificate URLs
	RFC 6066 [RFC6066] allows to avoid sending client-side certificates		RFC 6066 [RFC6066] allows to avoid sending client-side certificates
	and uses URLs instead. This reduces the over-the-air transmission.		and uses URLs instead. This reduces the over-the-air transmission.
	Note that the TLS cached info extension does not provide any help		Note that the TLS cached info extension does not provide any help
	with caching client certificates.		with caching client certificates.
	TLS/DTLS clients MUST implement support for client certificate URLs		TLS/DTLS clients MUST implement support for client certificate URLs
	for those environments where client-side certificates are used.		for those environments where client-side certificates are used and
			the server-side is not constrained. For constrained servers this
			functionality is NOT RECOMMENDED since it forces the server to
			execute an additional protocol exchange, potentially using a protocol
			it does not even support. The use of this extension also increases
			the risk of a denial of service attack against the constrained server
			due to the additional workload.
	6.3.2. Trusted CA Indication		6.3.2. Trusted CA Indication
	RFC 6066 [RFC6066] allows clients to indicate what trust anchor they		RFC 6066 [RFC6066] allows clients to indicate what trust anchor they
	support. With certificate-based authentication a DTLS server conveys		support. With certificate-based authentication a DTLS server conveys
	its end entity certificate to the client during the DTLS exchange		its end entity certificate to the client during the DTLS exchange
	provides. Since the server does not necessarily know what trust		provides. Since the server does not necessarily know what trust
	anchors the client has stored it includes intermediate CA certs in		anchors the client has stored it includes intermediate CA certs in
	the certificate payload as well to facilitate with certification path		the certificate payload as well to facilitate with certification path
	construction and path validation.		construction and path validation.
	Today, in most IoT deployments there is a fairly static relationship		Today, in most IoT deployments there is a fairly static relationship
	between the IoT device (and the software running on them) and the		between the IoT device (and the software running on them) and the
	server- side infrastructure and no such dynamic indication of trust		server-side infrastructure. For these deployments where IoT devices
	anchors is needed.		interact with a fixed, pre-configured set of servers this extension
			is NOT RECOMMENDED.
	For deployments where IoT devices interact with a fixed, pre-		In cases where client interact with dynamically discovered TLS/DTLS
	configured set of servers and where a software update mechanism is		servers, for example in the use cases described in Section 4.2, the
	available this extension is NOT RECOMMENDED. Environments where the		use of this extension is RECOMMENDED.
	client needs to interact with dynamically discovered TLS/DTLS servers
	the use of this extension is RECOMMENDED.
	7. Signature Algorithm Extension		7. Signature Algorithm Extension
	The "signature_algorithms" extension, defined in Section 7.4.1.4.1 of		The "signature_algorithms" extension, defined in Section 7.4.1.4.1 of
	RFC 5246 [RFC5246], allows the client to indicate to the server which		RFC 5246 [RFC5246], allows the client to indicate to the server which
	signature/hash algorithm pairs may be used in digital signatures.		signature/hash algorithm pairs may be used in digital signatures.
	The client MUST send this extension to select the use of SHA-256		The client MUST send this extension to select the use of SHA-256
	since otherwise absent this extension RFC 5246 defaults to SHA-1 /		since otherwise absent this extension RFC 5246 defaults to SHA-1 /
	ECDSA for the ECDH_ECDSA and the ECDHE_ECDSA key exchange algorithms.		ECDSA for the ECDH_ECDSA and the ECDHE_ECDSA key exchange algorithms.
	skipping to change at page 23, line 43 ¶		skipping to change at page 28, line 21 ¶
	one ciphersuite per profile but it is likely that additional		one ciphersuite per profile but it is likely that additional
	ciphtersuites get added over time.		ciphtersuites get added over time.
	user_canceled: Many IoT devices are unattended and hence this error		user_canceled: Many IoT devices are unattended and hence this error
	message is unlikely to occur.		message is unlikely to occur.
	9. Session Resumption		9. Session Resumption
	Session resumption is a feature of the core TLS/DTLS specifications		Session resumption is a feature of the core TLS/DTLS specifications
	that allows a client to continue with an earlier established session		that allows a client to continue with an earlier established session
	state. The resulting exchange is shown in Figure 8. In addition,		state. The resulting exchange is shown in Figure 10. In addition,
	the server may choose not to do a cookie exchange when a session is		the server may choose not to do a cookie exchange when a session is
	resumed. Still, clients have to be prepared to do a cookie exchange		resumed. Still, clients have to be prepared to do a cookie exchange
	with every handshake. The cookie exchange is not shown in the		with every handshake. The cookie exchange is not shown in the
	figure.		figure.
	Client Server		Client Server
	------ ------		------ ------
	ClientHello -------->		ClientHello -------->
	ServerHello		ServerHello
	[ChangeCipherSpec]		[ChangeCipherSpec]
	<-------- Finished		<-------- Finished
	[ChangeCipherSpec]		[ChangeCipherSpec]
	Finished -------->		Finished -------->
	Application Data <-------> Application Data		Application Data <-------> Application Data
	Figure 8: DTLS Session Resumption.		Figure 10: DTLS Session Resumption.
	Constrained clients MUST implement session resumption to improve the		Constrained clients MUST implement session resumption to improve the
	performance of the handshake. This will lead to a reduced number of		performance of the handshake. This will lead to a reduced number of
	message exchanges, lower computational overhead (since only symmetric		message exchanges, lower computational overhead (since only symmetric
	cryptography is used during a session resumption exchange), and		cryptography is used during a session resumption exchange), and
	session resumption requires less bandwidth.		session resumption requires less bandwidth.
	For cases where the server is constrained (but not the client) the		For cases where the server is constrained (but not the client) the
	client MUST implement RFC 5077 [RFC5077]. RFC 5077 specifies a		client MUST implement RFC 5077 [RFC5077]. RFC 5077 specifies a
	version of TLS/DTLS session resumption that does not require per-		version of TLS/DTLS session resumption that does not require per-
	skipping to change at page 28, line 42 ¶		skipping to change at page 33, line 16 ¶
	gmt_unix_time followed by a random sequence of 28 random bytes since		gmt_unix_time followed by a random sequence of 28 random bytes since
	the client can use the received time information to securely obtain		the client can use the received time information to securely obtain
	time information. For constrained servers it cannot be assumed that		time information. For constrained servers it cannot be assumed that
	they maintain accurate time information; these devices MUST include		they maintain accurate time information; these devices MUST include
	time information in the Server.Random structure when they actually		time information in the Server.Random structure when they actually
	obtain accurate time information that can be utilized by clients.		obtain accurate time information that can be utilized by clients.
	Clients MUST only use time information obtained from servers they		Clients MUST only use time information obtained from servers they
	trust.		trust.
	IoT devices using TLS/DTLS MUST offer ways to generate quality random		IoT devices using TLS/DTLS MUST offer ways to generate quality random
	numbers. Guidelines and requirements for random number generation		numbers. Note that these hardware-based random number generators do
	can be found in RFC 4086 [RFC4086].		not necessarily need to be implemented inside the microcontroller
			itself but could be made available in dedicated crypto-chips as well.
			Guidelines and requirements for random number generation can be found
			in RFC 4086 [RFC4086] and in the NIST Special Publication 800-90a
			[SP800-90A].
			Chip manufacturers are highly encouraged to provide sufficient
			documentation of their design for random number generators so that
			customers can have confidence about the quality of the generated
			random numbers. The confidence can be increased by providing
			information about the procedures that have been used to verify the
			randomness of numbers generated by the hardware modules. For
			example, NIST Special Publication 800-22b [SP800-22b] describes
			statistical tests that can be used to verify random random number
			generators.
	15. Truncated MAC and Encrypt-then-MAC Extension		15. Truncated MAC and Encrypt-then-MAC Extension
	The truncated MAC extension was introduced with RFC 6066 [RFC6066]		The truncated MAC extension was introduced with RFC 6066 [RFC6066]
	with the goal to reduce the size of the MAC used at the Record Layer.		with the goal to reduce the size of the MAC used at the Record Layer.
	This extension was developed for TLS ciphersuites that used older		This extension was developed for TLS ciphersuites that used older
	modes of operation where the MAC and the encryption operation was		modes of operation where the MAC and the encryption operation was
	performed independently.		performed independently.
	The recommended ciphersuites in this document use the newer		The recommended ciphersuites in this document use the newer
	skipping to change at page 32, line 41 ¶		skipping to change at page 37, line 29 ¶
	combination with the Poly1305 authenticator		combination with the Poly1305 authenticator
	[I-D.irtf-cfrg-chacha20-poly1305]. The assumption is made that a		[I-D.irtf-cfrg-chacha20-poly1305]. The assumption is made that a
	robust software update mechanism is offered.		robust software update mechanism is offered.
	22. Key Length Recommendations		22. Key Length Recommendations
	RFC 4492 [RFC4492] gives approximate comparable key sizes for		RFC 4492 [RFC4492] gives approximate comparable key sizes for
	symmetric- and asymmetric-key cryptosystems based on the best-known		symmetric- and asymmetric-key cryptosystems based on the best-known
	algorithms for attacking them. While other publications suggest		algorithms for attacking them. While other publications suggest
	slightly different numbers, such as [Keylength], the approximate		slightly different numbers, such as [Keylength], the approximate
	relationship still holds true. Figure 9 illustrates the comparable		relationship still holds true. Figure 11 illustrates the comparable
	key sizes in bits.		key sizes in bits.
	At the time of writing the key size recommendations for use with TLS-		At the time of writing the key size recommendations for use with TLS-
	based ciphers found in [I-D.ietf-uta-tls-bcp] recommend DH key		based ciphers found in [I-D.ietf-uta-tls-bcp] recommend DH key
	lengths of at least 2048 bit, which corresponds to a 112-bit		lengths of at least 2048 bit, which corresponds to a 112-bit
	symmetric key and a 233 bit ECC keys. These recommendations are		symmetric key and a 233 bit ECC keys. These recommendations are
	inline with those from other organizations, such as National		inline with those from other organizations, such as National
	Institute of Standards and Technology (NIST) or European Network and		Institute of Standards and Technology (NIST) or European Network and
	Information Security Agency (ENISA). The authors of		Information Security Agency (ENISA). The authors of
	[ENISA-Report2013] add that a symmetric 80-bit security level is		[ENISA-Report2013] add that a symmetric 80-bit security level is
	skipping to change at page 33, line 19 ¶		skipping to change at page 38, line 13 ¶
	long lived data.		long lived data.
	Symmetric | ECC | DH/DSA/RSA		Symmetric | ECC | DH/DSA/RSA
	------------+---------+-------------		------------+---------+-------------
	80 | 163 | 1024		80 | 163 | 1024
	112 | 233 | 2048		112 | 233 | 2048
	128 | 283 | 3072		128 | 283 | 3072
	192 | 409 | 7680		192 | 409 | 7680
	256 | 571 | 15360		256 | 571 | 15360
	Figure 9: Comparable Key Sizes (in bits).		Figure 11: Comparable Key Sizes (in bits).
	23. False Start		23. False Start
	A full TLS handshake as specified in [RFC5246] requires two full		A full TLS handshake as specified in [RFC5246] requires two full
	protocol rounds (four flights) before the handshake is complete and		protocol rounds (four flights) before the handshake is complete and
	the protocol parties may begin to send application data.		the protocol parties may begin to send application data.
	An abbreviated handshake (resuming an earlier TLS session) is		An abbreviated handshake (resuming an earlier TLS session) is
	complete after three flights, thus adding just one round-trip time if		complete after three flights, thus adding just one round-trip time if
	the client sends application data first.		the client sends application data first.
	skipping to change at page 34, line 50 ¶		skipping to change at page 39, line 41 ¶
	analysis more difficult is provided by the recommendations made in		analysis more difficult is provided by the recommendations made in
	this document.		this document.
	25. Security Considerations		25. Security Considerations
	This entire document is about security.		This entire document is about security.
	We would also like to point out that designing a software update		We would also like to point out that designing a software update
	mechanism into an IoT system is crucial to ensure that both		mechanism into an IoT system is crucial to ensure that both
	functionality can be enhanced and that potential vulnerabilities can		functionality can be enhanced and that potential vulnerabilities can
	be fixed. This software update mechanism is also useful for changing		be fixed. This software update mechanism is important for changing
	configuration information, for example, trust anchors and other		configuration information, for example, trust anchors and other
	keying related information.		keying related information. Such a suitable software update
			mechanism is available with the Lightweight Machine-to-Machine
			(LWM2M) protocol published by the Open Mobile Alliance (OMA) [LWM2M].
	26. IANA Considerations		26. IANA Considerations
	This document includes no request to IANA.		This document includes no request to IANA.
	27. Acknowledgements		27. Acknowledgements
	Thanks to Paul Bakker, Robert Cragie, Russ Housley, Rene Hummen,		Thanks to Paul Bakker, Robert Cragie, Russ Housley, Rene Hummen,
	Matthias Kovatsch, Sandeep Kumar, Sye Loong Keoh, Alexey Melnikov,		Matthias Kovatsch, Sandeep Kumar, Sye Loong Keoh, Alexey Melnikov,
	Manuel Pegourie-Gonnard, Akbar Rahman, Eric Rescorla, Michael		Manuel Pegourie-Gonnard, Akbar Rahman, Eric Rescorla, Michael
	skipping to change at page 36, line 49 ¶		skipping to change at page 41, line 42 ¶
	[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-		[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
	CCM Elliptic Curve Cryptography (ECC) Cipher Suites for		CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
	TLS", RFC 7251, June 2014.		TLS", RFC 7251, June 2014.
	[WAP-WDP] Wireless Application Protocol Forum, "Wireless Datagram		[WAP-WDP] Wireless Application Protocol Forum, "Wireless Datagram
	Protocol", June 2001.		Protocol", June 2001.
	28.2. Informative References		28.2. Informative References
			[ACE-WG] IETF, "Authentication and Authorization for Constrained
			Environments (ace) Working Group", URL:
			https://datatracker.ietf.org/wg/ace/charter/, Jan 2015.
	[AES] NIST, "FIPS PUB 197, Advanced Encryption Standard (AES)",		[AES] NIST, "FIPS PUB 197, Advanced Encryption Standard (AES)",
	http://www.iana.org/assignments/tls-parameters/		http://www.iana.org/assignments/tls-parameters/
	tls-parameters.xhtml#tls-parameters-4, November 2001.		tls-parameters.xhtml#tls-parameters-4, November 2001.
	[ENISA-Report2013]		[ENISA-Report2013]
	ENISA, "Algorithms, Key Sizes and Parameters Report -		ENISA, "Algorithms, Key Sizes and Parameters Report -
	2013", http://www.enisa.europa.eu/activities/identity-and-		2013", http://www.enisa.europa.eu/activities/identity-and-
	trust/library/deliverables/		trust/library/deliverables/
	algorithms-key-sizes-and-parameters-report, October 2013.		algorithms-key-sizes-and-parameters-report, October 2013.
	skipping to change at page 38, line 33 ¶		skipping to change at page 43, line 33 ¶
	ietf-tls-sslv3-diediedie-00 (work in progress), December		ietf-tls-sslv3-diediedie-00 (work in progress), December
	2014.		2014.
	[I-D.ietf-uta-tls-bcp]		[I-D.ietf-uta-tls-bcp]
	Sheffer, Y., Holz, R., and P. Saint-Andre,		Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of TLS and DTLS", draft-		"Recommendations for Secure Use of TLS and DTLS", draft-
	ietf-uta-tls-bcp-08 (work in progress), December 2014.		ietf-uta-tls-bcp-08 (work in progress), December 2014.
	[I-D.irtf-cfrg-chacha20-poly1305]		[I-D.irtf-cfrg-chacha20-poly1305]
	Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF		Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
	protocols", draft-irtf-cfrg-chacha20-poly1305-03 (work in		protocols", draft-irtf-cfrg-chacha20-poly1305-07 (work in
	progress), November 2014.		progress), January 2015.
	[I-D.mathewson-no-gmtunixtime]		[I-D.mathewson-no-gmtunixtime]
	Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in		Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in
	TLS", draft-mathewson-no-gmtunixtime-00 (work in		TLS", draft-mathewson-no-gmtunixtime-00 (work in
	progress), December 2013.		progress), December 2013.
	[I-D.schmertmann-dice-ccm-psk-pfs]		[I-D.schmertmann-dice-ccm-psk-pfs]
	Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher		Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher
	Suites with Forward Secrecy for Transport Layer Security		Suites with Forward Secrecy for Transport Layer Security
	(TLS)", draft-schmertmann-dice-ccm-psk-pfs-01 (work in		(TLS)", draft-schmertmann-dice-ccm-psk-pfs-01 (work in
	skipping to change at page 39, line 15 ¶		skipping to change at page 44, line 15 ¶
	[ImprintingSurvey]		[ImprintingSurvey]
	Chilton, E., "A Brief Survey of Imprinting Options for		Chilton, E., "A Brief Survey of Imprinting Options for
	Constrained Devices", URL: http://www.lix.polytechnique.fr		Constrained Devices", URL: http://www.lix.polytechnique.fr
	/hipercom/SmartObjectSecurity/papers/EricRescorla.pdf,		/hipercom/SmartObjectSecurity/papers/EricRescorla.pdf,
	March 2012.		March 2012.
	[Keylength]		[Keylength]
	Giry, D., "Cryptographic Key Length Recommendations",		Giry, D., "Cryptographic Key Length Recommendations",
	http://www.keylength.com, November 2014.		http://www.keylength.com, November 2014.
			[LWM2M] Open Mobile Alliance, "Lightweight Machine-to-Machine,
			Technical Specification, Candidate Version 1.0", December
			2013.
	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	November 1990.		November 1990.
	[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery		[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
	for IP version 6", RFC 1981, August 1996.		for IP version 6", RFC 1981, August 1996.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104, February		Hashing for Message Authentication", RFC 2104, February
	1997.		1997.
	skipping to change at page 40, line 18 ¶		skipping to change at page 45, line 21 ¶
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois		[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
	Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,		Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
	August 2008.		August 2008.
			[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
			Polk, "Internet X.509 Public Key Infrastructure:
			Additional Algorithms and Identifiers for DSA and ECDSA",
			RFC 5758, January 2010.
	[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor		[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
	Management Protocol (TAMP)", RFC 5934, August 2010.		Management Protocol (TAMP)", RFC 5934, August 2010.
	[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic		[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
	Curve Cryptography Algorithms", RFC 6090, February 2011.		Curve Cryptography Algorithms", RFC 6090, February 2011.
	[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for		[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
	Transport Layer Security (TLS)", RFC 6655, July 2012.		Transport Layer Security (TLS)", RFC 6655, July 2012.
	[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link		[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
	skipping to change at page 41, line 9 ¶		skipping to change at page 46, line 20 ¶
	Constrained Application Protocol (CoAP)", RFC 7390,		Constrained Application Protocol (CoAP)", RFC 7390,
	October 2014.		October 2014.
	[RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart		[RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart
	Object Security Workshop", RFC 7397, December 2014.		Object Security Workshop", RFC 7397, December 2014.
	[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for		[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
	IPv6 over Low-Power Wireless Personal Area Networks		IPv6 over Low-Power Wireless Personal Area Networks
	(6LoWPANs)", RFC 7400, November 2014.		(6LoWPANs)", RFC 7400, November 2014.
			[SP800-22b]
			NIST, "Special Publication 800-22, Revision 1a, A
			Statistical Test Suite for Random and Pseudorandom Number
			Generators for Cryptographic Applications",
			http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/
			SP800-22rev1a.pdf, April 2010.
			[SP800-90A]
			NIST, "DRAFT Special Publication 800-90a, Revision 1,
			Recommendation for Random Number Generation Using
			Deterministic Random Bit Generators",
			http://csrc.nist.gov/publications/drafts/800-90/
			sp800-90a_r1_draft_november2014_ver.pdf, November 2014.
	[Tripple-HS]		[Tripple-HS]
	Bhargavan, K., Delignat-Lavaud, C., Pironti, A., and P.		Bhargavan, K., Delignat-Lavaud, C., Pironti, A., and P.
	Strub, "Triple Handshakes and Cookie Cutters: Breaking and		Strub, "Triple Handshakes and Cookie Cutters: Breaking and
	Fixing Authentication over TLS", IEEE Symposium on		Fixing Authentication over TLS", IEEE Symposium on
	Security and Privacy, pages 98-113, 2014.		Security and Privacy, pages 98-113, 2014.
	Appendix A. Conveying DTLS over SMS		Appendix A. Conveying DTLS over SMS
	This section is normative for the use of DTLS over SMS. Timer		This section is normative for the use of DTLS over SMS. Timer
	recommendations are already outlined in Section 13 and also		recommendations are already outlined in Section 13 and also
	skipping to change at page 43, line 39 ¶		skipping to change at page 49, line 15 ¶
	Handshake messages MUST carry a validity period (TP-VP parameter in a		Handshake messages MUST carry a validity period (TP-VP parameter in a
	SMS-SUBMIT TPDU) that is not less than the current value of the		SMS-SUBMIT TPDU) that is not less than the current value of the
	retransmission timeout. In order to avoid persisting messages in the		retransmission timeout. In order to avoid persisting messages in the
	network that will be discarded by the receiving party, handshake		network that will be discarded by the receiving party, handshake
	messages SHOULD carry a validity period that is the same as, or just		messages SHOULD carry a validity period that is the same as, or just
	slightly higher than, the current value of the retransmission		slightly higher than, the current value of the retransmission
	timeout.		timeout.
	Appendix B. DTLS Record Layer Per-Packet Overhead		Appendix B. DTLS Record Layer Per-Packet Overhead
	Figure 10 shows the overhead for the DTLS record layer for protecting		Figure 12 shows the overhead for the DTLS record layer for protecting
	data traffic when AES-128-CCM with an 8-octet Integrity Check Value		data traffic when AES-128-CCM with an 8-octet Integrity Check Value
	(ICV) is used.		(ICV) is used.
	DTLS Record Layer Header................13 bytes		DTLS Record Layer Header................13 bytes
	Nonce (Explicit).........................8 bytes		Nonce (Explicit).........................8 bytes
	ICV..................................... 8 bytes		ICV..................................... 8 bytes
	------------------------------------------------		------------------------------------------------
	Overhead................................29 bytes		Overhead................................29 bytes
	------------------------------------------------		------------------------------------------------
	Figure 10: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead.		Figure 12: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead.
	The DTLS record layer header has 13 octets and consists of		The DTLS record layer header has 13 octets and consists of
	o 1 octet content type field,		o 1 octet content type field,
	o 2 octet version field,		o 2 octet version field,
	o 2 octet epoch field,		o 2 octet epoch field,
	o 6 octet sequence number,		o 6 octet sequence number,
End of changes. 39 change blocks.
	91 lines changed or deleted		311 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/