< draft-ietf-dice-profile-04.txt		draft-ietf-dice-profile-05.txt >
	dice H. Tschofenig, Ed.		dice H. Tschofenig, Ed.
	Internet-Draft ARM Ltd.		Internet-Draft ARM Ltd.
	Intended status: Standards Track August 31, 2014		Intended status: Standards Track October 26, 2014
	Expires: March 4, 2015		Expires: April 29, 2015
	A Datagram Transport Layer Security (DTLS) 1.2 Profile for the Internet		A Datagram Transport Layer Security (DTLS) 1.2 Profile for the Internet
	of Things		of Things
	draft-ietf-dice-profile-04.txt		draft-ietf-dice-profile-05.txt
	Abstract		Abstract
	This document defines a DTLS 1.2 profile that is suitable for		This document defines a DTLS 1.2 profile that is suitable for
	Internet of Things applications and is reasonably implementable on		Internet of Things applications and is reasonably implementable on
	many constrained devices.		many constrained devices.
	A common design pattern in IoT deployments is the use of a		A common design pattern in IoT deployments is the use of a
	constrained device (typically providing sensor data) that interacts		constrained device (typically providing sensor data) that interacts
	with the web infrastructure. This document focuses on this		with the web infrastructure. This document focuses on this
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 March 4, 2015.		This Internet-Draft will expire on April 29, 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 17 ¶		skipping to change at page 2, line 17 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. The Communication Model . . . . . . . . . . . . . . . . . . . 5		3. The Communication Model . . . . . . . . . . . . . . . . . . . 5
	4. The Ciphersuite Concept . . . . . . . . . . . . . . . . . . . 6		4. The Ciphersuite Concept . . . . . . . . . . . . . . . . . . . 6
	5. Credential Types . . . . . . . . . . . . . . . . . . . . . . 8		5. Credential Types . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 8		5.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 8
	5.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 9		5.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 10
	5.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 11		5.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 12
	6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 13		6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 14
	7. Session Resumption . . . . . . . . . . . . . . . . . . . . . 14		7. Session Resumption . . . . . . . . . . . . . . . . . . . . . 15
	8. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 15		9. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 16
	10. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 15		10. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 16
	11. Random Number Generation . . . . . . . . . . . . . . . . . . 16		11. Random Number Generation . . . . . . . . . . . . . . . . . . 17
	12. Client Certificate URLs . . . . . . . . . . . . . . . . . . . 17		12. Client Certificate URLs . . . . . . . . . . . . . . . . . . . 18
	13. Trusted CA Indication . . . . . . . . . . . . . . . . . . . . 17		13. Trusted CA Indication . . . . . . . . . . . . . . . . . . . . 18
	14. Truncated MAC Extension . . . . . . . . . . . . . . . . . . . 18		14. Truncated MAC Extension . . . . . . . . . . . . . . . . . . . 19
	15. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 18		15. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 19
	16. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 19		16. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 20
	17. TLS Session Hash . . . . . . . . . . . . . . . . . . . . . . 19		17. TLS Session Hash . . . . . . . . . . . . . . . . . . . . . . 20
	18. Negotiation and Downgrading Attacks . . . . . . . . . . . . . 19		18. Negotiation and Downgrading Attacks . . . . . . . . . . . . . 20
	19. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20		19. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
	20. Security Considerations . . . . . . . . . . . . . . . . . . . 20		20. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21		22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
	23. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		23. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	23.1. Normative References . . . . . . . . . . . . . . . . . . 21		23.1. Normative References . . . . . . . . . . . . . . . . . . 22
	23.2. Informative References . . . . . . . . . . . . . . . . . 22		23.2. Informative References . . . . . . . . . . . . . . . . . 23
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	This document defines a DTLS 1.2 [RFC6347] profile that offers		This document defines a DTLS 1.2 [RFC6347] profile that offers
	communication security for Internet of Things (IoT) applications and		communication security for Internet of Things (IoT) applications and
	is reasonably implementable on many constrained devices. The DTLS		is reasonably implementable on many constrained devices. The DTLS
	1.2 protocol is based on Transport Layer Security (TLS) 1.2 [RFC5246]		1.2 protocol is based on Transport Layer Security (TLS) 1.2 [RFC5246]
	and provides equivalent security guarantees. This document aims to		and provides equivalent security guarantees. This document aims to
	meet the following goals:		meet the following goals:
	o Serves as a one-stop shop for implementers to know which pieces of		o Serves as a one-stop shop for implementers to know which pieces of
	the specification jungle contain relevant details.		the specification jungle contain relevant details.
	o Does not alter the DTLS 1.2 specification.		o Does not alter the TLS/DTLS specifications.
	o Does not introduce any new extensions.		o Does not introduce any new extensions.
	o Aligns with the DTLS security modes of the Constrained Application		o Aligns with the DTLS security modes of the Constrained Application
	Protocol (CoAP) [RFC7252].		Protocol (CoAP) [RFC7252].
	DTLS is used to secure a number of applications run over an		DTLS is used to secure a number of applications run over an
	unreliable datagram transport. CoAP [RFC7252] is one such protocol		unreliable datagram transport. CoAP [RFC7252] is one such protocol
	and has been designed specifically for use in IoT environments. CoAP		and has been designed specifically for use in IoT environments. CoAP
	can be secured a number of different ways, also called security		can be secured a number of different ways, also called security
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 8 ¶
	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].
	Note that "Client" and "Server" in this document refer to TLS roles,		Note that "Client" and "Server" in this document refer to TLS roles,
	where the Client initiates the TLS handshake. This does not restrict		where the Client initiates the TLS handshake. This does not restrict
	the interaction pattern of the protocols carried inside TLS as the		the interaction pattern of the protocols carried inside TLS as the
	record layer allows bi-directional communication. In the case of		record layer allows bi-directional communication. In the case of
	CoAP the "Client" can act as a CoAP Server or Client.		CoAP the "Client" can act as a CoAP Server or Client.
			RFC 7228 [RFC7228] introduces the notion of constrained-node
			networks, which are small devices with severe constraints on power,
			memory, and processing resources. The terms constrained devices, and
			Internet of Things (IoT) devices are used interchangeably.
	3. The Communication Model		3. The Communication Model
	This document describes a profile of DTLS 1.2 and, to be useful, it		This document describes a profile of DTLS 1.2 and, to be useful, it
	has to make assumptions about the envisioned communication		has to make assumptions about the envisioned communication
	architecture.		architecture.
	The communication architecture shown in Figure 1 assumes a uni-cast		The communication architecture shown in Figure 1 assumes a unicast
	communication interaction with an IoT device utilizing a DTLS client		communication interaction with an IoT device utilizing a DTLS client
	and that client interacts with one or multiple DTLS servers.		and that client interacts with one or multiple DTLS servers.
	Clients are preconfigured with the address or addresses of servers		Clients are provisioned with information about the servers they need
	(e.g., as part of the firmware) they will communicate with as well as		to initiate their DTLS exchange with and with credentials. This
	authentication information:		information may be conveyed to clients as part of a firmware/software
			package or via a configuration protocol. The following credential
			types are supported by this profile:
	o For PSK-based authentication (see Section 5.1), this includes the		o For PSK-based authentication (see Section 5.1), this includes the
	paired "PSK identity" and shared secret to be used with each		paired "PSK identity" and shared secret to be used with each
	server.		server.
	o For raw public key-based authentication (see Section 5.2), this		o For raw public key-based authentication (see Section 5.2), this
	includes either the server's public key or the hash of the		includes either the server's public key or the hash of the
	server's public key.		server's public key.
	o For certificate-based authentication (see Section 5.3), this may		o For certificate-based authentication (see Section 5.3), this
	include a pre-populated trust anchor store that allows the client		includes a pre-populated trust anchor store that allows the DTLS
	to perform path validation for the certificate obtained during the		stack to perform path validation for the certificate obtained
	handshake with the server.		during the handshake with the server.
	This document only focuses on the description of the DTLS client-side		This document focuses on the description of the DTLS client-side
	functionality.		functionality but, quite naturally, the equivalent server-side
			support has to be available.
	+////////////////////////////////////+		+////////////////////////////////////+
	| Configuration |		| Configuration |
	|////////////////////////////////////|		|////////////////////////////////////|
	| Server A --> PSK Identity, PSK |		| Server A --> PSK Identity, PSK |
	| Server B --> Public Key (Server B),|		| Server B --> Public Key (Server B),|
	| Public Key (Client) |		| Public Key (Client) |
	| Server C --> Public Key (Client), |		| Server C --> Public Key (Client), |
	| Trust Anchor Store |		| Trust Anchor Store |
	+------------------------------------+		+------------------------------------+
	skipping to change at page 8, line 20 ¶		skipping to change at page 8, line 20 ¶
	5.1. Pre-Shared Secret		5.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 DTLS since it is both computational efficient and		techniques for 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 2 illustrates the DTLS exchange including the cookie exchange.		Figure 2 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.		it when challenged. The cookie exchange allows the server to react
			to flooding attacks.
	Client Server		Client Server
	------ ------		------ ------
	ClientHello -------->		ClientHello -------->
	<-------- HelloVerifyRequest		<-------- HelloVerifyRequest
	(contains cookie)		(contains cookie)
	ClientHello -------->		ClientHello -------->
	(with cookie)		(with cookie)
	skipping to change at page 9, line 17 ¶		skipping to change at page 9, line 18 ¶
	however, not have a user interface and most of their credentials are		however, not have a user interface and most of their credentials are
	bound to the device rather than the user. Furthermore, credentials		bound to the device rather than the user. Furthermore, credentials
	are provisioned into trusted hardware modules or in the firmware by		are provisioned into trusted hardware modules or in the firmware by
	the developers. As such, the encoding considerations are not		the developers. As such, the encoding considerations are not
	applicable to this usage environment. For use with this profile the		applicable to this usage environment. For use with this profile the
	PSK identities SHOULD NOT assume a structured format (as domain		PSK identities SHOULD NOT assume a structured format (as domain
	names, Distinguished Names, or IP addresses have) and a bit-by-bit		names, Distinguished Names, or IP addresses have) and a bit-by-bit
	comparison operation can then be used by the server-side		comparison operation can then be used by the server-side
	infrastructure.		infrastructure.
	As described in Section 3 clients may have pre-shared keys with		The client indicates which key it uses by including a "PSK identity"
	several different servers. The client indicates which key it uses by		in the ClientKeyExchange message. As described in Section 3 clients
	including a "PSK identity" in the ClientKeyExchange message. To help		may have multiple pre-shared keys with a single server and to help
	the client in selecting which PSK identity / PSK pair to use, the		the client in selecting which PSK identity / PSK pair to use, the
	server can provide a "PSK identity hint" in the ServerKeyExchange		server can provide a "PSK identity hint" in the ServerKeyExchange
	message. For IoT environments a simplifying assumption is made that		message. If the hint for PSK key selection is based on the domain
	the hint for PSK key selection is based on the domain name of the		name of the server then servers SHOULD NOT send the "PSK identity
	server. Hence, servers SHOULD NOT send the "PSK identity hint" in		hint" in the ServerKeyExchange message. Hence, servers SHOULD NOT
	the ServerKeyExchange message and client MUST ignore the message.		send the "PSK identity hint" in the ServerKeyExchange message and
	This approach is inline with RFC 4279 [RFC4279].		client MUST ignore the message. This approach is inline with RFC
			4279 [RFC4279]. Note: The TLS Server Name Indication (SNI) extension
			allows the client to tell a server the name of the server it is
			contacting, which is relevant for hosting environments. A server
			using the identity hint needs to guide the selection based on a
			received SNI value from the client.
	RFC 4279 requires TLS implementations supporting PSK ciphersuites to		RFC 4279 requires TLS implementations supporting PSK ciphersuites to
	support arbitrary PSK identities up to 128 octets in length, and		support arbitrary PSK identities up to 128 octets in length, and
	arbitrary PSKs up to 64 octets in length. This is a useful		arbitrary PSKs up to 64 octets in length. This is a useful
	assumption for TLS stacks used in the desktop and mobile environment		assumption for TLS stacks used in the desktop and mobile environment
	where management interfaces are used to provision identities and		where management interfaces are used to provision identities and
	keys. For the IoT environment, however, many devices are not		keys. For the IoT environment, however, many devices are not
	equipped with displays and input devices (e.g., keyboards). Hence,		equipped with displays and input devices (e.g., keyboards). Hence,
	keys are distributed as part of hardware modules or are embedded into		keys are distributed as part of hardware modules or are embedded into
	the firmware. As such, these restrictions are not applicable to this		the firmware. As such, these restrictions are not applicable to this
	profile.		profile.
	Constrained Application Protocol (CoAP) [RFC7252] currently specifies		Constrained Application Protocol (CoAP) [RFC7252] currently specifies
	TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to implement ciphersuite		TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to implement ciphersuite
	for use with shared secrets. This ciphersuite uses the AES algorithm		for use with shared secrets. This ciphersuite uses the AES algorithm
	with 128 bit keys and CCM as the mode of operation. The label "_8"		with 128 bit keys and CCM as the mode of operation. The label "_8"
	indicates that an 8-octet authentication tag is used. This		indicates that an 8-octet authentication tag is used. This
	ciphersuite makes use of the default TLS 1.2 Pseudorandom Function		ciphersuite makes use of the default TLS 1.2 Pseudorandom Function
	(PRF), which uses HMAC with the SHA-256 hash function.		(PRF), which uses an HMAC with the SHA-256 hash function. (Note that
			all IoT implementations will need a SHA-256 implementation due to the
			construction of the pseudo-random number function in TLS 1.2.)
			A device compliant with this protocol MUST implement
			TLS_PSK_WITH_AES_128_CCM_8 and follow the guidance from this section.
	5.2. Raw Public Key		5.2. Raw Public Key
	The use of raw public keys with DTLS, as defined in [RFC7250], is the		The use of raw public keys with DTLS, as defined in [RFC7250], is the
	first entry point into public key cryptography without having to pay		first entry point into public key cryptography without having to pay
	the price of certificates and a PKI. The specification re-uses the		the price of certificates and a PKI. The specification re-uses the
	existing Certificate message to convey the raw public key encoded in		existing Certificate message to convey the raw public key encoded in
	the SubjectPublicKeyInfo structure. To indicate support two new TLS		the SubjectPublicKeyInfo structure. To indicate support two new TLS
	extensions had been defined, as shown in Figure 3, namely the		extensions had been defined, as shown in Figure 3, namely the
	server_certificate_type and the client_certificate_type. To operate		server_certificate_type and the client_certificate_type. To operate
	skipping to change at page 11, line 21 ¶		skipping to change at page 12, line 11 ¶
	1.2 and utilizes an eight-octet authentication tag. The use of a		1.2 and utilizes an eight-octet authentication tag. The use of a
	Diffie-Hellman key exchange adds perfect forward secrecy (PFS). More		Diffie-Hellman key exchange adds perfect forward secrecy (PFS). More
	details about PFS can be found in Section 9.		details about PFS can be found in Section 9.
	RFC 6090 [RFC6090] provides valuable information for implementing		RFC 6090 [RFC6090] provides valuable information for implementing
	Elliptic Curve Cryptography algorithms, particularly for choosing		Elliptic Curve Cryptography algorithms, particularly for choosing
	methods that have been published more than 20 years ago.		methods that have been published more than 20 years ago.
	Since many IoT devices will either have limited ways to log error or		Since many IoT devices will either have limited ways to log error or
	no ability at all, any error will lead to implementations attempting		no ability at all, any error will lead to implementations attempting
	to re-try the exchange.		to re-try the exchange. Implementers have to carefully evaluate the
			impact of errors and ways to remedy the situation since a commonly
			used approach for delegating decision making to users is difficult in
			a timely fashion (or impossible).
			A device compliant with this protocol MUST implement
			TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this
			section.
	5.3. Certificates		5.3. Certificates
	The use of mutual certificate-based authentication is shown in		The use of mutual certificate-based authentication is shown in
	Figure 4, which makes use of the cached info extension		Figure 4, 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
	skipping to change at page 12, line 48 ¶		skipping to change at page 13, line 44 ¶
	<-------- Finished		<-------- Finished
	Figure 4: DTLS Mutual Certificate-based Authentication.		Figure 4: DTLS Mutual Certificate-based Authentication.
	Regarding the ciphersuite choice the discussion in Section 5.2		Regarding the ciphersuite choice the discussion in Section 5.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 5.2 is also applicable to this		ciphersuite description in Section 5.2 is also applicable to this
	section.		section.
	It is RECOMMENDED to limit the depth of the certificate chain to a		IoT devices MUST provide support for a server certificate chain of at
	maximum of three (3).		least 3 not including the trust anchor and MAY reject connections
			from servers offering chains longer than 3. IoT devices MAY have
			client certificate chains of any length. Obviously, longer chains
			require more resources to process, transmit or receive.
			A device compliant with this protocol MUST implement
			TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this
			section.
	6. Error Handling		6. Error Handling
	DTLS uses the Alert protocol to convey error messages and specifies a		DTLS uses the Alert protocol to convey error messages and specifies a
	longer list of errors. However, not all error messages defined in		longer list of errors. However, not all error messages defined in
	the TLS specification are applicable to this profile. All error		the TLS specification are applicable to this profile. All error
	messages marked as RESERVED are only supported for backwards		messages marked as RESERVED are only supported for backwards
	compatibility with SSL and are therefore not applicable to this		compatibility with SSL and are therefore not applicable to this
	profile. Those include decryption_failed_RESERVED,		profile. Those include decryption_failed_RESERVED,
	no_certificate_RESERVE, and export_restriction_RESERVED.		no_certificate_RESERVE, and export_restriction_RESERVED.
	skipping to change at page 18, line 32 ¶		skipping to change at page 19, line 32 ¶
	The truncated MAC extension was introduced with RFC 6066 with the		The truncated MAC extension was introduced with RFC 6066 with the
	goal to reduces the size of the MAC used at the Record Layer. This		goal to reduces the size of the MAC used at the Record Layer. This
	extension was developed for TLS ciphersuites that used older modes of		extension was developed for TLS ciphersuites that used older modes of
	operation where the MAC and the encryption operation was performed		operation where the MAC and the encryption operation was performed
	independently.		independently.
	For CoAP, however, the recommended ciphersuites use the newer		For CoAP, however, the recommended ciphersuites use the newer
	Authenticated Encryption with Associated Data (AEAD) construct,		Authenticated Encryption with Associated Data (AEAD) construct,
	namely the CBC-MAC mode (CCM) with eight-octet authentication tags.		namely the CBC-MAC mode (CCM) with eight-octet authentication tags.
	Furthermore, the extension [I-D.ietf-tls-encrypt-then-mac]		Furthermore, the extension [RFC7366] introducing the encrypt-then-MAC
	introducing the encrypt-then-MAC security mechanism (instead of the		security mechanism (instead of the MAC-then-encrypt) is also not
	MAC-then-encrypt) is also not applicable for this profile.		applicable for this profile.
	Recommendation: Since this profile only supports AEAD ciphersuites		Recommendation: Since this profile only supports AEAD ciphersuites
	this extension is not applicable.		this extension is not applicable.
	15. Server Name Indication (SNI)		15. Server Name Indication (SNI)
	This RFC 6066 extension defines a mechanism for a client to tell a		This RFC 6066 extension defines a mechanism for a client to tell a
	TLS server the name of the server it wants to contact. This is a		TLS server the name of the server it wants to contact. This is a
	useful extension for many hosting environments where multiple virtual		useful extension for many hosting environments where multiple virtual
	servers are run on single IP address.		servers are run on single IP address.
	skipping to change at page 20, line 24 ¶		skipping to change at page 21, line 24 ¶
	observed by an on-path eavesdropper. For example, the DTLS PSK		observed by an on-path eavesdropper. For example, the DTLS PSK
	exchange reveals the PSK identity, the supported extensions, the		exchange reveals the PSK identity, the supported extensions, the
	session id, algorithm parameters, etc. When session resumption is		session id, algorithm parameters, etc. When session resumption is
	used then individual TLS sessions can be correlated by an on-path		used then individual TLS sessions can be correlated by an on-path
	adversary. With many IoT deployments it is likely that keying		adversary. With many IoT deployments it is likely that keying
	material and their identifiers are persistent over a longer period of		material and their identifiers are persistent over a longer period of
	time due to the cost of updating software on these devices.		time due to the cost of updating software on these devices.
	User participation with many IoT deployments poses a challenge since		User participation with many IoT deployments poses a challenge since
	many of the IoT devices operate unattended, even though they will		many of the IoT devices operate unattended, even though they will
	initially be enabled by a human. The ability to control data sharing		initially be provisioned by a human. The ability to control data
	and to configure preference will have to be provided at a system		sharing and to configure preference will have to be provided at a
	level rather than at the level of a DTLS profile, which is the scope		system level rather than at the level of the DTLS exchange itself,
	of this document. Quite naturally, the use of DTLS with mutual		which is the scope of this document. Quite naturally, the use of
	authentication will allow a TLS server to collect authentication		DTLS with mutual authentication will allow a TLS server to collect
	information about the IoT device (potentially over a long period of		authentication information about the IoT device (likely over a long
	time). While this strong form of authentication will prevent mis-		period of time). While this strong form of authentication will
	attribution it also allows strong identification. This device-		prevent mis-attribution it also allows strong identification.
	related data collection (e.g., sensor recordings) will be associated		Device-related data collection (e.g., sensor recordings) will be
	with other data to be truly useful and this extra data might include		associated with other data to be truly useful and this extra data
	personal data about the owner of the device or data about the		might include personal data about the owner of the device or data
	environment it senses. Consequently, the data stored on the server-		about the environment it senses. Consequently, the data stored on
	side will be vulnerable to stored data compromise. For the		the server-side will be vulnerable to stored data compromise. For
	communication between the client and the server this specification		the communication between the client and the server this
	prevents eavesdroppers to gain access to the communication content.		specification prevents eavesdroppers to gain access to the
	While the PSK-based ciphersuite does not provide PFS the asymmetric		communication content. While the PSK-based ciphersuite does not
	version does. No explicit techniques, such as extra padding, have		provide PFS the asymmetric versions do. This prevents an adversary
	been provided to make traffic analysis more difficult.		from obtaining past communication content when access to a long-term
			secret has been gained. Note that no extra effort to make traffic
			analysis more difficult is provided by the recommendations made in
			this document.
	20. Security Considerations		20. 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 also useful for changing
	configuration information, for example, trust anchors and other		configuration information, for example, trust anchors and other
	keying related information.		keying related information.
	21. IANA Considerations		21. IANA Considerations
	This document includes no request to IANA.		This document includes no request to IANA.
	22. Acknowledgements		22. Acknowledgements
	Thanks to Robert Cragie, Russ Housley, Rene Hummen, Sandeep Kumar,		Thanks to Robert Cragie, Russ Housley, Rene Hummen, Sandeep Kumar,
	Sye Loong Keoh, Eric Rescorla, Michael Richardson, Zach Shelby, and		Sye Loong Keoh, Eric Rescorla, Michael Richardson, Zach Shelby,
	Sean Turner for their helpful comments and discussions that have		Michael StJohns, and Sean Turner for their helpful comments and
	shaped the document.		discussions that have shaped the document.
	Big thanks also to Klaus Hartke, who wrote the initial version of		Big thanks also to Klaus Hartke, who wrote the initial version of
	this document.		this document.
	23. References		23. References
	23.1. Normative References		23.1. Normative References
	[EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)		[EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
	REGISTRATION AUTHORITY", April 2010,		REGISTRATION AUTHORITY", April 2010,
	skipping to change at page 21, line 39 ¶		skipping to change at page 22, line 41 ¶
	[I-D.ietf-tls-cached-info]		[I-D.ietf-tls-cached-info]
	Santesson, S. and H. Tschofenig, "Transport Layer Security		Santesson, S. and H. Tschofenig, "Transport Layer Security
	(TLS) Cached Information Extension", draft-ietf-tls-		(TLS) Cached Information Extension", draft-ietf-tls-
	cached-info-16 (work in progress), February 2014.		cached-info-16 (work in progress), February 2014.
	[I-D.ietf-tls-session-hash]		[I-D.ietf-tls-session-hash]
	Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley,		Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley,
	A., and M. Ray, "Transport Layer Security (TLS) Session		A., and M. Ray, "Transport Layer Security (TLS) Session
	Hash and Extended Master Secret Extension", draft-ietf-		Hash and Extended Master Secret Extension", draft-ietf-
	tls-session-hash-01 (work in progress), August 2014.		tls-session-hash-02 (work in progress), October 2014.
	[I-D.mathewson-no-gmtunixtime]
	Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in
	TLS", draft-mathewson-no-gmtunixtime-00 (work in
	progress), December 2013.
	[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.
	[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites		[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
	for Transport Layer Security (TLS)", RFC 4279, December		for Transport Layer Security (TLS)", RFC 4279, December
	2005.		2005.
	[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.
	skipping to change at page 23, line 11 ¶		skipping to change at page 24, line 11 ¶
	Suite Value (SCSV) for Preventing Protocol Downgrade		Suite Value (SCSV) for Preventing Protocol Downgrade
	Attacks", draft-bmoeller-tls-downgrade-scsv-02 (work in		Attacks", draft-bmoeller-tls-downgrade-scsv-02 (work in
	progress), May 2014.		progress), May 2014.
	[I-D.ietf-lwig-tls-minimal]		[I-D.ietf-lwig-tls-minimal]
	Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's		Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's
	Guide to the (Datagram) Transport Layer Security Protocol		Guide to the (Datagram) Transport Layer Security Protocol
	for Smart Objects and Constrained Node Networks", draft-		for Smart Objects and Constrained Node Networks", draft-
	ietf-lwig-tls-minimal-01 (work in progress), March 2014.		ietf-lwig-tls-minimal-01 (work in progress), March 2014.
	[I-D.ietf-tls-encrypt-then-mac]
	Gutmann, P., "Encrypt-then-MAC for TLS and DTLS", draft-
	ietf-tls-encrypt-then-mac-03 (work in progress), July
	2014.
	[I-D.ietf-tls-negotiated-dl-dhe]		[I-D.ietf-tls-negotiated-dl-dhe]
	Gillmor, D., "Negotiated Discrete Log Diffie-Hellman		Gillmor, D., "Negotiated Discrete Log Diffie-Hellman
	Ephemeral Parameters for TLS", draft-ietf-tls-negotiated-		Ephemeral Parameters for TLS", draft-ietf-tls-negotiated-
	dl-dhe-00 (work in progress), July 2014.		dl-dhe-00 (work in progress), July 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-02 (work in progress), August 2014.		ietf-uta-tls-bcp-06 (work in progress), October 2014.
			[I-D.mathewson-no-gmtunixtime]
			Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in
			TLS", draft-mathewson-no-gmtunixtime-00 (work in
			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
	progress), August 2014.		progress), August 2014.
	[IANA-TLS]		[IANA-TLS]
	IANA, "TLS Cipher Suite Registry",		IANA, "TLS Cipher Suite Registry",
	http://www.iana.org/assignments/tls-parameters/		http://www.iana.org/assignments/tls-parameters/
	skipping to change at page 24, line 18 ¶		skipping to change at page 25, line 18 ¶
	[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.
	[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)		[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
	Multiple Certificate Status Request Extension", RFC 6961,		Multiple Certificate Status Request Extension", RFC 6961,
	June 2013.		June 2013.
			[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
			Constrained-Node Networks", RFC 7228, May 2014.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252, June 2014.		Application Protocol (CoAP)", RFC 7252, June 2014.
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, May 2014.		Attack", BCP 188, RFC 7258, May 2014.
			[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer
			Security (TLS) and Datagram Transport Layer Security
			(DTLS)", RFC 7366, September 2014.
	Author's Address		Author's Address
	Hannes Tschofenig (editor)		Hannes Tschofenig (editor)
	ARM Ltd.		ARM Ltd.
	110 Fulbourn Rd		110 Fulbourn Rd
	Cambridge CB1 9NJ		Cambridge CB1 9NJ
	Great Britain		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. 24 change blocks.
	87 lines changed or deleted		125 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/