< draft-ietf-dice-profile-12.txt   draft-ietf-dice-profile-13.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: November 29, 2015 Alcatel-Lucent Expires: December 13, 2015 Alcatel-Lucent
May 28, 2015 June 11, 2015
A TLS/DTLS Profile for the Internet of Things A TLS/DTLS Profile for the Internet of Things
draft-ietf-dice-profile-12.txt draft-ietf-dice-profile-13.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 that collects data via sensor or the use of a constrained device that collects data via sensor or
controls actuators for use in home automation, industrial control controls actuators for use in 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 (DTLS) 1.2 profile that offers communications security for this TLS (DTLS) 1.2 profile that offers communications security for this
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 November 29, 2015. This Internet-Draft will expire on December 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 48 skipping to change at page 2, line 48
17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 37 17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 37
18. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 37 18. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 37
19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 38 19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 38
20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 38 20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 38
21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 39 21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 39
22. Key Length Recommendations . . . . . . . . . . . . . . . . . 40 22. Key Length Recommendations . . . . . . . . . . . . . . . . . 40
23. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 41 23. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 41
24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42
25. Security Considerations . . . . . . . . . . . . . . . . . . . 42 25. Security Considerations . . . . . . . . . . . . . . . . . . . 42
26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 27. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43
28. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 28. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
28.1. Normative References . . . . . . . . . . . . . . . . . . 43 28.1. Normative References . . . . . . . . . . . . . . . . . . 43
28.2. Informative References . . . . . . . . . . . . . . . . . 44 28.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 50 Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 50
A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 50 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 50
A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 51 A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 51
A.3. Multiplexing Security Associations . . . . . . . . . . . 52 A.3. Multiplexing Security Associations . . . . . . . . . . . 52
A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 53 A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 53
Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 53 Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 53
Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 54 Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
skipping to change at page 11, line 13 skipping to change at page 11, line 13
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 message infrastructure it may use CoAP by pushing the data via a POST message
to a pre-configured endpoint on the server. In certain circumstances to a pre-configured endpoint on the server. In certain circumstances
this 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 a DTLS exchange with a resource Figure 4 shows a sensor starting a DTLS exchange with a resource
directory to register available resources. directory to register available resources.
[I-D.ietf-core-resource-directory] defines the resource directory [I-D.ietf-core-resource-directory] defines the resource directory
(RD) as a web entity that stores information about web resources and (RD) as a web entity that stores information about web resources and
implements Representational State Transfer (REST) interfaces for implements Representational State Transfer (REST) interfaces for
registration and lookup of those resources. Note that the described registration and lookup of those resources. Note that the described
exchange is borrowed from the OMA Lightweight Machine-to-Machine exchange is borrowed from the OMA Lightweight Machine-to-Machine
skipping to change at page 13, line 24 skipping to change at page 13, line 24
Section 4.1 illustrates a deployment model where the TLS/DTLS client Section 4.1 illustrates a deployment model where the TLS/DTLS client
is constrained and efforts need to be taken to improve memory is constrained and efforts need to be taken to improve memory
utilization, bandwidth consumption, reduce performance impacts, etc. utilization, bandwidth consumption, reduce performance impacts, etc.
In this section, we assume a scenario where constrained devices run In this section, we assume a scenario where constrained devices run
TLS/ DTLS servers to secure access to application layer services TLS/ DTLS servers to secure access to application layer services
running on top of CoAP, HTTP or other protocols. Figure 5 running on top of CoAP, HTTP or other protocols. Figure 5
illustrates a possible deployment whereby a number of constrained illustrates a possible deployment whereby a number of constrained
servers are waiting for regular clients to access their resources. servers are waiting for regular clients to access their resources.
The entire process is likely, but not necessarily, controlled by a The entire process is likely, but not necessarily, controlled by a
third party, the authentication and authorisation server. This third party, the authentication and authorization server. This
authentication and authorization server is responsible for holding authentication and authorization server is responsible for holding
authorization policies that govern the access to resources and authorization policies that govern the access to resources and
distribution of keying material. distribution of keying material.
+////////////////////////////////////+ +////////////////////////////////////+
| Configuration | | Configuration |
|////////////////////////////////////| |////////////////////////////////////|
| Credentials | | Credentials |
| Client A -> Public Key | | Client A -> Public Key |
| Server S1 -> Symmetric Key | | Server S1 -> Symmetric Key |
skipping to change at page 17, line 41 skipping to change at page 17, line 41
22.5 C 22.5 C
Configure Actuator Configure Actuator
(authenticated/authorized) (authenticated/authorized)
-------------------------------------------------> ------------------------------------------------->
PUT /fan?on-off=true PUT /fan?on-off=true
CoAP 2.04 Changed CoAP 2.04 Changed
<------------------------------------------------- <-------------------------------------------------
Figure 6: Local Discovery and Resouce Access. Figure 6: Local Discovery and Resource Access.
5. The Ciphersuite Concept 5. The 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 23, line 24 skipping to change at page 23, line 24
6.3. Certificates 6.3. Certificates
The use of mutual certificate-based authentication is shown in The use of mutual certificate-based authentication is shown in
Figure 9, which makes use of the cached info extension Figure 9, which makes use of the cached info extension
[I-D.ietf-tls-cached-info]. Support of the cached info extension is [I-D.ietf-tls-cached-info]. Support of the cached info extension is
REQUIRED. Caching certificate chains allows the client to reduce the REQUIRED. Caching certificate chains allows the client to reduce the
communication overhead significantly since otherwise the server would communication overhead significantly since otherwise the server would
provide the end entity certificate, and the certificate chain with provide the end entity certificate, and the certificate chain with
every full DTLS handshake. Because certificate validation requires every full DTLS handshake. Because certificate validation requires
that root keys be distributed independently, the self-signed that root keys be distributed independently, the self-signed
certificate that specifies the root certificate authority is omitted certificate that specifies the root certification authority is
from the chain. Client implementations MUST be provisioned with a omitted from the chain. Client implementations MUST be provisioned
trust anchor store that contains the root certificates. The use of with a trust anchor store that contains these root certificates. The
the Trust Anchor Management Protocol (TAMP) [RFC5934] is, however, use of the Trust Anchor Management Protocol (TAMP) [RFC5934] is,
not envisioned. Instead IoT devices using this profile MUST use a however, not envisioned. Instead IoT devices using this profile MUST
software update mechanism to populate the trust anchor store. use a software update mechanism to populate the trust anchor store.
Client Server Client Server
------ ------ ------ ------
ClientHello --------> ClientHello -------->
*cached_info* *cached_info*
ServerHello ServerHello
*cached_info* *cached_info*
Certificate Certificate
skipping to change at page 26, line 16 skipping to change at page 26, line 16
described in Section 6.3.2 is applicable. Note that the Service Name described in Section 6.3.2 is applicable. Note that the Service Name
Indication (SNI) extension cannot be used in this case since SNI does Indication (SNI) extension cannot be used in this case since SNI does
not offer the ability to convey EUI-64 [EUI64] identifiers. not offer the ability to convey EUI-64 [EUI64] identifiers.
6.3.2. Certificates used by Clients 6.3.2. Certificates used by Clients
For client certificates the identifier used in the SubjectAltName or For client certificates the identifier used in the SubjectAltName or
in the leftmost CN component of subject name MUST be an EUI-64, as in the leftmost CN component of subject name MUST be an EUI-64, as
mandated in Section 9.1.3.3 of [RFC7252]. mandated in Section 9.1.3.3 of [RFC7252].
6.3.3. Certificate Revocation
For certificate revocation neither the Online Certificate Status For certificate revocation neither the Online Certificate Status
Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used.
Instead, this profile relies on a software update mechanism to Instead, this profile relies on a software update mechanism to
provision information about revoked certificates. While multiple provision information about revoked certificates. While multiple
OCSP stapling [RFC6961] has recently been introduced as a mechanism OCSP stapling [RFC6961] has recently been introduced as a mechanism
to piggyback OCSP request/responses inside the DTLS/TLS handshake (to to piggyback OCSP request/responses inside the DTLS/TLS handshake (to
avoid the cost of a separate protocol handshake), further avoid the cost of a separate protocol handshake), further
investigations are needed to determine its suitability for the IoT investigations are needed to determine its suitability for the IoT
environment. environment.
6.3.3. Certificate Content As stated earlier in this section, modifications to the trust anchor
store depends on a software update mechanism as well.
6.3.4. Certificate Content
All certificate elements listed in Table 1 are mandatory-to-implement All certificate elements listed in Table 1 are mandatory-to-implement
for client and servers claiming support for certificate-based for client and servers claiming support for certificate-based
authentication. No other certificate elements are used by this authentication. No other certificate elements are used by this
specification. specification.
When using certificates, IoT devices MUST provide support for a When using certificates, IoT devices MUST provide support for a
server certificate chain of at least 3 not including the trust anchor server certificate chain of at least 3 not including the trust anchor
and MAY reject connections from servers offering chains longer than and MAY reject connections from servers offering chains longer than
3. IoT devices MAY have client certificate chains of any length. 3. IoT devices MAY have client certificate chains of any length.
skipping to change at page 28, line 20 skipping to change at page 28, line 25
There are various algorithms used to sign digital certificates, such There are various algorithms used to sign digital certificates, such
as RSA, the Digital Signature Algorithm (DSA), and the Elliptic Curve as RSA, the Digital Signature Algorithm (DSA), and the Elliptic Curve
Digital Signature Algorithm (ECDSA). As Table 1 indicates Digital Signature Algorithm (ECDSA). As Table 1 indicates
certificate are signed using ECDSA. This is not only true for the certificate are signed using ECDSA. This is not only true for the
end-entity certificates but also for all other certificates in the end-entity certificates but also for all other certificates in the
chain, including CA certificates. chain, including CA certificates.
Further details about X.509 certificates can be found in Further details about X.509 certificates can be found in
Section 9.1.3.3 of [RFC7252]. Section 9.1.3.3 of [RFC7252].
6.3.4. Client Certificate URLs 6.3.5. Client Certificate URLs
RFC 6066 [RFC6066] allows to avoid sending client-side certificates RFC 6066 [RFC6066] allows to avoid sending client-side certificates
and uses URLs instead. This reduces the over-the-air transmission. and uses URLs instead. This reduces the over-the-air transmission.
Note that the TLS cached info extension does not provide any help Note that the TLS cached info extension does not provide any help
with caching client certificates. with caching client certificates.
TLS/DTLS clients MUST implement support for client certificate URLs TLS/DTLS clients MUST implement support for client certificate URLs
for those environments where client-side certificates are used and for those environments where client-side certificates are used and
the server-side is not constrained. For constrained servers this the server-side is not constrained. For constrained servers this
functionality is NOT RECOMMENDED since it forces the server to functionality is NOT RECOMMENDED since it forces the server to
execute an additional protocol exchange, potentially using a protocol execute an additional protocol exchange, potentially using a protocol
it does not even support. The use of this extension also increases it does not even support. The use of this extension also increases
the risk of a denial of service attack against the constrained server the risk of a denial of service attack against the constrained server
due to the additional workload. due to the additional workload.
6.3.5. Trusted CA Indication 6.3.6. 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 and to facilitate certification path anchors the client has stored and to facilitate certification path
construction as well as path validation, it includes intermediate CA construction as well as path validation, it includes intermediate CA
certs in the certificate payload. certs in the certificate payload.
Today, in most IoT deployments there is a fairly static relationship Today, in most IoT deployments there is a fairly static relationship
skipping to change at page 30, line 34 skipping to change at page 30, line 41
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
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. ciphersuites get added over time.
user_canceled: Many IoT devices are unattended and hence this error user_canceled: Many IoT devices are unattended and hence this error
message is unlikely to occur. message is unlikely to occur.
9. Session Resumption 9. Session Resumption
Session resumption is a feature of the core TLS/DTLS specifications Session resumption is a feature of the core TLS/DTLS specifications
that allows a client to continue with an earlier established session that allows a client to continue with an earlier established session
state. The resulting exchange is shown in Figure 10. In addition, state. The resulting exchange is shown in Figure 10. In addition,
the server may choose not to do a cookie exchange when a session is the server may choose not to do a cookie exchange when a session is
skipping to change at page 32, line 20 skipping to change at page 32, line 22
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
proposed in [I-D.schmertmann-dice-ccm-psk-pfs], might become proposed in [I-D.schmertmann-dice-ccm-psk-pfs], might become
available as standardized ciphersuite in the (near) future. The available as standardized ciphersuite in the (near) future. The
recommended PSK-based ciphersuite offers excellent performance, a recommended PSK-based ciphersuite offers excellent performance, a
very small memory footprint, and has the lowest on the wire overhead very small memory footprint, and has the lowest on the wire overhead
at the expense of not using any public cryptography. For deployments at the expense of not using any public cryptography. For deployments
where public key cryptography is acceptable the raw public might where public key cryptography is acceptable the raw public might
offer an acceptable middleground between the PSK ciphersuite in terms offer an acceptable middle ground between the PSK ciphersuite in
of out-of-band validation and the functionality offered by asymmetric terms of out-of-band validation and the functionality offered by
cryptography. asymmetric cryptography.
The use of PFS is a trade-off decision since on one hand the The use of PFS is a trade-off decision since on one hand the
compromise of long-term secrets of embedded devices is more likely compromise of long-term secrets of embedded devices is more likely
than with many other Internet hosts but on the other hand a Diffie- than with many other Internet hosts but on the other hand a Diffie-
Hellman exchange requires ephemeral key pairs to be generated, which Hellman exchange requires ephemeral key pairs to be generated, which
is demanding from a performance point of view. For obvious is demanding from a performance point of view. For obvious
performance improvement, some implementations re-use key pairs over performance improvement, some implementations re-use key pairs over
multiple exchanges (rather than generating new keys for each multiple exchanges (rather than generating new keys for each
exchange). However, note that such key re-use over long periods exchange). However, note that such key re-use over long periods
voids the benefits of forward secrecy when an attack gains access to voids the benefits of forward secrecy when an attack gains access to
skipping to change at page 33, line 25 skipping to change at page 33, line 27
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. As an additional feature, the same other peer is still alive. As an additional feature, the same
mechanism can also be used to perform Path Maximum Transmission Unit mechanism can also be used to perform Path Maximum Transmission Unit
(MTU) Discovery. (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 and the number of messages message exchange an IoT device performs and the number of messages
the application needs to exchange as part of their application the application needs to exchange as part of their application
functionality. There are three types of exchanges that need to be functionality. There are three types of exchanges that need to be
analysed: analyzed:
Client-Initiated, One-Shot Messages Client-Initiated, One-Shot Messages
This is a common communication pattern where IoT devices upload This is a common communication pattern where IoT devices upload
data to a server on the Internet on an irregular basis. The data to a server on the Internet on an irregular basis. The
communication may be triggered by specific events, such as opening communication may be triggered by specific events, such as opening
a door. a door.
Since the upload happens on an irregular and unpredictable basis Since the upload happens on an irregular and unpredictable basis
and due to renumbering and Network Address Translation (NAT) the and due to renumbering and Network Address Translation (NAT) the
skipping to change at page 36, line 47 skipping to change at page 36, line 50
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 applicable 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.
Implementations conformant to this specification MUST use AEAD Implementations conformant to this specification MUST use AEAD
ciphers. Hence, RFC 7366 and RFC 6066 are not applicable to this ciphers. Hence, RFC 7366 and RFC 6066 are not applicable to this
specifciation and MUST NOT be implemented. specification and MUST NOT be implemented.
16. Server Name Indication (SNI) 16. Server Name Indication (SNI)
The Server Name Indication extension defined in [RFC6066] defines a The Server Name Indication extension defined in [RFC6066] defines a
mechanism for a client to tell a TLS/DTLS server the name of the mechanism for a client to tell a TLS/DTLS server the name of the
server it wants to contact. This is a useful extension for many server it wants to contact. This is a useful extension for many
hosting environments where multiple virtual servers are run on single hosting environments where multiple virtual servers are run on single
IP address. IP address.
This specification RECOMMENDs the implementation of the Server Name This specification RECOMMENDs the implementation of the Server Name
skipping to change at page 38, line 30 skipping to change at page 38, line 34
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.
To prevent the re-negotiation attack [RFC5746] this specification To prevent the re-negotiation attack [RFC5746] this specification
RECOMMENDS to disable the TLS renegotigation feature. Clients MUST RECOMMENDS to disable the TLS renegotiation feature. Clients MUST
respond to server-initiated re-negotiation attempts with an alert respond to server-initiated re-negotiation attempts with an alert
message (no_renegotiation) and clients MUST NOT initiate them. message (no_renegotiation) and clients MUST NOT initiate 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 behavior 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 behavior that leads
some clients to re-run the handshake with lower version. As a some clients to re-run the handshake with lower version. As a
result, a potential security vulnerability is introduced when a result, a potential security vulnerability is introduced when a
system is running an old TLS/SSL version (e.g., because of the need system is running an old TLS/SSL version (e.g., because of the need
to integrate with legacy systems). In the worst case, this allows an to integrate with legacy systems). In the worst case, this allows an
attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is
so broken that there is no secure cipher available for it (see so broken that there is no secure cipher available for it (see
[I-D.ietf-tls-sslv3-diediedie]). [I-D.ietf-tls-sslv3-diediedie]).
The above-described downgrade vulnerability is solved by the TLS The above-described downgrade vulnerability is solved by the TLS
Fallback Signaling Cipher Suite Value (SCSV) [RFC7507] extension. Fallback Signaling Cipher Suite Value (SCSV) [RFC7507] extension.
However, the solution is not applicable to implementations conforming
However, the solution is not appliable to implementations conforming
to this profile since the version negotiation MUST use TLS/DTLS to this profile since the version negotiation MUST use TLS/DTLS
version 1.2 (or higher). More specifically, this implies: version 1.2 (or higher). More specifically, this implies:
o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in
the ClientHello. the ClientHello.
o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS
version lower than 1.2. version lower than 1.2.
o Servers MUST fail the handshake by sending a protocol_version o Servers MUST fail the handshake by sending a protocol_version
skipping to change at page 39, line 44 skipping to change at page 39, line 48
to be adjusted over time. Some deployment environments will also be to be adjusted over time. Some deployment environments will also be
impacted by local regulation, which might dictate a certain cipher impacted by local regulation, which might dictate a certain cipher
and key size. Ongoing discussions regarding the choice of specific and key size. Ongoing discussions regarding the choice of specific
ECC curves will also likely impact implementations. Note that this ECC curves will also likely impact implementations. Note that this
document does not recommend or mandate a specific ECC curve. document does not recommend or mandate a specific ECC curve.
The following recommendations can be made to chip manufacturers: The following recommendations can be made to chip manufacturers:
o Make any AES hardware-based crypto implementation accessible to o Make any AES hardware-based crypto implementation accessible to
developers working on security implementations at higher layers. developers working on security implementations at higher layers.
Sometimes hardware implementatios are added to microcontrollers to Sometimes hardware implementations are added to microcontrollers
offer support for functionality needed at the link layer and are to offer support for functionality needed at the link layer and
only available to the on-chip link layer protocol implementation. are only available to the on-chip link layer protocol
implementation.
o Provide flexibility for the use of the crypto function with future o Provide flexibility for the use of the crypto function with future
extensibility in mind. For example, making an AES-CCM extensibility in mind. For example, making an AES-CCM
implementation available to developers is a first step but such an implementation available to developers is a first step but such an
implementation may not be usable due to parameter differences implementation may not be usable due to parameter differences
between an AES-CCM implementations. AES-CCM in IEEE 802.15.4 and between an AES-CCM implementations. AES-CCM in IEEE 802.15.4 and
Bluetooth Smart uses a nonce length of 13-octets while DTLS uses a Bluetooth Smart uses a nonce length of 13-octets while DTLS uses a
nonce length of 12-octets. Hardware implementations of AES-CCM nonce length of 12-octets. Hardware implementations of AES-CCM
for IEEE 802.15.4 and Bluetooth Smart are therefore not re-usable for IEEE 802.15.4 and Bluetooth Smart are therefore not re-usable
by a DTLS stack. by a DTLS stack.
skipping to change at page 40, line 19 skipping to change at page 40, line 25
o Offer access to building blocks in addition (or as an alternative) o Offer access to building blocks in addition (or as an alternative)
to the complete functionality. For example, a chip manufacturer to the complete functionality. For example, a chip manufacturer
who gives developers access to the AES crypto function can use it who gives developers access to the AES crypto function can use it
to build an efficient AES-GCM implementations. Another example is to build an efficient AES-GCM implementations. Another example is
to make a special instruction available that increases the speed to make a special instruction available that increases the speed
of speed-up carryless multiplications. of speed-up carryless multiplications.
As a recommendation for developers and product architects we As a recommendation for developers and product architects we
recommend that sufficient headroom is provided to allow an upgrade to recommend that sufficient headroom is provided to allow an upgrade to
a newer cryptographic algorithms over the lifetime of the product. a newer cryptographic algorithms over the lifetime of the product.
As an example, while AES-CCM is recommended thoughout this As an example, while AES-CCM is recommended throughout this
specification future products might use the ChaCha20 cipher in specification future products might use the ChaCha20 cipher in
combination with the Poly1305 authenticator [RFC7539]. The combination with the Poly1305 authenticator [RFC7539]. The
assumption is made that a robust software update mechanism is assumption is made that a robust software update mechanism is
offered. offered.
22. Key Length Recommendations 22. Key Length Recommendations
RFC 4492 [RFC4492] gives approximate comparable key sizes for RFC 4492 [RFC4492] gives approximate comparable key sizes for
symmetric- and asymmetric-key cryptosystems based on the best-known symmetric- and asymmetric-key cryptosystems based on the best-known
algorithms for attacking them. While other publications suggest algorithms for attacking them. While other publications suggest
skipping to change at page 42, line 4 skipping to change at page 42, line 8
The conditions for using the TLS False Start mechanism are met by the The conditions for using the TLS False Start mechanism are met by the
public-key-based ciphersuites in this document. In summary, the public-key-based ciphersuites in this document. In summary, the
conditions are conditions are
o Modern symmetric ciphers with an effective key length of 128 bits, o Modern symmetric ciphers with an effective key length of 128 bits,
such as AES-128-CCM such as AES-128-CCM
o Client certificate types, such as ecdsa_sign o Client certificate types, such as ecdsa_sign
o Key exchange methods, such as ECDHE_ECDSA o Key exchange methods, such as ECDHE_ECDSA
Based on the improvement over a full roundtrip for the full TLS/DTLS
Based on the improvement over a full round-trip for the full TLS/DTLS
exchange this specification RECOMMENDS the use of the False Start exchange this specification RECOMMENDS the use of the False Start
mechanism when clients send application data first. mechanism when clients send application data first.
24. Privacy Considerations 24. Privacy Considerations
The DTLS handshake exchange conveys various identifiers, which can be The DTLS handshake exchange conveys various identifiers, which can be
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
skipping to change at page 43, line 12 skipping to change at page 43, line 18
be fixed. This software update mechanism is important for changing be fixed. This software update mechanism is important for changing
configuration information, for example, trust anchors and other configuration information, for example, trust anchors and other
keying related information. Such a suitable software update keying related information. Such a suitable software update
mechanism is available with the Lightweight Machine-to-Machine mechanism is available with the Lightweight Machine-to-Machine
(LWM2M) protocol published by the Open Mobile Alliance (OMA) [LWM2M]. (LWM2M) protocol published by the Open Mobile Alliance (OMA) [LWM2M].
26. IANA Considerations 26. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
27. Acknowledgements 27. Acknowledgments
Thanks to Derek Atkins, Olaf Bergmann, Paul Bakker, Robert Cragie, Thanks to Derek Atkins, Olaf Bergmann, Paul Bakker, Robert Cragie,
Russ Housley, Rene Hummen, Matthias Kovatsch, Sandeep Kumar, Sye Russ Housley, Rene Hummen, Jayaraghavendran K, Matthias Kovatsch,
Loong Keoh, Simon Lemay, Alexey Melnikov, Manuel Pegourie-Gonnard, Sandeep Kumar, Sye Loong Keoh, Simon Lemay, Alexey Melnikov, Manuel
Akbar Rahman, Eric Rescorla, Michael Richardson, Ludwig Seitz, Zach Pegourie-Gonnard, Akbar Rahman, Eric Rescorla, Michael Richardson,
Shelby, Michael StJohns, Rene Struik, and Sean Turner for their Ludwig Seitz, Zach Shelby, Michael StJohns, Rene Struik, and Sean
helpful comments and discussions that have shaped the document. Turner for their helpful comments and 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.
Finally, we would like to thank our area director (Stephen Farrell) Finally, we would like to thank our area director (Stephen Farrell)
and our working group chairs (Zach Shelby and Dorothy Gellert) for and our working group chairs (Zach Shelby and Dorothy Gellert) for
their support. their support.
28. References 28. References
skipping to change at page 46, line 17 skipping to change at page 46, line 22
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-sslv3-diediedie] [I-D.ietf-tls-sslv3-diediedie]
Barnes, R., Thomson, M., Pironti, A., and A. Langley, Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", draft- "Deprecating Secure Sockets Layer Version 3.0", draft-
ietf-tls-sslv3-diediedie-03 (work in progress), April ietf-tls-sslv3-diediedie-03 (work in progress), April
2015. 2015.
[I-D.irtf-cfrg-curves] [I-D.irtf-cfrg-curves]
Langley, A., Salz, R., and S. Turner, "Elliptic Curves for Langley, A. and R. Salz, "Elliptic Curves for Security",
Security", draft-irtf-cfrg-curves-02 (work in progress), draft-irtf-cfrg-curves-02 (work in progress), March 2015.
March 2015.
[I-D.josefsson-eddsa-ed25519] [I-D.josefsson-eddsa-ed25519]
Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft- Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft-
josefsson-eddsa-ed25519-03 (work in progress), May 2015. josefsson-eddsa-ed25519-03 (work in progress), May 2015.
[I-D.mathewson-no-gmtunixtime] [I-D.mathewson-no-gmtunixtime]
Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in
TLS", draft-mathewson-no-gmtunixtime-00 (work in TLS", draft-mathewson-no-gmtunixtime-00 (work in
progress), December 2013. progress), December 2013.
skipping to change at page 50, line 41 skipping to change at page 50, line 41
This section requires readers to be familiar with the terminology and This section requires readers to be familiar with the terminology and
concepts described in [GSM-SMS], and [WAP-WDP]. concepts described in [GSM-SMS], and [WAP-WDP].
The remainder of this section assumes Mobile Stations are capable of The remainder of this section assumes Mobile Stations are capable of
producing and consuming 8-bit binary data encoded Transport Protocol producing and consuming 8-bit binary data encoded Transport Protocol
Data Units (TPDU). Data Units (TPDU).
A.1. Overview A.1. Overview
DTLS adds an additional roundtrip to the TLS [RFC5246] handshake to DTLS adds an additional round-trip to the TLS [RFC5246] handshake to
serve as a return-routability test for protection against certain serve as a return-routability test for protection against certain
types of DoS attacks. Thus a full blown DTLS handshake comprises up types of DoS attacks. Thus a full blown DTLS handshake comprises up
to 6 "flights" (i.e., logical message exchanges), each of which is to 6 "flights" (i.e., logical message exchanges), each of which is
then mapped on to one or more DTLS records using the segmentation and then mapped on to one or more DTLS records using the segmentation and
reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. The reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. The
overhead for said scheme is 6 bytes per Handshake message which, overhead for said scheme is 6 bytes per Handshake message which,
given a realistic 10+ messages handshake, would amount around 60 given a realistic 10+ messages handshake, would amount around 60
bytes across the whole handshake sequence. bytes across the whole handshake sequence.
Note that the DTLS SaR scheme is defined for handshake messages only. Note that the DTLS SaR scheme is defined for handshake messages only.
skipping to change at page 54, line 6 skipping to change at page 54, line 6
o 2 octet version field, o 2 octet version field,
o 2 octet epoch field, o 2 octet epoch field,
o 6 octet sequence number, o 6 octet sequence number,
o 2 octet length field. o 2 octet length field.
The "nonce" input to the AEAD algorithm is exactly that of [RFC5288], The "nonce" input to the AEAD algorithm is exactly that of [RFC5288],
i.e., 12 bytes long. It consists of a 4 octet salt and an 8 octet i.e., 12 bytes long. It consists of two values, namely a 4 octet
nonce. The salt is the "implicit" part of the nonce and is not sent salt and an 8 octet nonce_explicit:
in the packet. Since the nonce_explicit may be the 8 octet sequence
number and, in DTLS, it is the 8 octet epoch concatenated with the 6
octet sequence number.
RFC 6655 [RFC6655] allows the nonce_explicit to be a sequence number The salt is the "implicit" part and is not sent in the packet.
or something else. This document makes this use more restrictive for Instead, the salt is generated as part of the handshake process.
use with DTLS: the 64-bit none_explicit MUST be the 16-bit epoch
concatenated with the 48-bit seq_num. The sequence number component
of the nonce_explicit field at the AES-CCM layer is an exact copy of
the sequence number in the record layer header field. This leads to
a duplication of 8-bytes per record.
To avoid this 8-byte duplication RFC 7400 [RFC7400] provides help The nonce_explicit value is 8 octet long and it is chosen by the
with the use of the generic header compression technique for IPv6 sender and carried in each TLS record. RFC 6655 [RFC6655] allows
over Low-Power Wireless Personal Area Networks (6LoWPANs). Note that the nonce_explicit to be a sequence number or something else.
this header compression technique is not available when DTLS is This document makes this use more restrictive for use with DTLS:
exchanged over transports that do not use IPv6 or 6LoWPAN, such as the 64-bit none_explicit value MUST be the 16-bit epoch
the SMS transport described in Appendix A. concatenated with the 48-bit seq_num. The sequence number
component of the nonce_explicit field at the AES-CCM layer is an
exact copy of the sequence number in the record layer header
field. This leads to a duplication of 8-bytes per record.
To avoid this 8-byte duplication RFC 7400 [RFC7400] provides help
with the use of the generic header compression technique for IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs). Note
that this header compression technique is not available when DTLS
is exchanged over transports that do not use IPv6 or 6LoWPAN, such
as the SMS transport described in Appendix A.
Appendix C. DTLS Fragmentation Appendix C. DTLS Fragmentation
[Editor's Note: Proposed text that requires discussion. ] [Editor's Note: Proposed text that requires discussion. ]
Section 4.2.3 of [RFC6347] advises DTLS implementations to not Section 4.2.3 of [RFC6347] advises DTLS implementations to not
produce overlapping fragments, but requires receivers to be able to produce overlapping fragments, but requires receivers to be able to
cope with them. The need for the latter requisite is explained in 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 Section 4.1.1.1 of [RFC6347]: accurate path MTU (PMTU) estimation may
be traded for shorter handshake completion time. This approach may be traded for shorter handshake completion time. This approach may
 End of changes. 32 change blocks. 
63 lines changed or deleted 71 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/