Client                                               Server
      ------                                               ------

      ClientHello                   -------->
                                                       ServerHello
                                                [ChangeCipherSpec]
                                    <--------             Finished
      [ChangeCipherSpec]
      Finished                      -------->
      Application Data              <------->     Application Data

            

Figure 5: DTLS Session Resumption.

Clients MUST implement session resumption to improve the performance of the handshake (in terms of reduced number of message exchanges, lower computational overhead, and less bandwidth conserved).

Since the communication model described in Section 4 does not assume that the server is constrained RFC 5077 [RFC5077] specifying TLS session resumption without server-side state is not utilized by this profile.

10. Compression

[I-D.ietf-uta-tls-bcp] recommends to always disable DTLS-level compression due to attacks. For IoT applications compression at the DTLS is not needed since application layer protocols are highly optimized and the compression algorithms at the DTLS layer increase code size and complexity.

This DTLS client profile does not include DTLS layer compression.

11. Perfect Forward Secrecy

Perfect forward secrecy (PFS) is a property that preserves the confidentiality of past conversations even in situations where the long-term secret is compromised.

The PSK ciphersuite recommended in Section 6.1 does not offer this property since it does not utilize a Diffie-Hellman exchange. New ciphersuites that support PFS for PSK-based authentication, such as proposed in [I-D.schmertmann-dice-ccm-psk-pfs], might become available as standardized ciphersuite in the (near) future.

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 than with many other Internet hosts but on the other hand a Diffie-Hellman exchange requires ephemeral key pairs to be generated, which is demanding from a performance point of view. For performance reasons some implementations re-use key pairs over multiple exchanges (rather than generating new keys for each exchange) for the obvious performance improvement. Note, however, that such key re-use over long periods voids the benefits of forward secrecy when an attack gains access to this DH key pair.

The impact of the disclosure of past conversations and the desire to increase the cost for pervasive monitoring (as demanded by [RFC7258]) has to be taken into account when making a deployment decision.

This specification recommends the use of the ciphersuites listed in Section 6.

12. Keep-Alive

RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the other peer is still alive. The same mechanism can also be used to perform Path Maximum Transmission Unit (MTU) Discovery.

A recommendation about the use of RFC 6520 depends on the type of message exchange an IoT device performs. There are three types of exchanges that need to be analysed:

Client-Initiated, One-Shot Messages

This is a common communication pattern where IoT devices upload data to a server on the Internet on an irregular basis. The communication may be triggered by specific events, such as opening a door.

Since the upload happens on an irregular and unpredictable basis and due to renumbering and Network Address Translation (NAT) a new DTLS session or DTLS session resumption can be used.

In this case there is no use for a keep-alive extension for this scenario.

Client-Initiated, Regular Data Uploads

This is a variation of the previous case whereby data gets uploaded on a regular basis, for example, based on frequent temperature readings. If neither NAT bindings nor IP address changes occurred then the DTLS record layer will not notice any changes. For the case where the IP address and port number changes, it is necessary to re-create the DTLS record layer using session resumption.

In this scenario there is no use for a keep-alive extension. It is also very likely that the device will enter a sleep cycle in between data transmissions to keep power consumption low.

Server-Initiated Messages

In the two previous scenarios the client initiated the protocol interaction but in this case we consider server-initiated messages. Since messages to the client may get blocked by intermediaries, such as NATs (including IPv4/IPv6 protocol translators) and stateful packet filtering firewalls, the initial connection setup is triggered by the client and then kept alive. Since state at middleboxes expires fairly quickly (according to measurements described in [HomeGateway]), regular heartbeats are necessary whereby these keep-alive messages may be exchanged at the application layer or within DTLS itself.

For this message exchange pattern the use of DTLS heartbeat messages is quite useful. The MTU discovery mechanism, which is also part of [RFC6520], is less likely to be relevant since for many IoT deployments the most constrained link is the wireless interface between the IoT device and the network itself (rather than some links along the end-to-end path). Only in more complex network topologies, such as multi-hop mesh networks, the situation is.

For server-initiated messages the heartbeat extension can be RECOMMENDED.

13. Timeouts

To connect to the Internet a variety of wired and wireless technologies are available. Many of the low power radio 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 explained in RFC 4919 [RFC4919]). Other radio technologies, such as the Global System for Mobile Communications (GSM) using the short messaging service (SMS) have similar constraints in terms of payload sizes, such as 140 bytes without the optional segmentation and reassembly scheme known as Concatenated SMS, but show higher latency.

