< draft-ietf-dice-profile-07.txt   draft-ietf-dice-profile-08.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 18, 2015 Alcatel-Lucent Expires: June 24, 2015 Alcatel-Lucent
December 15, 2014 December 21, 2014
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-07.txt draft-ietf-dice-profile-08.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 18, 2015. This Internet-Draft will expire on June 24, 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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . 12 5. The TLS/DTLS Ciphersuite Concept . . . . . . . . . . . . . . 14
6. Credential Types . . . . . . . . . . . . . . . . . . . . . . 13 6. Credential Types . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 13 6.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 15
6.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 15 6.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 17
6.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 17 6.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 19
7. Signature Algorithm Extension . . . . . . . . . . . . . . . . 20 7. Signature Algorithm Extension . . . . . . . . . . . . . . . . 22
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 20 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 22
9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 21 9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 23
10. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 22 11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 24
12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 25
13. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 25 13. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 27
14. Random Number Generation . . . . . . . . . . . . . . . . . . 25 14. Random Number Generation . . . . . . . . . . . . . . . . . . 27
15. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 26 15. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 28
16. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 27 16. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 29
17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 27 17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 29
18. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 27 18. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 29
19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 28 19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 30
20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 28 20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 30
21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 29 21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 31
22. Key Length Recommendations . . . . . . . . . . . . . . . . . 30 22. Key Length Recommendations . . . . . . . . . . . . . . . . . 32
23. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 31 23. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 33
24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32 24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34
25. Security Considerations . . . . . . . . . . . . . . . . . . . 32 25. Security Considerations . . . . . . . . . . . . . . . . . . . 34
26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
28. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 28. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
28.1. Normative References . . . . . . . . . . . . . . . . . . 33 28.1. Normative References . . . . . . . . . . . . . . . . . . 35
28.2. Informative References . . . . . . . . . . . . . . . . . 34 28.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 38 Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 41
A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 38 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 41
A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 39 A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 42
A.3. Multiplexing Security Associations . . . . . . . . . . . 40 A.3. Multiplexing Security Associations . . . . . . . . . . . 42
A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 40 A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 43
Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 41 Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
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 4, line 43 skipping to change at page 4, line 46
o An explicit sequence number and an epoch field is included in the o An explicit sequence number and an epoch field is included in the
Record Protocol. Section 4.1 of RFC 6347 explains the processing Record Protocol. Section 4.1 of RFC 6347 explains the processing
rules for these two new fields. The value used to compute the MAC rules for these two new fields. The value used to compute the MAC
is the 64-bit value formed by concatenating the epoch and the is the 64-bit value formed by concatenating the epoch and the
sequence number. sequence number.
o Stream ciphers must not be used with DTLS. The only stream cipher o Stream ciphers must not be used with DTLS. The only stream cipher
defined for TLS 1.2 is RC4 and due to cryptographic weaknesses it defined for TLS 1.2 is RC4 and due to cryptographic weaknesses it
is not recommended anymore even for use with TLS is not recommended anymore even for use with TLS
[I-D.ietf-tls-prohibiting-rc4]. [I-D.ietf-tls-prohibiting-rc4]. Note that the term 'stream
cipher' is a technical term in the TLS specification. Section 4.7
of RFC 5246 defines stream ciphers in TLS as follows. In stream
cipher encryption, the plaintext is exclusive-ORed with an
dentical amount of output generated from a cryptographically
secure keyed pseudorandom number generator.
o The TLS Handshake Protocol has been enhanced to include a o The TLS Handshake Protocol has been enhanced to include a
stateless cookie exchange for Denial of Service (DoS) resistance. stateless cookie exchange for Denial of Service (DoS) resistance.
For this purpose a new handshake message, the HelloVerifyRequest, For this purpose a new handshake message, the HelloVerifyRequest,
was added to DTLS. This handshake message is sent by the server was added to DTLS. This handshake message is sent by the server
and includes a stateless cookie, which is returned in a and includes a stateless cookie, which is returned in a
ClientHello message back to the server. Although the exchange is ClientHello message back to the server. Although the exchange is
optional for the server to execute, a client implementation has to optional for the server to execute, a client implementation has to
be prepared to respond to it. Furthermore, the handshake message be prepared to respond to it. Furthermore, the handshake message
format has been extended to deal with message loss, reordering, format has been extended to deal with message loss, reordering,
skipping to change at page 10, line 8 skipping to change at page 10, line 8
network access authentication. An IoT device using a network access network access authentication. An IoT device using a network access
authentication solution based on TLS can re-use most parts of the authentication solution based on TLS can re-use most parts of the
code for the use of DTLS/TLS at the application layer thereby saving code for the use of DTLS/TLS at the application layer thereby saving
a significant amount of flash memory. Note, however, that the a significant amount of flash memory. Note, however, that the
credentials used for network access authentication and those used for credentials used for network access authentication and those used for
application layer security are very likely different. application layer security are very likely different.
4.1.1.2. CoAP-based Data Exchange Example 4.1.1.2. CoAP-based Data Exchange Example
When a constrained client uploads sensor data to a server When a constrained client uploads sensor data to a server
infrastructure it may use CoAP by pushing the data via a POST to a infrastructure it may use CoAP by pushing the data via a POST message
pre-configured endpoint on the server. In certain circumstances this to a pre-configured endpoint on the server. In certain circumstances
might be too limiting and additional functionality is needed, as this might be too limiting and additional functionality is needed, as
shown in Figure 4, where the IoT device itself runs a CoAP server shown in Figure 4, where the IoT device itself runs a CoAP server
hosting the resource that is made accessible to other entities. hosting the resource that is made accessible to other entities.
Despite running a CoaP server on the IoT device it is still the DTLS Despite running a CoaP server on the IoT device it is still the DTLS
client on the IoT device that initiates the interaction with the non- client on the IoT device that initiates the interaction with the non-
constrained resource server in our scenario. constrained resource server in our scenario.
Figure 4 shows a sensor starting with a DTLS exchange with a resource Figure 4 shows a sensor starting with a DTLS exchange with a resource
server to register available resources. The initial DTLS interaction directory to register available resources.
between the sensor, acting as a DTLS client, and the resource server, [I-D.ietf-core-resource-directory] defines the resource directory as
acting as a DTLS server, will be a full DTLS handshake. Once this a web entity that stores information about web resources and
handshake is complete both parties have established the DTLS record implements the REST interfaces defined in
layer, which can subsequently be used to secure the CoAP message [I-D.ietf-core-resource-directory] for registration and lookup of
exchange, which starts with a the resource registration. Details those resources.
about the resource registry capabilities can be found in
The initial DTLS interaction between the sensor, acting as a DTLS
client, and the resource directory, acting as a DTLS server, will be
a full DTLS handshake. Once this handshake is complete both parties
have established the DTLS record layer. Subsequently, the CoAP
client can securely register at the resource directory. Details
about the capabilities of the resource directory can be found in
[I-D.ietf-core-resource-directory]. [I-D.ietf-core-resource-directory].
After some time (assuming that the client regularly refreshes its After some time (assuming that the client regularly refreshes its
registration) the resource server receives a request (not shown) from registration) the resource directory receives a request (not shown in
an application to retrieve the temperature information from the the figure) from an application to retrieve the temperature
sensor. This request is relayed by the resource directory to the information from the sensor. This request is relayed by the resource
sensor using a GET message exchange. The already established DTLS directory to the sensor using a GET message exchange. The already
record layer can be used to secure the message exchange. established DTLS record layer can be used to secure the message
exchange.
Resource Resource
Sensor Directory Sensor Directory
------ --------- ------ ---------
+--- +---
| |
| ClientHello --------> | ClientHello -------->
| client_certificate_type | client_certificate_type
F| server_certificate_type F| server_certificate_type
skipping to change at page 11, line 46 skipping to change at page 12, line 4
\ Y \ Y
* \ E * \ E
* (time passes) \ R * (time passes) \ R
* \ * \
+--- \ P +--- \ P
C| \ R C| \ R
O| Req: GET coaps://sensor.example.com/temp \ O O| Req: GET coaps://sensor.example.com/temp \ O
A| <-------- \ T A| <-------- \ T
P| \ E P| \ E
| Res: 2.05 Content \ C | Res: 2.05 Content \ C
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
TEXT TO BE DONE Section 4.1 illustrates deployment models where the TLS/DTLS client
is constrained and efforts need to be taken to improve memory
utilization, bandwidth consumption, reduce performance impacts, etc.
In this section we look at cases where constrained devices run TLS/
DTLS servers to secure access to an application layer protocol
server, like a CoAP or HTTP server. Running server functionality on
a constrained node is typically more demanding since servers have to
listen and wait for incoming requests. Therefore, they will have
fewer possibilities to enter sleeping cycles. Nevertheless, there
are legitimate reasons to deploy servers as constrained devices.
A deployment with constrained servers has to overcome several
challenges. Later we will explain how these challenges has been
solved using CoAP as an example. Other protocols may offer similar
capabilities. While the requirements for the TLS/DTLS protocol
profile change only slightly when run on a constrained server (in
comparison to running it on a constrained client) several other eco-
system factor will impact deployment.
The challenges are:
Discovery and Reachability:
Before initiating a connection to a constrained server a client
first needs to discover that server and, once discovered, it needs
to maintain reachability with that device.
In CoAP the discovery of resources offered by servers is
accomplished by sending a unicast or multicast CoAP GET to a well-
known URI. The CORE Link format specification [RFC6690] describes
the use case (see Section 1.2.1), and reserves the URI (see
Section 7.1). Section 7 of the CoAP specification [RFC7252]
describes the discovery procedure. RFC 7390 [RFC7390] describes
use case for discovering CoAP servers using multicast (see
Section 3.3), and specifies the protocol processing rules for CoAP
group communications (see Section 2.7).
Authentication:
The next challenge concerns the provisioning of authentication
credentials to the clients as well as servers. In Section 4.1 we
assumed that credentials (and other configuration information) are
provisioned to the device and that those can be used with the
authorization servers. Of course, this leads to a very static
relationship between the clients and their server-side
infrastructure but poses fewer challenges from a deployment point
of view, as described in Section 2 of
[I-D.iab-smart-object-architecture] these different communication
patterns. In any case, engineers and product designers have to
determine how the relevant credentials are distributed to the
respective parties. For example, shared secrets may need to be
provisioned to clients and the constrained servers for subsequent
use of TLS/DTLS PSK. In other deployments, certificates, private
keys, and trust anchors for use with certificate-based
authentication may need to be utilized.
Practical solutions either use pairing (also called imprinting) or
a trusted third party. With pairing two devices execute a special
protocol exchange that is unauthenticated to establish an shared
key (for example using an unauthenticated Diffie-Hellman exchange)
key. To avoid man-in-the-middle attacks an out-of-band channel is
used to verify that nobody has tampered with the exchanged
protocol messages. This out-of-band channel can come in many
forms, including:
* Human involvement by comparing hashed keys, entering passkeys,
scanning QR codes
* The use of alternative wireless communication channels (e.g.,
infra-red communication in addition to WiFi)
* Proximity-based information
More details about these different pairing/imprinting techniques
can be found in the smart object security workshop report
[RFC7397] and various position papers submitted to that topic,
such as [ImprintingSurvey]. The use of a trusted third party
follows a different approach and is subject to ongoing
standardization efforts in the 'Authentication and Authorization
for Constrained Environments (ACE)' working group.
Authorization
The last challenge is the ability for the constrained server to
make an authorization decision when clients access protected
resources. Pre-provisioning access control information to
constrained servers may be one option but works only in a small
scale, less dynamic environment. For a more fine-grained and
dynamic access control the reader is referred to the ongoing work
in the ACE working group.
5. The TLS/DTLS Ciphersuite Concept 5. The TLS/DTLS Ciphersuite Concept
TLS (and consequently DTLS) has the concept of ciphersuites and an TLS (and consequently DTLS) has the concept of ciphersuites and an
IANA registry [IANA-TLS] was created to register the suites. A IANA registry [IANA-TLS] was created to register the suites. A
ciphersuite (and the specification that defines it) contains the ciphersuite (and the specification that defines it) contains the
following information: following information:
o Authentication and key exchange algorithm (e.g., PSK) o Authentication and key exchange algorithm (e.g., PSK)
skipping to change at page 15, line 20 skipping to change at page 17, line 20
contacting, which is relevant for hosting environments. A server contacting, which is relevant for hosting environments. A server
using the identity hint needs to guide the selection based on a using the identity hint needs to guide the selection based on a
received SNI value from the client. 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 environments assumption for TLS stacks used in the desktop and mobile environments
where management interfaces are used to provision identities and where management interfaces are used to provision identities and
keys. For the IoT environment, keys are distributed as part of keys. For the IoT environment, keys are distributed as part of
hardware modules or are embedded into the firmware and, as such, hardware modules or are embedded into the firmware. Implementations
these restrictions are not applicable to this profile. in compliance with this profile MAY use PSK identities up to 128
octets in length, and arbitrary PSKs up to 64 octets in length. The
use of shorter PSK identities and shorter PSKs is RECOMMENDED.
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 an HMAC with the SHA-256 hash function. (Note that (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 all IoT implementations will need a SHA-256 implementation due to the
construction of the pseudo-random number function in DTLS/TLS 1.2.) construction of the pseudo-random number function in DTLS/TLS 1.2.)
skipping to change at page 15, line 44 skipping to change at page 17, 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 6, 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
------ ------ ------ ------
ClientHello --------> ClientHello -------->
client_certificate_type *client_certificate_type*
server_certificate_type *server_certificate_type*
<------- HelloVerifyRequest
ClientHello -------->
client_certificate_type
server_certificate_type
ServerHello ServerHello
client_certificate_type *client_certificate_type*
server_certificate_type *server_certificate_type*
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
RFC 7250.
Figure 6: DTLS Raw Public Key Exchange including the Cookie Exchange. Figure 6: 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
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 provides perfect forward secrecy (PFS).
details about PFS can be found in Section 11. More details about PFS can be found in Section 11.
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 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.
skipping to change at page 17, line 30 skipping to change at page 19, line 28
[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 rely on a software update Instead IoT devices using this profile MUST use a software update
mechanism to provision these trust anchors. mechanism to populate the trust anchor store.
Client Server Client Server
------ ------ ------ ------
ClientHello --------> ClientHello -------->
cached_information *cached_information*
<------- HelloVerifyRequest
ClientHello -------->
cached_information
ServerHello ServerHello
cached_information *cached_information*
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
[I-D.ietf-tls-cached-info].
Figure 7: DTLS Mutual Certificate-based Authentication. Figure 7: DTLS Mutual Certificate-based Authentication.
When DTLS is used to secure CoAP messages then the server provided When DTLS is used to secure CoAP messages then the server provided
certificates MUST contain the fully qualified DNS domain name or certificates MUST contain the fully qualified DNS domain name or
"FQDN" as dNSName. The coaps URI scheme is described in Section 6.2 "FQDN" as dNSName. The coaps URI scheme is described in Section 6.2
of [RFC7252]. This FQDN is stored in the SubjectAltName or in the of [RFC7252]. This FQDN is stored in the SubjectAltName 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 the profile in this specification does not
skipping to change at page 19, line 32 skipping to change at page 21, line 31
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.
Recommendation: Add support for client certificate URLs for those TLS/DTLS clients MUST implement support for client certificate URLs
environments where client-side certificates are used. for those environments where client-side certificates are used.
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 and no such dynamic indication of trust
anchors is needed. anchors is needed.
Recommendation: For IoT deployments where clients talk to a fixed, For deployments where IoT devices interact with a fixed, pre-
pre-configured set of servers and where a software update mechanism configured set of servers and where a software update mechanism is
is available this extension is not recommended. Environments where available this extension is NOT RECOMMENDED. Environments where the
the client needs to interact with dynamically discovered TLS/DTLS client needs to interact with dynamically discovered TLS/DTLS servers
servers this extension may be useful to reduce the communication the use of this extension is RECOMMENDED.
overhead. Note, however, in that case the TLS cached info extension
may help to reduce the communication overhead for everything but the
first protocol interaction.
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 21, line 37 skipping to change at page 23, line 33
servers supporting this specification but implementations MUST be servers supporting this specification but implementations MUST be
prepared to process these errors to deal with servers that are not prepared to process these errors to deal with servers that are not
compliant to the profiles in this document: compliant to the profiles in this document:
protocol_version: While this document focuses only on one version of protocol_version: While this document focuses only on one version of
the TLS/DTLS protocol, namely version 1.2, ongoing work on TLS/ the TLS/DTLS protocol, namely version 1.2, ongoing work on TLS/
DTLS 1.3 is in progress at the time of writing. DTLS 1.3 is in progress at the time of writing.
insufficient_security: This error message indicates that the server insufficient_security: This error message indicates that the server
requires ciphers to be more secure. This document specifies only requires ciphers to be more secure. This document specifies only
only 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 TLS/DTLS that allows a client to Session resumption is a feature of the core TLS/DTLS specifications
continue with an earlier established session state. The resulting that allows a client to continue with an earlier established session
exchange is shown in Figure 8. In addition, the server may choose state. The resulting exchange is shown in Figure 8. In addition,
not to do a cookie exchange when a session is resumed. Still, the server may choose not to do a cookie exchange when a session is
clients have to be prepared to do a cookie exchange with every resumed. Still, clients have to be prepared to do a cookie exchange
handshake. with every handshake. The cookie exchange is not shown in the
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 8: DTLS Session Resumption.
Clients MUST implement session resumption to improve the performance Constrained clients MUST implement session resumption to improve the
of the handshake (in terms of reduced number of message exchanges, performance of the handshake. This will lead to a reduced number of
lower computational overhead, and less bandwidth conserved). message exchanges, lower computational overhead (since only symmetric
cryptography is used during a session resumption exchange), and
session resumption requires less bandwidth.
Since the communication model described in Section 4 does not assume For cases where the server is constrained (but not the client) the
that the server is constrained, RFC 5077 [RFC5077] specifying TLS/ client MUST implement RFC 5077 [RFC5077]. RFC 5077 specifies a
DTLS session resumption without server-side state is not utilized by version of TLS/DTLS session resumption that does not require per-
this profile. session state information to be maintained by the constrained server.
This is accomplished by using a ticket-based approach.
If both the client and the server are constrained devices both
devices SHOULD implement RFC 5077 and MUST implement basic session
resumption.
10. Compression 10. Compression
Section 3.3 of [I-D.ietf-uta-tls-bcp] recommends to disable TLS/DTLS- Section 3.3 of [I-D.ietf-uta-tls-bcp] recommends to disable TLS/DTLS-
level compression due to attacks, such as CRIME. For IoT level compression due to attacks, such as CRIME. For IoT
applications compression at the TLS/DTLS layer is not needed since applications compression at the TLS/DTLS layer is not needed since
application layer protocols are highly optimized and the compression application layer protocols are highly optimized and the compression
algorithms at the DTLS layer increases code size and complexity. algorithms at the DTLS layer increases code size and complexity.
Recommendation: This TLS/DTLS profile MUST NOT implement and use TLS/ This TLS/DTLS profile MUST NOT implement TLS/DTLS layer compression.
DTLS layer compression.
11. Perfect Forward Secrecy 11. Perfect Forward Secrecy
Perfect forward secrecy (PFS) is a property that preserves the Perfect forward secrecy (PFS) is a property that preserves the
confidentiality of past conversations even in situations where the confidentiality of past conversations even in situations where the
long-term secret is compromised. long-term secret is compromised.
The PSK ciphersuite recommended in Section 6.1 does not offer this The PSK ciphersuite recommended in Section 6.1 does not offer this
property since it does not utilize a Diffie-Hellman exchange. New property since it does not utilize a Diffie-Hellman exchange. New
ciphersuites that support PFS for PSK-based authentication, such as ciphersuites that support PFS for PSK-based authentication, such as
skipping to change at page 23, line 24 skipping to change at page 25, line 30
reasons some implementations re-use key pairs over multiple exchanges reasons some implementations re-use key pairs over multiple exchanges
(rather than generating new keys for each exchange) for the obvious (rather than generating new keys for each exchange) for the obvious
performance improvement. Note, however, that such key re-use over performance improvement. Note, however, that such key re-use over
long periods voids the benefits of forward secrecy when an attack long periods voids the benefits of forward secrecy when an attack
gains access to this DH key pair. gains access to this DH key pair.
The impact of the disclosure of past conversations and the desire to The impact of the disclosure of past conversations and the desire to
increase the cost for pervasive monitoring (as demanded by [RFC7258]) increase the cost for pervasive monitoring (as demanded by [RFC7258])
has to be taken into account when making a deployment decision. has to be taken into account when making a deployment decision.
Recommendation: Client implementations claiming support of this Client implementations claiming support of this profile MUST
profile MUST implement the ciphersuites listed in Section 6 according implement the ciphersuites listed in Section 6 according to the
to the selected credential type. selected credential type.
12. Keep-Alive 12. Keep-Alive
RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the
other peer is still alive. The same mechanism can also be used to other peer is still alive. The same mechanism can also be used to
perform Path Maximum Transmission Unit (MTU) Discovery. perform Path Maximum Transmission Unit (MTU) Discovery.
A recommendation about the use of RFC 6520 depends on the type of A recommendation about the use of RFC 6520 depends on the type of
message exchange an IoT device performs. There are three types of message exchange an IoT device performs. There are three types of
exchanges that need to be analysed: exchanges that need to be analysed:
skipping to change at page 24, line 46 skipping to change at page 27, line 5
part of [RFC6520], is less likely to be relevant since for many part of [RFC6520], is less likely to be relevant since for many
IoT deployments the most constrained link is the wireless IoT deployments the most constrained link is the wireless
interface between the IoT device and the network itself (rather interface between the IoT device and the network itself (rather
than some links along the end-to-end path). Only in more complex than some links along the end-to-end path). Only in more complex
network topologies, such as multi-hop mesh networks, path MTU network topologies, such as multi-hop mesh networks, path MTU
discovery might be appropriate. It also has to be noted that DTLS discovery might be appropriate. It also has to be noted that DTLS
itself already provides a basic path discovery mechanism (see itself already provides a basic path discovery mechanism (see
Section 4.1.1.1 of RFC 6347 by using the fragmentation capability Section 4.1.1.1 of RFC 6347 by using the fragmentation capability
of the handshake protocol). of the handshake protocol).
For server-initiated messages the heartbeat extension can be For server-initiated messages the heartbeat extension is RECOMMENDED.
RECOMMENDED.
13. Timeouts 13. Timeouts
To connect to the Internet a variety of wired and wireless To connect to the Internet a variety of wired and wireless
technologies are available. Many of the low power radio technologies are available. Many of the low power radio
technologies, such as IEEE 802.15.4 or Bluetooth Smart, only support technologies, such as IEEE 802.15.4 or Bluetooth Smart, only support
small frame sizes (e.g., 127 bytes in case of IEEE 802.15.4 as small frame sizes (e.g., 127 bytes in case of IEEE 802.15.4 as
explained in RFC 4919 [RFC4919]). Other radio technologies, such as explained in RFC 4919 [RFC4919]). Other radio technologies, such as
the Global System for Mobile Communications (GSM) using the short the Global System for Mobile Communications (GSM) using the short
messaging service (SMS) have similar constraints in terms of payload messaging service (SMS) have similar constraints in terms of payload
skipping to change at page 25, line 39 skipping to change at page 27, line 41
initial timer value of 1 second and twice the value at each initial timer value of 1 second and twice the value at each
retransmission up to no less than 60 seconds. Due to the nature of retransmission up to no less than 60 seconds. Due to the nature of
some radio technologies, these values are too aggressive and lead to some radio technologies, these values are too aggressive and lead to
spurious failures when messages in flight need longer. spurious failures when messages in flight need longer.
Note: If a round-trip time estimator (such as proposed in Note: If a round-trip time estimator (such as proposed in
[I-D.bormann-core-cocoa]) is available in the protocol stack of the [I-D.bormann-core-cocoa]) is available in the protocol stack of the
device, it could be used to dynamically update the setting of the device, it could be used to dynamically update the setting of the
retransmit timeout. retransmit timeout.
Recommendation: Choosing appropriate timeout values is difficult with Choosing appropriate timeout values is difficult with infrequent data
infrequent data transmissions, changing network conditions, and large transmissions, changing network conditions, and large variance in
variance in latency. This specification therefore RECOMMENDS an latency. This specification therefore RECOMMENDS an initial timer
initial timer value of 10 seconds with exponential back off up to no value of 10 seconds with exponential back off up to no less then 60
less then 60 seconds. Appendix A provides additional normative text seconds. Appendix A provides additional normative text for carrying
for carrying DTLS over SMS. DTLS over SMS.
14. Random Number Generation 14. Random Number Generation
The TLS/DTLS protocol requires random numbers to be available during The TLS/DTLS protocol requires random numbers to be available during
the protocol run. For example, during the ClientHello and the the protocol run. For example, during the ClientHello and the
ServerHello exchange the client and the server exchange random ServerHello exchange the client and the server exchange random
numbers. Also, the use of the Diffie-Hellman exchange requires numbers. Also, the use of the Diffie-Hellman exchange requires
random numbers during the key pair generation. Special care has to random numbers during the key pair generation. Special care has to
be paid when generating random numbers in embedded systems as many be paid when generating random numbers in embedded systems as many
entropy sources available on desktop operating systems or mobile entropy sources available on desktop operating systems or mobile
skipping to change at page 26, line 19 skipping to change at page 28, line 21
example leading to the same keys generated again and again. example leading to the same keys generated again and again.
It is important to note that sources contributing to the randomness It is important to note that sources contributing to the randomness
pool on laptops, or desktop PCs are not available on many IoT device, pool on laptops, or desktop PCs are not available on many IoT device,
such as mouse movement, timing of keystrokes, air turbulence on the such as mouse movement, timing of keystrokes, air turbulence on the
movement of hard drive heads, etc. Other sources have to be found or movement of hard drive heads, etc. Other sources have to be found or
dedicated hardware has to be added. dedicated hardware has to be added.
The ClientHello and the ServerHello messages contains the 'Random' The ClientHello and the ServerHello messages contains the 'Random'
structure, which has two components: gmt_unix_time and a random structure, which has two components: gmt_unix_time and a random
sequence of 28 random bytes. gmt_unix_time holds the current time sequence of 28 random bytes. gmt_unix_time holds the current time and
and date in standard UNIX 32-bit format (seconds since the midnight date in standard UNIX 32-bit format (seconds since the midnight
starting Jan 1, 1970, GMT). [I-D.mathewson-no-gmtunixtime] argues starting Jan 1, 1970, GMT). [I-D.mathewson-no-gmtunixtime] argues
that the entire ClientHello.Random value (including gmt_unix_time) that the entire ClientHello.Random value (including gmt_unix_time)
should be set to a cryptographically random sequence because of should be set to a cryptographically random sequence because of
privacy concerns regarding device fingerprinting. Since many IoT privacy concerns regarding device fingerprinting. Since many IoT
devices do not have access to a real-time clock this recommendation devices do not have access to a real-time clock this recommendation
it is RECOMMENDED to follow the guidance outlined in it is RECOMMENDED to follow the guidance outlined in
[I-D.mathewson-no-gmtunixtime] regarding the content of the [I-D.mathewson-no-gmtunixtime] regarding the content of the
ClientHello.Random field. However, for the ServerHello.Random ClientHello.Random field. However, for the ServerHello.Random
structure it is RECOMMENDED to maintain the existing structure with structure it is RECOMMENDED to maintain the existing structure with
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. time information. For constrained servers it cannot be assumed that
they maintain accurate time information; these devices MUST include
time information in the Server.Random structure when they actually
obtain accurate time information that can be utilized by clients.
Clients MUST only use time information obtained from servers they
trust.
Recommendation: IoT devices using TLS/DTLS MUST offer ways to IoT devices using TLS/DTLS MUST offer ways to generate quality random
generate quality random numbers. Guidelines and requirements for numbers. Guidelines and requirements for random number generation
random number generation can be found in RFC 4086 [RFC4086]. can be found in RFC 4086 [RFC4086].
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
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,
and are therefore not appliable to the truncated MAC extension. and are therefore not appliable to the truncated MAC extension.
RFC 7366 [RFC7366] introduced the encrypt-then-MAC extension (instead RFC 7366 [RFC7366] introduced the encrypt-then-MAC extension (instead
of the previously used MAC-then-encrypt) since the MAC-then-encrypt of the previously used MAC-then-encrypt) since the MAC-then-encrypt
mechanism has been the subject of a number of security mechanism has been the subject of a number of security
vulnerabilities. RFC 7366 is, however, also not applicable to the vulnerabilities. RFC 7366 is, however, also not applicable to the
AEAD ciphers recommended in this document. AEAD ciphers recommended in this document.
Recommendation: Since this profile only supports AEAD ciphersuites Implementations conformant to this specification MUST use AEAD
these two extensions are not applicable. ciphers and RFC 7366 and RFC 6066 MUST NOT be implemented.
16. Server Name Indication (SNI) 16. Server Name Indication (SNI)
This RFC 6066 extension defines a mechanism for a client to tell a The Server Name Indication extension defined in [RFC6066] defines a
TLS/DTLS server the name of the server it wants to contact. This is mechanism for a client to tell a TLS/DTLS server the name of the
a useful extension for many hosting environments where multiple server it wants to contact. This is a useful extension for many
virtual servers are run on single IP address. hosting environments where multiple virtual servers are run on single
IP address.
Recommendation: Unless it is known that a TLS/DTLS client does not This specification RECOMMENDs the implementation of RFC 6066 unless
interact with a server in a hosting environment we RECOMMEND clients it is known that a TLS/DTLS client does not interact with a server in
to implement the SNI extension. a hosting environment.
17. Maximum Fragment Length Negotiation 17. Maximum Fragment Length Negotiation
This RFC 6066 extension lowers the maximum fragment length support This RFC 6066 extension lowers the maximum fragment length support
needed for the Record Layer from 2^14 bytes to 2^9 bytes. needed for the Record Layer from 2^14 bytes to 2^9 bytes.
This is a very useful extension that allows the client to indicate to This is a very useful extension that allows the client to indicate to
the server how much maximum memory buffers it uses for incoming the server how much maximum memory buffers it uses for incoming
messages. Ultimately, the main benefit of this extension is it to messages. Ultimately, the main benefit of this extension is it to
allows client implementations to lower their RAM requirements since allows client implementations to lower their RAM requirements since
the client does not need to accept packets of large size (such as 16k the client does not need to accept packets of large size (such as 16k
packets as required by plain TLS/DTLS). packets as required by plain TLS/DTLS).
Recommendation: Client implementations MUST support this extension. Client implementations MUST support this extension.
18. Session Hash 18. Session Hash
In order to begin connection protection, the Record Protocol requires In order to begin connection protection, the Record Protocol requires
specification of a suite of algorithms, a master secret, and the specification of a suite of algorithms, a master secret, and the
client and server random values. The algorithm for computing the client and server random values. The algorithm for computing the
master secret is defined in Section 8.1 of RFC 5246 but only includes master secret is defined in Section 8.1 of RFC 5246 but only includes
a small number of parameters exchanged during the handshake and does a small number of parameters exchanged during the handshake and does
not include parameters like the client and server identities. This not include parameters like the client and server identities. This
can be utilized by an attacker to mount a man-in-the-middle attack can be utilized by an attacker to mount a man-in-the-middle attack
since the master secret is not guaranteed to be unique across since the master secret is not guaranteed to be unique across
sessions, as discovered in the 'Triple Handshake' attack sessions, as discovered in the 'Triple Handshake' attack
[Tripple-HS]. [Tripple-HS].
[I-D.ietf-tls-session-hash] defines a TLS extension that binds the [I-D.ietf-tls-session-hash] defines a TLS extension that binds the
master secret to a log of the full handshake that computes it, thus master secret to a log of the full handshake that computes it, thus
preventing such attacks. preventing such attacks.
Recommendation: Client implementations SHOULD implement this Client implementations SHOULD implement this extension even though
extension even though the ciphersuites recommended by this profile the ciphersuites recommended by this profile are not vulnerable to
are not vulnerable to this attack. For Diffie-Hellman-based this attack. For Diffie-Hellman-based ciphersuites the keying
ciphersuites the keying material is contributed by both parties and material is contributed by both parties and in case of the pre-shared
in case of the pre-shared secret key ciphersuite both parties need to secret key ciphersuite both parties need to be in possession of the
be in possession of the shared secret to ensure that the handshake shared secret to ensure that the handshake completes successfully.
completes successfully. It is, however, possible that some It is, however, possible that some application layer protocols will
application layer protocols will tunnel other authentication tunnel other authentication protocols on top of DTLS making this
protocols on top of DTLS making this attack relevant again. attack relevant again.
19. Re-Negotiation Attacks 19. Re-Negotiation Attacks
TLS/DTLS allows a client and a server who already have a TLS/DTLS TLS/DTLS allows a client and a server who already have a TLS/DTLS
connection to negotiate new parameters, generate new keys, etc by connection to negotiate new parameters, generate new keys, etc by
using the re-negotiation feature. Renegotiation happens in the using the re-negotiation feature. Renegotiation happens in the
existing connection, with the new handshake packets being encrypted existing connection, with the new handshake packets being encrypted
along with application data. Upon completion of the re-negotiation along with application data. Upon completion of the re-negotiation
procedure the new channel replaces the old channel. procedure the new channel replaces the old channel.
As described in RFC 5746 [RFC5746] there is no cryptographic binding As described in RFC 5746 [RFC5746] there is no cryptographic binding
between the two handshakes, although the new handshake is carried out between the two handshakes, although the new handshake is carried out
using the cryptographic parameters established by the original using the cryptographic parameters established by the original
handshake. handshake.
Recommendation: To prevent the re-negotiation attack [RFC5746] this To prevent the re-negotiation attack [RFC5746] this specification
specification RECOMMENDS to disable the TLS renegotigation feature. RECOMMENDS to disable the TLS renegotigation feature. Clients MUST
Clients MUST respond to server-initiated re-negotiation attempts with respond to server-initiated re-negotiation attempts with an alert
an alert message (no_renegotiation) and clients MUST NOT initiate message (no_renegotiation) and clients MUST NOT initiate them.
them.
20. Downgrading Attacks 20. Downgrading Attacks
When a client sends a ClientHello with a version higher than the When a client sends a ClientHello with a version higher than the
highest version known to the server, the server is supposed to reply highest version known to the server, the server is supposed to reply
with ServerHello.version equal to the highest version known to the with ServerHello.version equal to the highest version known to the
server and the handshake can proceed. This behaviour is known as server and the handshake can proceed. This behaviour is known as
version tolerance. Version-intolerance is when the server (or a version tolerance. Version-intolerance is when the server (or a
middlebox) breaks the handshake when it sees a ClientHello.version middlebox) breaks the handshake when it sees a ClientHello.version
higher than what it knows about. This is the behaviour that leads higher than what it knows about. This is the behaviour that leads
skipping to change at page 35, line 34 skipping to change at page 37, line 34
[I-D.bmoeller-tls-falsestart] [I-D.bmoeller-tls-falsestart]
Langley, A., Modadugu, N., and B. Moeller, "Transport Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", draft-bmoeller-tls- Layer Security (TLS) False Start", draft-bmoeller-tls-
falsestart-01 (work in progress), November 2014. falsestart-01 (work in progress), November 2014.
[I-D.bormann-core-cocoa] [I-D.bormann-core-cocoa]
Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,
"CoAP Simple Congestion Control/Advanced", draft-bormann- "CoAP Simple Congestion Control/Advanced", draft-bormann-
core-cocoa-02 (work in progress), July 2014. core-cocoa-02 (work in progress), July 2014.
[I-D.iab-smart-object-architecture]
Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
"Architectural Considerations in Smart Object Networking",
draft-iab-smart-object-architecture-06 (work in progress),
October 2014.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z. and C. Bormann, "CoRE Resource Directory", Shelby, Z. and C. Bormann, "CoRE Resource Directory",
draft-ietf-core-resource-directory-02 (work in progress), draft-ietf-core-resource-directory-02 (work in progress),
November 2014. November 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-downgrade-scsv] [I-D.ietf-tls-downgrade-scsv]
Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade Suite Value (SCSV) for Preventing Protocol Downgrade
Attacks", draft-ietf-tls-downgrade-scsv-02 (work in Attacks", draft-ietf-tls-downgrade-scsv-03 (work in
progress), November 2014. progress), December 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-tls-prohibiting-rc4] [I-D.ietf-tls-prohibiting-rc4]
Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf-
tls-prohibiting-rc4-01 (work in progress), October 2014. tls-prohibiting-rc4-01 (work in progress), October 2014.
skipping to change at page 36, line 46 skipping to change at page 39, line 5
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/
tls-parameters.xhtml#tls-parameters-4, 2014. tls-parameters.xhtml#tls-parameters-4, 2014.
[ImprintingSurvey]
Chilton, E., "A Brief Survey of Imprinting Options for
Constrained Devices", URL: http://www.lix.polytechnique.fr
/hipercom/SmartObjectSecurity/papers/EricRescorla.pdf,
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.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
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.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003. CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
skipping to change at page 38, line 8 skipping to change at page 40, line 27
[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
Format", RFC 6690, August 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 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014. 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 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", RFC 7366, September 2014. (DTLS)", RFC 7366, September 2014.
[RFC7390] Rahman, A. and E. Dijk, "Group Communication for the
Constrained Application Protocol (CoAP)", RFC 7390,
October 2014.
[RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart
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.
[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.
skipping to change at page 42, line 12 skipping to change at page 44, line 39
the sequence number in the record layer header field. This leads to the sequence number in the record layer header field. This leads to
a duplication of 8-bytes per record. a duplication of 8-bytes per record.
To avoid this 8-byte duplication RFC 7400 [RFC7400] provides help To avoid this 8-byte duplication RFC 7400 [RFC7400] provides help
with the use of the generic header compression technique for IPv6 with the use of the generic header compression technique for IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs). Note that over Low-Power Wireless Personal Area Networks (6LoWPANs). Note that
this header compression technique is not available when DTLS is this header compression technique is not available when DTLS is
exchanged over transports that do not use IPv6 or 6LoWPAN, such as exchanged over transports that do not use IPv6 or 6LoWPAN, such as
the SMS transport described in Appendix A. the SMS transport described in Appendix A.
Appendix C. DTLS Fragmentation
[Editor's Note: Proposed text that requires discussion. ]
Section 4.2.3 of [RFC6347] advises DTLS implementations to not
produce overlapping fragments, but requires receivers to be able to
cope with them. The need for the latter requisite is explained in
Section 4.1.1.1 of [RFC6347]: accurate path MTU (PMTU) estimation may
be traded for shorter handshake completion time. This approach may
be beneficial in unconstrained networks where a PMTU of 1280 bytes
can be pretty much universally assumed. However, when the handshake
is carried over a narrow-band radio technology, such as IEEE 802.15.4
or GSM-SMS, and the client is lacking reliable PMTU data to inform
fragmentation (e.g., using [RFC1981] or [RFC1191]) can put a cost on
the constrained implementation in terms of memory (due to re-
buffering) and latency (due to re-transmission) much higher than the
benefit that it would get from a shorter handshake.
In order to reduce the likelihood of producing different fragment
sizes (and consequent overlaps) within the same handshake, this
document RECOMMENDs:
o for clients (handshake initiators), to perform PMTU discovery
towards the server before handshake starts, and not rely on any
guesses (unless the network path characteristics are reliably
known from another source);
o for servers, to mirror the fragment size selected by their
clients.
Authors' Addresses Authors' Addresses
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. 48 change blocks. 
149 lines changed or deleted 316 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/