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

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

            

Figure 8: 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/DTLS session resumption without server-side state is not utilized by this profile.

10. Compression

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 applications compression at the TLS/DTLS layer is not needed since application layer protocols are highly optimized and the compression algorithms at the DTLS layer increases code size and complexity.

Recommendation: This TLS/DTLS profile MUST NOT implement and use TLS/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 recommended PSK-based ciphersuite offers excellent performance, a very small memory footprint, and has the lowest on the wire overhead at the expense of not using any public cryptography. For deployments where public key cryptography is acceptable the raw public might offer an acceptable middleground between the PSK ciphersuite in terms of out-of-band validation and the functionality offered by asymmetric cryptography.

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.

Recommendation: Client implementations claiming support of this profile MUST implement the ciphersuites listed in Section 6 according to the selected credential type.

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) the DTLS handshake may need to be re-started (ideally using session resumption, if possible).

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 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 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 but may interfere with registrations kept at the application layer (for example when the CoAP resource directory is used). 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, path MTU discovery might be appropriate. It also has to be noted that DTLS itself already provides a basic path discovery mechanism (see Section 4.1.1.1 of RFC 6347 by using the fragmentation capability of the handshake protocol).

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.

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.

Recommendation: 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. Appendix A provides additional normative text for carrying DTLS over SMS.

14. Random Number Generation

The TLS/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.

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 messages 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 ClientHello.Random value (including gmt_unix_time) should be set to a cryptographically random sequence because of privacy concerns regarding device fingerprinting. Since many IoT devices do not have access to a real-time clock this recommendation it is RECOMMENDED to follow the guidance outlined in [I-D.mathewson-no-gmtunixtime] regarding the content of the ClientHello.Random field. However, for the ServerHello.Random structure it is RECOMMENDED to maintain the existing structure with gmt_unix_time followed by a random sequence of 28 random bytes since the client can use the received time information to securely obtain time information.

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

15. Truncated MAC and Encrypt-then-MAC Extension

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. This extension was developed for TLS ciphersuites that used older modes of operation where the MAC and the encryption operation was performed independently.

The recommended ciphersuites in this document use the newer Authenticated Encryption with Associated Data (AEAD) construct, namely the CBC-MAC mode (CCM) with eight-octet authentication tags, and are therefore not appliable to the truncated MAC extension.

RFC 7366 [RFC7366] introduced the encrypt-then-MAC extension (instead of the previously used MAC-then-encrypt) since the MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities. RFC 7366 is, however, also not applicable to the AEAD ciphers recommended in this document.

Recommendation: Since this profile only supports AEAD ciphersuites these two extensions are not applicable.

16. Server Name Indication (SNI)

This RFC 6066 extension defines a 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 hosting environments where multiple virtual servers are run on single IP address.

Recommendation: Unless it is known that a TLS/DTLS client does not interact with a server in a hosting environment we RECOMMEND clients to implement the SNI extension.

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. Session Hash

In order to begin connection protection, the Record Protocol requires specification of a suite of algorithms, a master secret, and 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 a small number of parameters exchanged during the handshake and does not include parameters like 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, as discovered in the 'Triple Handshake' attack [Tripple-HS].

[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/DTLS allows a client and a server who already have a TLS/DTLS connection to negotiate new parameters, generate new keys, etc by using the re-negotiation feature. Renegotiation happens in the existing 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.

Recommendation: To prevent the re-negotiation attack [RFC5746] this specification RECOMMENDS to disable 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

When a client sends a ClientHello with a version higher than the highest version known to the server, the server is supposed to reply with ServerHello.version equal to the highest version known to the server and the handshake can proceed. This behaviour is known as version tolerance. Version-intolerance is when the server (or a middlebox) breaks the handshake when it sees a ClientHello.version higher than what it knows about. This is the behaviour that leads some clients to re-run the handshake with lower version. As a result, a potential security vulnerability is introduced when a 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 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 [I-D.ietf-tls-sslv3-diediedie]).

The above-described downgrade vulnerability is solved by the TLS Fallback Signaling Cipher Suite Value (SCSV) [I-D.ietf-tls-downgrade-scsv] extension. However, the solution is not appliable to implementations conforming to this profile since the version negotiation MUST use TLS/DTLS version 1.2 (or higher). More specifically, this implies:

• Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in the ClientHello.
• Clients MUST NOT retry a failed negotiation offering a TLS/DTLS version lower than 1.2.
• Servers MUST fail the handshake by sending a protocol_version fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated. Note that the aborted connection is non-resumable.

If at some time in the future the TLS/DTLS 1.2 profile reaches the quality of SSL 3.0 a software update mechanism is needed since constrained devices are unlikely to run multiple TLS/DTLS versions due to memory size restrictions.

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 9 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

            

DTLS Record Layer Header................13 bytes
Nonce (Explicit).........................8 bytes
ICV..................................... 8 bytes
------------------------------------------------
Overhead................................29 bytes
------------------------------------------------