The DTLS handshake protocol adds a fragmentation and reassembly mechanism to the TLS handshake protocol since each DTLS record must fit within a single transport layer datagram, as described in Section 4.2.3 of [RFC6347]. Since handshake messages are potentially bigger than the maximum record size, the mechanism fragments a handshake message over a number of DTLS records, each of which can be transmitted separately.

To deal with the unreliable message delivery provided by UDP, DTLS adds timeouts and re-transmissions, as described in Section 4.2.4 of [RFC6347]. Although the timeout values are implementation specific, recommendations are provided in Section 4.2.4.1 of [RFC6347], with an 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 some radio technologies, these values are too aggressive and lead to spurious failures when messages in flight need longer.

Choosing appropriate timeout values is difficult with infrequent data transmissions, changing network conditions, and large variance in latency. This specification therefore RECOMMENDS an initial timer value of 10 seconds with exponential back off up to no less then 60 seconds.

Note: If a round-trip time estimator (such as proposed in [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 retransmit timeout.

Appendix A provides additional information for carrying DTLS over SMS.

14. Random Number Generation

The DTLS protocol requires random numbers to be available during the protocol run. For example, during the ClientHello and the ServerHello exchange the client and the server exchange random numbers. Also, the use of the Diffie-Hellman exchange requires random numbers during the key pair generation. Special care has to be paid when generating random numbers in embedded systems as many entropy sources available on desktop operating systems or mobile devices might be missing, as described in [Heninger]. Consequently, if not enough time is given during system start time to fill the entropy pool then the output might be predictable and repeatable, for example leading to the same keys generated again and again.

Recommendation: IoT devices using DTLS MUST offer ways to generate quality random numbers. Guidelines and requirements for random number generation can be found in RFC 4086 [RFC4086].

It is important to note that sources contributing to the randomness pool on laptops, or desktop PCs are not available on many IoT device, such as mouse movement, timing of keystrokes, air turbulence on the movement of hard drive heads, etc. Other sources have to be found or dedicated hardware has to be added.

The ClientHello and the ServerHello message contains the 'Random' structure, which has two components: gmt_unix_time and a random sequence of 28 random bytes. gmt_unix_time holds the current time and date in standard UNIX 32-bit format (seconds since the midnight starting Jan 1, 1970, GMT). [I-D.mathewson-no-gmtunixtime] argues that the entire value the ClientHello.Random and ServerHello.Random fields, including gmt_unix_time, should be set to a cryptographically random sequence because of privacy concerns (fingerprinting). Since many IoT devices do not have access to a real-time clock this recommendation is even more relevant in the embedded systems environment.

15. Truncated MAC Extension

The truncated MAC extension was introduced with RFC 6066 with the goal to reduces the size of the MAC used at the Record Layer. This extension was developed for TLS ciphersuites that used older modes of operation where the MAC and the encryption operation was performed independently.

For CoAP, however, the recommended ciphersuites use the newer Authenticated Encryption with Associated Data (AEAD) construct, namely the CBC-MAC mode (CCM) with eight-octet authentication tags. Furthermore, the extension [RFC7366] introducing the encrypt-then-MAC security mechanism (instead of the MAC-then-encrypt) is also not applicable for this profile.

Recommendation: Since this profile only supports AEAD ciphersuites this extension is not applicable.

16. Server Name Indication (SNI)

This RFC 6066 extension defines a mechanism for a client to tell a TLS server the name of the server it wants to contact. This is a useful extension for many hosting environments where multiple virtual servers are run on single IP address.

Recommendation: Unless it is known that a DTLS client does not interact with a server in a hosting environment that requires such an extension we advice to offer support for the SNI extension in this profile.

17. Maximum Fragment Length Negotiation

This RFC 6066 extension lowers the maximum fragment length support 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 the server how much maximum memory buffers it uses for incoming messages. Ultimately, the main benefit of this extension is it to allows client implementations to lower their RAM requirements since the client does not need to accept packets of large size (such as 16k packets as required by plain TLS/DTLS).

Recommendation: Client implementations MUST support this extension.

18. TLS Session Hash

The TLS master secret is not cryptographically bound to important session parameters such as the client and server identities. This 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 sessions.

[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 preventing such attacks.

Recommendation: Client implementations SHOULD implement this extension even though the ciphersuites recommended by this profile are not vulnerable to this attack. For Diffie-Hellman-based ciphersuites the keying material is contributed by both parties and in case of the pre-shared secret key ciphersuite both parties need to be in possession of the shared secret to ensure that the handshake completes successfully. It is, however, possible that some application layer protocols will tunnel other authentication protocols on top of DTLS making this attack relevant again.

19. Re-Negotiation Attacks

TLS and DTLS allows a client and a server who already have a TLS connection to negotiate new parameters, generate new keys, etc by using a feature in TLS called re-negotiation. Renegotiation happens in the existing TLS connection, with the new handshake packets being encrypted along with application data. Upon completion of the re-negotiation procedure the new channel replaces the old channel.

As described in RFC 5746 [RFC5746] there is no cryptographic binding between the two handshakes, although the new handshake is carried out using the cryptographic parameters established by the original handshake.

To prevent the TLS re-negotiation attack [RFC5746] this specification RECOMMENDS not to use the TLS renegotigation feature. Clients MUST respond to server-initiated re-negotiation attempts with an Alert message (no_renegotiation) and clients MUST NOT initiate them.

20. Downgrading Attacks

[Editor's Note: Additional text needed.]

This specification demands version 1.2 of DTLS to be used and DTLS version 1.1 is not supported. Unlike with TLS where many earlier versions exist there is no risk of downgrading to an older version of DTLS in context of this profile. The work described in [I-D.bmoeller-tls-downgrade-scsv] is therefore also not applicable to this environment since there is no legacy DTLS/TLS IoT server infrastructure when this profiled is followed.

21. Crypto Agility

This document recommends software and chip manufacturers to implement AES and the CCM mode of operation. This document references the CoAP recommended ciphersuite choices, which have been selected based on implementation and deployment experience from the IoT community. Over time the preference for algorithms will, however, change. Not all components of a ciphersuite are likely to change at the same speed. Changes are more likely expected for ciphers, the mode of operation, and the hash algorithms. The recommended key lengths have to be adjusted over time. Some deployment environments will also be impacted by local regulation, which might dictate a certain cipher and key size. Ongoing discussions regarding the choice of specific ECC curves will also likely to impact implementations.

The following recommendations can be made to chip manufacturers:

• Make any AES hardware-based crypto implementation accessible to developers working on security implementations at higher layers. Sometimes hardware implementatios are added to microcontrollers to offer support for functionality needed at the link layer and are only available to the on-chip link layer protocol implementation.
• Provide flexibility for the use of the crypto function with future extensibility in mind. For example, making an AES-CCM implementation available to developers is a first step but such an implementation may not be usable due to parameter differences 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 nonce length of 12-octets. Hardware implementations of AES-CCM for IEEE 802.15.4 and Bluetooth Smart are therefore not re-usable by a DTLS stack.
• Offer access to building blocks in addition (or as an alternative) to the complete functionality. For example, a chip manufacturer who gives developers access to an the AES crypto function can use it in functions to build an efficient AES-GCM implementations. Another example is to make a special instruction available that increases the speed of speed-up carryless multiplications.

As a recommendation for developers and product architects we recommend that sufficient headroom is provided to allow an upgrade to a newer cryptographic algorithms over the lifetime of the product. As an example, while AES-CCM is recommended thoughout this specification future products might use the ChaCha20 cipher in combination with the Poly1305 authenticator [I-D.irtf-cfrg-chacha20-poly1305]. The assumption is made that a robust software update mechanism is offered.

22. Key Length Recommendations

RFC 4492 [RFC4492] gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best-known algorithms for attacking them. While other publications suggest slightly different numbers, such as [Keylength], the approximate relationship still holds true. Figure 6 illustrates the comparable key sizes in bits.

At the time of writing the key size recommendations for use with TLS-based ciphers found in [I-D.ietf-uta-tls-bcp] recommend DH key lengths of at least 2048 bit, which corresponds to a 112-bit symmetric key and a 233 bit ECC keys. These recommendations are inline with those from other organizations, such as National Institute of Standards and Technology (NIST) or European Network and Information Security Agency (ENISA). The authors of [ENISA-Report2013] add that a symmetric 80-bit security level is sufficient for legacy applications for the coming years, but a 128-bit security level is the minimum requirement for new systems being deployed. The authors further note that one needs to also take into account the length of time data needs to be kept secure for. The use 80-bit encryption for transactional data may be acceptable for the near future while one has to insist on 128-bit encryption for long lived data.

              
                    Symmetric  |   ECC   |  DH/DSA/RSA
                   ------------+---------+-------------
                        80     |   163   |     1024
                       112     |   233   |     2048
                       128     |   283   |     3072
                       192     |   409   |     7680
                       256     |   571   |    15360