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

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

            

Figure 11: DTLS Session Resumption.

Constrained clients MUST implement session resumption to improve the performance of the handshake. This will lead to a reduced number of message exchanges, lower computational overhead (since only symmetric cryptography is used during a session resumption exchange), and session resumption requires less bandwidth.

For cases where the server constrained (but not the client) the client MUST implement RFC 5077 [RFC5077]. Note that the constrained server refers to a device that has limitations in terms of RAM and flash memory, which place restrictions on the amount of TLS/DTLS security state information that can be stored on such a device. RFC 5077 specifies a version of TLS/DTLS session resumption that does not require per-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. Clients that do not want to use session resumption are always able to send a ClientHello message with an empty session_id to revert to a full handshake.

10. Compression

Section 3.3 of [RFC7525] 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.

This TLS/DTLS profile MUST NOT implement 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.2 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 middle ground 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 obvious performance improvement, some implementations re-use key pairs over multiple exchanges (rather than generating new keys for each exchange). However, note 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.

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

12. Keep-Alive

Application layer communication may create state at the endpoints and this state my expire at some time. For this reason, applications define ways to refresh state, if necessary. While the application layer exchanges are largely outside the scope of the underlying TLS/DTLS exchange similar state considerations also play a role at the level of TLS/DTLS. While TLS/DTLS also creates state in form of a security context (see the security parameter described in Appendix A6 in RFC 5246) at the client and the server this state information does not expire. However, network intermediaries may also allocate state and require this state to be kept alive. Failure to keep state alive at a stateful packet filtering firewall or at a NAT may result in the inability for one node to reach the other since packets will get blocked by these middleboxes. Periodic keep-alive messages exchanged between the TLS/DTLS client and server keep state at these middleboxes alive. According to measurements described in [HomeGateway] there is some variance in state management practices used in residential gateways but the timeouts are heavily impacted by the choice of the transport layer protocol: timeouts for UDP are typically much shorter than those for TCP.

RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the other peer is still alive. As an additional feature, 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 and the number of messages the application needs to exchange as part of their application functionality. There are three types of exchanges that need to be analyzed:

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 and maintains it. Since messages to the client may get blocked by middleboxes the initial connection setup is triggered by the client and then kept alive by the server.

For this message exchange pattern the use of DTLS heartbeat messages is quite useful but may have to be coordinated with application exchanges (for example when the CoAP resource directory is used) to avoid redundant keep-alive message exchanges. 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 is 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 [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 doubled with at each retransmission up to no less than 60 seconds.

TLS protocol steps can take longer due to higher processing time on the constrained side. On the other hand, the way DTLS handles retransmission, which is per-flight instead of per-segment, tends to interact poorly with low bandwidth networks.

For these reasons, it's essential that the probability of a spurious retransmit is minimized and, on timeout, the sending endpoint does not react too aggressively. The latter is particularly relevant when the WSN is temporarily congested: if lost packets are re-injected too quickly, congestion worsens.

An initial timer value of 9 seconds with exponential back off up to no less then 60 seconds is therefore RECOMMENDED.

This value is chosen big enough to absorb large latency variance due to either slow computation on constrained endpoints or to intrinsic network characteristics (e.g. GSM-SMS), as well as to produce a low number of retransmission events and relax the pacing between them. Its worst case wait time is the same as using 1s timeout (i.e. 63s), while triggering less then half retransmissions (2 instead of 5).

In order to minimise the wake time during DTLS handshake, sleepy nodes might decide to select a lower threshold, and consequently a smaller initial timeout value. If this is the case, the implementation MUST keep into account the considerations about network stability described in this section.

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.

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.

Lacking sources of randomness in an embedded system may lead to the same keys generated again and again.

The ClientHello and the ServerHello messages contains the 'Random' structure, which has two components: gmt_unix_time and a 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). Since many IoT devices do not have access to an accurate clock, it is RECOMMENDED to place a sequence of random bytes in the two components of the 'Random' structure when creating a ClientHello or ServerHello message and not to assume a structure when receiving these payloads.

When TLS is used with certificate-based authentication the availability of time information is needed to check the validity of a certificate. Higher-layer protocols may provide secure time information. The gmt_unix_time component of the ServerHello is not used for this purpose.

IoT devices using TLS/DTLS must offer ways to generate quality random numbers. There are various implementation choices for integrating a hardware-based random number generator into a product: an implementation inside the microcontroller itself is one option but also dedicated crypto-chips are reasonable choices. The best choice will depend on various factors outside the scope of this document. Guidelines and requirements for random number generation can be found in RFC 4086 [RFC4086] and in the NIST Special Publication 800-90a [SP800-90A].

Chip manufacturers are highly encouraged to provide sufficient documentation of their design for random number generators so that customers can have confidence about the quality of the generated random numbers. The confidence can be increased by providing information about the procedures that have been used to verify the randomness of numbers generated by the hardware modules. For example, NIST Special Publication 800-22b [SP800-22b] describes statistical tests that can be used to verify random random number generators.

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 applicable 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.

Implementations conformant to this specification MUST use AEAD ciphers. Hence, RFC 7366 and RFC 6066 are not applicable to this specification and MUST NOT be implemented.

16. Server Name Indication (SNI)

The Server Name Indication extension defined in [RFC6066] 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.

This specification RECOMMENDs the implementation of the Server Name Indication extension unless it is known that a TLS/DTLS client does not interact with a server in a hosting environment.

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 to allow 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).

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 [Triple-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.

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.

To prevent the re-negotiation attack [RFC5746] this specification RECOMMENDS to disable the TLS renegotiation 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 behavior 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 behavior 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) [RFC7507] extension. However, the solution is not applicable 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 this profile reaches the quality of SSL 3.0 a software update 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 as well. Some deployment environments will also be impacted by local regulation, which might dictate a certain algorithm and key size combination. Ongoing discussions regarding the choice of specific ECC curves will also likely impact implementations. Note that this document does not recommend or mandate a specific ECC curve.

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 in the protocol stack. Sometimes hardware implementations 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. Such a setup does not allow application developers to re-use the hardware-based AES 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 the AES crypto function can use it 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 suggest 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 throughout this specification future products might use the ChaCha20 cipher in combination with the Poly1305 authenticator [RFC7539]. 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 12 illustrates the comparable key sizes in bits.

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

            

              
0        1        2        3        4
+--------+--------+--------+--------+--------+
| ...    | 0x04   | 2      | ...    | ...    |
+--------+--------+--------+--------+--------+
  UDH      IEI      IE       Dest     Source
  Length            Length   Port     Port

            

              
0        1        2        3        4        5        6
+--------+--------+--------+--------+--------+--------+--------+
| ...    | 0x05   | 4      |       ...       |       ...       |
+--------+--------+--------+--------+--------+--------+--------+
  UDH      IEI      IE       Dest              Source
  Length            Length   Port              Port

            

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