RFC 7925
Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things
RFC 7925: TLS/DTLS Profiles for the Internet of Things 🎀
okay bestie, this one is RFC 7925, and it's a Standards Track document from July 2016 🦋 it's from the IETF, and the main authors are H. Tschofenig (he's the editor, Ed.) at ARM Ltd. and T. Fossati at Nokia. it's published as ISSN 2070-1721. the header doesn't list any obsoletes or updates, so it's not replacing or changing anything else 💅
Abstract ✨
okay so picture a tiny device that collects data from sensors or controls actuators, the kind of thing running home automation, industrial control, smart cities, and other IoT setups 🏠 this doc is basically saying "hey, let's lock that data exchange down" with a TLS and DTLS 1.2 profile 🔒 it's all about stopping eavesdropping, tampering, and message forgery. the wild part is that lacking communication security is a super common IoT vulnerability, and it's literally solvable with well-researched, widely deployed Internet security protocols 😭 the fix is already sitting right there!!
Status of This Memo 📜
ok so this is an Internet Standards Track document. it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 7841. and for the current status, any errata, or to give feedback, the page is http://www.rfc-editor.org/info/rfc7925 🌸
Copyright Notice ©️
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 🧾
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. TLS and DTLS . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Communication Models . . . . . . . . . . . . . . . . . . 6
3.3. The Ciphersuite Concept . . . . . . . . . . . . . . . . . 20
4. Credential Types . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 23
4.3. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 25
4.4. Certificates . . . . . . . . . . . . . . . . . . . . . . 27
5. Signature Algorithm Extension . . . . . . . . . . . . . . . . 32
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 32
7. Session Resumption . . . . . . . . . . . . . . . . . . . . . 34
8. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 35
10. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 36
11. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 38
12. Random Number Generation . . . . . . . . . . . . . . . . . . 39
13. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 40
14. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 40
15. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 41
16. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 41
17. Renegotiation Attacks . . . . . . . . . . . . . . . . . . . . 42
18. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 42
19. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 43
20. Key Length Recommendations . . . . . . . . . . . . . . . . . 44
21. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 45
22. Privacy Considerations . . . . . . . . . . . . . . . . . . . 45
23. Security Considerations . . . . . . . . . . . . . . . . . . . 46
24. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
24.1. Normative References . . . . . . . . . . . . . . . . . . 47
24.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 56
A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 56
A.2. Message Segmentation and Reassembly . . . . . . . . . . . 57
A.3. Multiplexing Security Associations . . . . . . . . . . . 57
A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 58
Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 59
Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 60
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 611. Introduction 🧚
okay so an engineer building an Internet of Things (IoT) device has to look at the security threats first, then pick the security services that can shut those threats down 🔍
enabling IoT devices to swap data usually means the two endpoints need to authenticate each other, plus the data needs integrity and confidentiality protection 🛡️ these services can live at different layers of the stack, but Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) has been super popular with lots of application protocols, and it's very likely to be useful for IoT too 💜
fitting Internet protocols onto constrained devices can be rough ngl, but standardization work has produced new profiles and protocols, like the Constrained Application Protocol (CoAP) [RFC7252] 🌈 CoAP messages mostly travel over UDP/DTLS, but other transports work too: SMS (described in Appendix A) or TCP (which is currently being proposed with [COAP-TCP-TLS]) 📱
the main goal here is protecting CoAP messages with DTLS 1.2 [RFC6347] 🎯 BUT the info in the following sections isn't limited to CoAP, or even to DTLS itself. it's bigger than that!
so this document defines a profile of DTLS 1.2 [RFC6347] and TLS 1.2 [RFC5246] that offers communication security services for IoT applications, and that's reasonably implementable on many constrained devices 💖 a profile here means the available configuration options and protocol extensions get used in the way that best supports the IoT environment ✨ and the big slay: this document does not alter the TLS/DTLS specifications, and it doesn't introduce any new TLS/DTLS extension 🙌
the main audience is the embedded system developer who's configuring and using a TLS/DTLS stack 👩💻 but it may also help folks who are developing or picking a suitable TLS/DTLS stack for an IoT product 🎀 if you already know (D)TLS, you can skip ahead to Section 4, no shame 🫶
2. Terminology 📖
okay the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document get interpreted the way RFC 2119 [RFC2119] describes them 📚 these are the important ones, so watch for them!!
this spec talks about TLS and DTLS, especially version 1.2, which was the most recent version when it was written 🕰️ we say TLS/DTLS whenever something applies to both versions, and we call out TLS or DTLS when they differ 🔀 also, TLS 1.3 is being developed, but this profile isn't expected to "just work" with it, since TLS 1.3 has significant changes 😬
quick heads up: "client" and "server" here are TLS/DTLS roles, and the client is the one that starts the handshake 🤝 that doesn't limit how the protocols on top of DTLS interact, because the record layer allows bidirectional communication 🔁 we dig into that more in Section 3.2 💅
RFC 7228 [RFC7228] introduces the idea of constrained-node networks, which are made of small devices with serious limits on power, memory, and processing 🔋 "constrained devices" and "IoT devices" are used interchangeably, so don't be confused 🫠
the terms "certification authority" (CA) and "distinguished name" (DN) come from [RFC5280] 🪪 and "trust anchor" and "trust anchor store" are defined in [RFC6024] like this:
A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A trust anchor store is a set of one or more trust anchors stored in a device.... A device may have more than one trust anchor store, each of which may be used by one or more applications.
ok that's the whole vibe for part one, and the big bag of TLS/DTLS goodness is next 🦋 buckle up!
3. Overview ✨
3.1. TLS and DTLS 🎀
okay so TLS [RFC5246] is the protocol that gives you authenticated, confidentiality- and integrity-protected communication between two endpoints, and it's giving security queen energy 👑. It has two layers: the Record Protocol and the handshaking protocols. At the bottom, sitting on top of a reliable transport protocol (e.g., TCP), is the Record Protocol 🧚. It keeps the connection secure with symmetric cryptography for confidentiality, data origin authentication, and integrity protection, and it's the layer that wraps up all the higher-level protocols.
The handshaking protocols are three subprotocols: the handshake protocol, the change cipher spec protocol, and the alert protocol. The handshake protocol is the main event 💖. It lets the server and client authenticate each other and negotiate an encryption algorithm and cryptographic keys before the application protocol sends or receives any data.
DTLS [RFC6347] is basically TLS's twin 🦋, and it's intentionally very similar in design. But DTLS runs on an unreliable datagram transport, so it has to cope with the fact that TLS assumed reliable, ordered delivery. RFC 6347 explains all of this in great detail (it's the full tea ☕). Here's the short version for anyone who isn't familiar with DTLS. The differences are:
- An explicit sequence number and an epoch field are included in the Record Protocol. Section 4.1 of RFC 6347 explains the processing rules for these two new fields. The value used to compute the Message Authentication Code (MAC) is the 64-bit value formed by concatenating the epoch and the sequence number.
- Stream ciphers must not be used with DTLS 🙅♀️. The only stream cipher defined for TLS 1.2 is RC4, and due to cryptographic weaknesses, it is not recommended anymore even for use with TLS [RFC7465]. Note that "stream cipher" is a technical term in the TLS specification. Section 4.7 of RFC 5246 defines stream ciphers in TLS as follows: "In stream cipher encryption, the plaintext is exclusive-ORed with an identical amount of output generated from a cryptographically secure keyed pseudorandom number generator."
- The TLS handshake protocol has been enhanced to include a stateless cookie exchange for Denial-of-Service (DoS) resistance 🛡️. For this purpose, a new handshake message, the HelloVerifyRequest, was added to DTLS. This handshake message is sent by the server and includes a stateless cookie, which is returned in a ClientHello message back to the server. Although the exchange is optional for the server to execute, a client implementation has to be prepared to respond to it. Furthermore, the handshake message format has been extended to deal with message loss, reordering, and fragmentation.
3.2. Communication Models 🌸
This document describes a profile of DTLS and, to be useful, it has to make assumptions about the envisioned communication architecture.
Two communication architectures (and consequently two profiles) are described in this document. ✨
3.2.1. Constrained TLS/DTLS Clients 🧚
The communication architecture shown in Figure 1 assumes a unicast communication interaction with an IoT device utilizing a constrained TLS/DTLS client interacting with one or multiple TLS/DTLS servers. Think of it as one tiny device chatting with one or more servers, and it's iconic 🤖.
Before a client can initiate the TLS/DTLS handshake, it needs to know the IP address of that server and what credentials to use. Application-layer protocols, such as CoAP, which is conveyed on top of DTLS, may be configured with URIs of the endpoints to which CoAP needs to register and publish data. This configuration information (including non-confidential credentials, like certificates) may be conveyed to clients as part of a firmware/software package or via a configuration protocol. The following credential types are supported by this profile:
- For authentication based on the Pre-Shared Key (PSK) (see Section 4.2), this includes the paired "PSK identity" and shared secret to be used with each server. 🔑
- For authentication based on the raw public key (see Section 4.3), this includes either the server's public key or the hash of the server's public key. 🍓
- For certificate-based authentication (see Section 4.4), this includes a pre-populated trust anchor store that allows the DTLS stack to perform path validation for the certificate obtained during the handshake with the server. 📜
Figure 1 shows example configuration information stored at the constrained client for use with respective servers. Look at this little setup, it's so organized 🥹.
This document focuses on the description of the DTLS client-side functionality but, quite naturally, the equivalent server-side support has to be available.
+////////////////////////////////////+
| Configuration |
|////////////////////////////////////|
| Server A --> PSK Identity, PSK |
| |
| Server B --> Public Key (Server B),|
| Public/Private Key |
| (for Client) |
| |
| Server C --> Public/Private Key |
| (for Client) |
| Trust Anchor Store |
+------------------------------------+
oo
oooooo
o
+-----------+
|Constrained|
|TLS/DTLS |
|Client |-
+-----------+ \
\ ,-------.
,' `. +------+
/ IP-Based \ |Server|
( Network ) | A |
\ / +------+
`. ,'
'---+---' +------+
| |Server|
| | B |
| +------+
|
| +------+
+----------------->|Server|
| C |
+------+
Figure 1: Constrained Client Profile3.2.1.1. Examples of Constrained Client Exchanges 🦋
3.2.1.1.1. Network Access Authentication Example ✨
Okay bestie, reuse is literally the main theme in constrained environments 💖 and it's behind so many of the design choices. The big rule is: don't add new functionality if you can avoid it 🧚 A good example is network access authentication 🔐 This happens when a device joins a network and has to get through authentication and access control before it can talk to other devices or reach the Internet.
Figure 2 shows the network access architecture 🦋 The IoT device starts the communication with an access point, using the procedures for a specific physical layer. Credentials are often managed and stored centrally in the Authentication, Authorization, and Accounting (AAA) server, so the security protocol exchange may need to be relayed through the Authenticator, which is the functionality running on the access point that talks to the AAA server 🌸 The authentication and key exchange protocol lives inside a container called the Extensible Authentication Protocol (EAP) [RFC3748]. Messages go back and forth between the EAP endpoints: the EAP peer on the IoT device, and the EAP server, which is on the AAA server or the access point 💜 To get EAP messages from the access point (acting as an AAA client) to the AAA server, you need a proper protocol mechanism, either RADIUS [RFC2865] or Diameter [RFC6733] 👑
If you want more background and the terminology, check out RFC 5247 [RFC5247] 📚
+--------------+
|Authentication|
|Authorization |
|Accounting |
|Server |
|(EAP Server) |
| |
+-^----------^-+
* EAP o RADIUS/
* o Diameter
--v----------v--
/// \\\
// \\
| Federation |
| Substrate |
\\ //
\\\ ///
--^----------^--
* EAP o RADIUS/
* o Diameter
+-------------+ +-v----------v--+
| | EAP/EAP Method | |
| Internet of |<***************************>| Access Point |
| Things | |(Authenticator)|
| Device | EAP Lower Layer and |(AAA Client) |
| (EAP Peer) | Secure Association Protocol | |
| |<--------------------------->| |
| | | |
| | Physical Layer | |
| |<===========================>| |
+-------------+ +---------------+
Legend:
<****>: Device-to-AAA-Server Exchange
<---->: Device-to-Authenticator Exchange
<oooo>: AAA-Client-to-AAA-Server Exchange
<====>: Physical layer like IEEE 802.11/802.15.4
Figure 2: Network Access ArchitectureOne standardized EAP method is EAP-TLS, defined in RFC 5216 [RFC5216] 🎀 It reuses the TLS-based protocol exchange and wraps it inside the EAP payload. This is the reuse magic, because lots of TLS components can be shared between the network access security functionality and the TLS functionality used to secure application-layer traffic 🫶 In the EAP-TLS exchange in Figure 3, the IoT device, as the EAP peer, acts as a TLS client 🥹
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Success
Figure 3: EAP-TLS ExchangeThe guidance in this document also applies to EAP-TLS used for network access authentication 🌈 An IoT device that uses a TLS-based network access authentication solution can reuse most of the code it already has for DTLS/TLS at the application layer, which saves a significant amount of flash memory 💅 Just note, though, that the credentials for network access authentication and the ones for application-layer security are very likely different 🙈
That's the reuse glow-up we love to see ✨
3.2.1.1.2. CoAP-Based Data Exchange Example 🦋
okay so, when a constrained client uploads sensor data to a server setup, it can use CoAP and just POST the data to a preconfigured endpoint on the server 📮 that's the simple version. but sometimes that's too limiting, and you need more functionality. that's where Figures 4 and 5 come in 💅 the IoT device runs its own CoAP server and hosts a resource that other entities can access. even with a CoAP server running on the device, the DTLS client on the IoT device is still the one that starts the interaction with the non-constrained resource server in this scenario 🔐
Figure 4 shows a sensor kicking off a DTLS exchange with a resource directory, and then Figure 5 shows it using CoAP to register its available resources 🌸 [CoRE-RD] describes the resource directory (RD) as a web entity that stores information about web resources and offers Representational State Transfer (REST) interfaces for registering and looking up those resources. ngl the exchange shown here is borrowed from the Open Mobile Alliance (OMA) Lightweight Machine-to-Machine (LWM2M) specification [LWM2M], which uses an RD but also adds proxy functionality ✨
the first DTLS interaction, between the sensor acting as a DTLS client and the resource directory acting as a DTLS server, is going to be a full DTLS handshake 🤝 once that handshake is done, both parties have set up the DTLS record layer. after that, the CoAP client can register at the resource directory securely 🔒
after some time has passed (assuming the client keeps refreshing its registration), the resource directory gets a request from an application asking for the temperature info from the sensor 🌡️ the resource directory relays that request to the sensor with a GET message exchange. the DTLS record layer that's already set up can be used to secure this message exchange, so no need to start over 🦋
Resource
Sensor Directory
------ ---------
+---
|
| ClientHello -------->
| #client_certificate_type#
F| #server_certificate_type#
U|
L| <------- HelloVerifyRequest
L|
| ClientHello -------->
D| #client_certificate_type#
T| #server_certificate_type#
L|
S| ServerHello
| #client_certificate_type#
H| #server_certificate_type#
A| Certificate
N| ServerKeyExchange
D| CertificateRequest
S| <-------- ServerHelloDone
H|
A| Certificate
K| ClientKeyExchange
E| CertificateVerify
| [ChangeCipherSpec]
| Finished -------->
|
| [ChangeCipherSpec]
| <-------- Finished
+---
Note: Extensions marked with "#" were introduced with
RFC 7250.
Figure 4: DTLS/CoAP Exchange Using Resource Directory:
Part 1 -- DTLS HandshakeFigure 5 shows the DTLS-secured communication between the sensor and the resource directory using CoAP 💜
Resource
Sensor Directory
------ ---------
[[==============DTLS-Secured Communication===================]]
+--- ///+
C| \ D
O| Req: POST coap://rd.example.com/rd?ep=node1 \ T
A| Payload: \ L
P| </temp>;ct=41; \ S
| rt="temperature-c";if="sensor", \
R| </light>;ct=41; \ R
D| rt="light-lux";if="sensor" \ E
| --------> \ C
R| \ O
E| \ R
G| Res: 2.01 Created \ D
| <-------- Location: /rd/4521 \
| \ L
+--- \ A
\ Y
* \ E
* (time passes) \ R
* \
+--- \ P
C| \ R
O| Req: GET coaps://sensor.example.com/temp \ O
A| <-------- \ T
P| \ E
| Res: 2.05 Content \ C
G| Payload: \ T
E| 25.5 --------> \ E
T| \ D
+--- ///+
Figure 5: DTLS/CoAP Exchange Using Resource Directory:
Part 2 -- CoAP/RD Exchangeand the bit to remember: the CoAP GET message sent from the resource server is protected using the DTLS record layer that was already established 🔐✨
3.2.2. Constrained TLS/DTLS Servers 🖥️
okay so 3.2.1 was all about the TLS/DTLS client being the constrained one 🥹. Now we flip it! This section pictures constrained devices running TLS/DTLS servers to lock down access to application-layer services on top of CoAP, HTTP, or other protocols 💅. Figure 6 shows a setup where a bunch of constrained servers are chillin', waiting for regular clients to come knock. The whole thing is likely (but not necessarily!) run by a third party: the authentication and authorization server. That server holds the authorization policies that decide who gets access to what, and it handles distributing the keying material 🔑.
+////////////////////////////////////+
| Configuration |
|////////////////////////////////////|
| Credentials |
| Client A -> Public Key |
| Server S1 -> Symmetric Key |
| Server S2 -> Certificate |
| Server S3 -> Public Key |
| Trust Anchor Store |
| Access Control Lists |
| Resource X: Client A / GET |
| Resource Y: Client A / PUT |
+------------------------------------+
oo
oooooo
o
+---------------+ +-----------+
|Authentication | +-------->|TLS/DTLS |
|& Authorization| | |Client A |
|Server | | +-----------+
+---------------+ ++
^ | +-----------+
\ | |Constrained|
\ ,-------. | Server S1 |
,' `. +-----------+
/ Local \
( Network )
\ / +-----------+
`. ,' |Constrained|
'---+---' | Server S2 |
| +-----------+
|
| +-----------+
+-----------------> |Constrained|
| Server S3 |
+-----------+Figure 6: Constrained Server Profile
A deployment with constrained servers has to overcome several challenges 😤. Below we explain how these challenges can be solved with CoAP, as an example. Other protocols may offer similar capabilities. While the requirements for the TLS/DTLS protocol profile change only slightly when run on a constrained server (compared to running it on a constrained client), several other ecosystem factors will impact deployment.
There are several challenges that need to be addressed:
Discovery and Reachability:
A client must first and foremost discover the server before initiating a connection to it ✨. Once it has been discovered, reachability to the device needs to be maintained.
In CoAP, the discovery of resources offered by servers is accomplished by sending a unicast or multicast CoAP GET to a well-known URI. The Constrained RESTful Environments (CoRE) Link Format specification [RFC6690] describes the use case (see Section 1.2.1) and reserves the URI (see Section 7.1). Section 7 of the CoAP specification [RFC7252] describes the discovery procedure. [RFC7390] describes the use case for discovering CoAP servers using multicast (see Section 3.3) and specifies the protocol processing rules for CoAP group communications (see Section 2.7) 🌸.
The use of RD [CoRE-RD] is yet another possibility for discovering registered servers and their resources. Since RD is usually not a proxy, clients can discover links registered with the RD and then access them directly 🦋.
Authentication:
The next challenge concerns the provisioning of authentication credentials to the clients as well as servers 🔐. In Section 3.2.1, we assume that credentials (and other configuration information) are provisioned to the device, and that those can be used with the authorization servers. Of course, this leads to a very static relationship between the clients and their server-side infrastructure, but it poses fewer challenges from a deployment point of view, as described in Section 2 of [RFC7452]. In any case, engineers and product designers have to determine how the relevant credentials are distributed to the respective parties. For example, shared secrets may need to be provisioned to clients and the constrained servers for subsequent use of TLS/DTLS PSK. In other deployments, certificates, private keys, and trust anchors for use with certificate-based authentication may need to be utilized.
Practical solutions use either pairing (also called imprinting) or a trusted third party. With pairing, two devices execute a special protocol exchange that is unauthenticated to establish a shared key (for example, using an unauthenticated Diffie-Hellman (DH) exchange). To avoid man-in-the-middle attacks, an out-of-band channel is used to verify that nobody has tampered with the exchanged protocol messages. This out-of-band channel can come in many forms, including:
- Human involvement by comparing hashed keys, entering passkeys, and scanning QR codes
- The use of alternative wireless communication channels (e.g., infrared communication in addition to Wi-Fi)
- Proximity-based information
More details about these different pairing/imprinting techniques can be found in the Smart Object Security Workshop report [RFC7397] and various position papers submitted on that topic, such as [ImprintingSurvey]. The use of a trusted third party follows a different approach and is subject to ongoing standardization efforts in the Authentication and Authorization for Constrained Environments (ACE) working group [ACE-WG] 🧚.
Authorization:
The last challenge is the ability for the constrained server to make an authorization decision when clients access protected resources. Pre-provisioning access control information to constrained servers may be one option, but it works only in a small-scale, less dynamic environment. For a finer-grained and more dynamic access control solution, the reader is referred to the ongoing work in the IETF ACE working group 👑.
Figure 7 shows an example interaction where a device, a thermostat in our case, searches the local network for discoverable resources and accesses those 🌡️. The thermostat starts the procedure using a link-local discovery message using the "All CoAP Nodes" multicast address by utilizing the link format per RFC 6690 [RFC6690]. The IPv6 multicast address used for CoAP link-local discovery is FF02::FD. As a result, a temperature sensor and a fan respond. These responses allow the thermostat to subsequently read temperature information from the temperature sensor with a CoAP GET request issued to the previously learned endpoint. In this example, we assume that accessing the temperature sensor readings and controlling the fan requires authentication and authorization of the thermostat, and that TLS is used to authenticate both endpoints and to secure the communication 💜.
Temperature
Thermostat Sensor Fan
---------- --------- ---
Discovery
-------------------->
GET coap://[FF02::FD]/.well-known/core
CoAP 2.05 Content
<-------------------------------
</3303/0/5700>;rt="temperature";
if="sensor"
CoAP 2.05 Content
<--------------------------------------------------
</fan>;rt="fan";if="actuation"
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
\ Protocol steps to obtain access token or keying /
\ material for access to the temperature sensor and fan. /
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Read Sensor Data
(authenticated/authorized)
------------------------------->
GET /3303/0/5700
CoAP 2.05 Content
<-------------------------------
22.5 C
Configure Actuator
(authenticated/authorized)
------------------------------------------------->
PUT /fan?on-off=true
CoAP 2.04 Changed
<-------------------------------------------------Figure 7: Local Discovery and Resource Access
the thermostat really said "discover, authenticate, then touch the fan" and I'm obsessed 🌈😭
3.3. The Ciphersuite Concept 🎀
Okay so TLS (and therefore DTLS 🫶) supports ciphersuites, and there's an IANA registry [IANA-TLS] that was made to register all of them 📋. A ciphersuite, plus the spec that defines it, packs in the following info:
- Authentication and key exchange algorithm (e.g., PSK) 🔑
- Cipher and key length (e.g., Advanced Encryption Standard (AES) with 128-bit keys [AES]) 🔐
- Mode of operation (e.g., Counter with CBC-MAC (CCM) mode for AES) [RFC3610] 🌀
- Hash algorithm for integrity protection, such as the Secure Hash Algorithm (SHA) in combination with Keyed-Hashing for Message Authentication (HMAC) (see [RFC2104] and [RFC6234]) 🧾
- Hash algorithm for use with pseudorandom functions (e.g., HMAC with the SHA-256) 🎲
- Misc information (e.g., length of authentication tags) ✨
- Information whether the ciphersuite is suitable for DTLS or only for TLS 🦋
The TLS ciphersuite TLS_PSK_WITH_AES_128_CCM_8, for example, uses a pre-shared authentication and key exchange algorithm. [RFC6655] defines this ciphersuite 💜. It uses the AES encryption algorithm, which is a block cipher. AES supports different key lengths (such as 128, 192, and 256 bits), so that info has to be specified too, and this particular suite uses 128-bit keys 🔑. A block cipher encrypts plaintext in fixed-size blocks, and AES works on a block size of 128 bits 🧱. For messages longer than 128 bits, the message gets chopped into 128-bit blocks, and the AES cipher is applied to those input blocks with appropriate chaining. That chaining is called the mode of operation 🔗.
TLS 1.2 introduced Authenticated Encryption with Associated Data (AEAD) ciphersuites (see [RFC5116] and [RFC6655]) 🌟. AEAD is a class of block cipher modes that encrypt (parts of) the message and authenticate the message at the same time 🤯. AES-CCM [RFC6655] is an example of one of these modes.
Some AEAD ciphersuites have shorter authentication tags (i.e., message authentication codes), which makes them a better fit for low-bandwidth networks where small message size matters 🐣. The TLS_PSK_WITH_AES_128_CCM_8 ciphersuite, the one that ends in _8, has an 8-octet authentication tag. The regular CCM ciphersuites have, at the time of writing, 16-octet authentication tags 📏. The design of CCM and its security properties are described in [CCM] 📖.
TLS 1.2 also replaced the combination of MD5/SHA-1 hash functions in the TLS pseudorandom function (PRF) that earlier versions of TLS used with ciphersuite-specified PRFs. Because of this, authors of newer TLS 1.2 ciphersuite specs explicitly say which MAC algorithm and which hash functions are used with the TLS PRF 🧐.
4. Credential Types 🗝️
The mandatory-to-implement functionality depends on which credential type you use with your IoT devices 💅. The subsections below cover the implications of three credential types: pre-shared secrets, raw public keys, and certificates 🌸.
4.1. Preconditions 🧁
Every exchange described in the upcoming sections assumes that some information was distributed before the TLS/DTLS interaction starts 📦. The credentials are used to authenticate the client to the server, and vice versa 🤝. Which information items need to be distributed depends on the credential types you pick 🎀. In all cases, the IoT device needs to know which algorithms to prefer, especially if the implemented ciphersuites give it multiple algorithm choices. It also needs info about the other communication endpoint (for example, in the form of a URI) that a particular credential has to be used with 🌐.
- Pre-Shared Secrets: a shared secret together with an identifier needs to be made available to the device as well as to the other communication party 🤫.
- Raw Public Keys: a public key and a private key are stored on the device and are typically associated with some identifier 🔏. To authenticate the other communication party, the matching credential has to be known. If the other end uses raw public keys as well, then its public key needs to be provisioned (out of band) to the device 📬.
- Certificates: using certificates requires the device to store the public key (as part of the certificate) as well as the private key 📜. The certificate contains the identifier of the device plus various other attributes 🪪. Both communication parties are assumed to have a trust anchor store that contains CA certificates and, in the case of certificate pinning, end-entity certificates 🏰. Just like with the other credentials, the IoT device needs info about which entity to use which certificate with. Without a trust anchor store on the IoT device, certificate validation just won't be possible 💀.
We call all of the above "device credentials" 🏷️. These device credentials may be provisioned to the device already during manufacturing, or later in the process, depending on the envisioned business and deployment model 🏭. These initial credentials are often called "root of trust" 👑. Whatever process you choose for generating these initial device credentials, it MUST be ensured that a different key pair is provisioned for each device, installed in as secure a manner as possible 🔒. For example, it is preferable to generate public/private keys on the IoT device itself rather than generating them outside the device 🧚. Since an IoT device is likely to interact with various other parties, the initial device credential may only be used with some dedicated entities. Configuring further configuration and credentials to the device is left to a separate interaction 🫧. An example of a dedicated protocol for distributing credentials, access control lists, and configuration info is the LWM2M protocol [LWM2M] 💌.
For all the credentials listed above, there's a chance they'll need to be replaced or deleted 🔄. Separate protocols have been developed to check the status of these credentials and to manage them, such as the Trust Anchor Management Protocol (TAMP) [RFC5934] 📋. Their usage, however, is not envisioned in the IoT context so far 🙃. IoT devices are assumed to have a software update mechanism built in, and it allows updates of low-level device info, including credentials and configuration parameters ⚙️. This document does not mandate a specific software/firmware update protocol, though 🤷♀️.
With all credentials used as input to TLS/DTLS authentication, it's important that they were generated with care 🥹. When using a pre-shared secret, a critical consideration is using sufficient entropy during key generation, as discussed in [RFC4086] 🎲. Deriving a shared secret from a password, some device identifiers, or other low-entropy sources is not secure 🙅♀️. A low-entropy secret, or password, is subject to dictionary attacks 😱. Attention also has to be paid when generating public/private key pairs, because a lack of randomness can result in the same key pair being used on many devices 🥶. This topic is also discussed in Section 12, since keys are generated during the TLS/DTLS exchange itself too, and the same considerations apply 🔥.
4.2. Pre-Shared Secret 🔑
okay so pre-shared secrets are literally one of the most basic moves in TLS/DTLS 💖 they're computationally efficient AND bandwidth conserving, which is so on-brand for constrained devices. Authentication based on pre-shared secrets was introduced to TLS in RFC 4279 [RFC4279] 🎀
Figure 8 shows the DTLS exchange with the cookie exchange built in. The server doesn't have to start a cookie exchange with every single handshake, but the client is required to implement it and react to it when challenged, as defined in RFC 6347 [RFC6347] 🍓 The cookie exchange lets the server react to flooding attacks 🛡️
Client Server
------ ------
ClientHello -------->
<-------- HelloVerifyRequest
(contains cookie)
ClientHello -------->
(with cookie)
ServerHello
*ServerKeyExchange
<-------- ServerHelloDone
ClientKeyExchange
ChangeCipherSpec
Finished -------->
ChangeCipherSpec
<-------- Finished
Application Data <-------> Application DataLegend: * indicates an optional message payload
Figure 8: DTLS PSK Authentication Including the Cookie Exchange
Note that [RFC4279] used the term "PSK identity" to refer to the identifier used to point at the right secret. ✨ "Identifier" would honestly be the better word here, but we reuse the terminology from RFC 4279 to avoid confusion. RFC 4279 doesn't mandate any particular type of PSK identity, so the client and server have to agree on the identities and keys to be used. 🤝
The UTF-8 encoding of identities described in Section 5.1 of RFC 4279 is there to improve interoperability when a human configures the identity through a management interface in a web browser. But plenty of IoT devices have no user interface at all, and most of their credentials are bound to the device rather than to a user. Credentials are also often provisioned into hardware modules or alongside the firmware. So the encoding considerations just don't apply to this environment 🙈
For use with this profile, the PSK identities SHOULD NOT assume a structured format (such as domain names, distinguished names, or IP addresses), and a byte-by-byte comparison operation MUST be used by the server for any operation related to the PSK identity. These types of identifiers are called "absolute" per RFC 6943 [RFC6943]. 💅
Protocol-wise, the client indicates which key it uses by including a "PSK identity" in the ClientKeyExchange message. As described in Section 3.2, clients may have multiple pre-shared keys with a single server, for example in a hosting context. The TLS Server Name Indication (SNI) extension lets the client say which server it's contacting, and a server implementation needs to guide its selection based on the SNI value it receives from the client. 👑
RFC 4279 requires TLS implementations that support PSK ciphersuites to support arbitrary PSK identities up to 128 octets in length and arbitrary PSKs up to 64 octets in length. That's a useful assumption for TLS stacks on desktop and mobile, where management interfaces are used to provision identities and keys. Implementations in compliance with this profile MAY use PSK identities up to 128 octets in length and arbitrary PSKs up to 64 octets in length. The use of shorter PSK identities is RECOMMENDED. 🌸
"The Constrained Application Protocol (CoAP)" [RFC7252] currently specifies TLS_PSK_WITH_AES_128_CCM_8 as the mandatory-to-implement ciphersuite for use with shared secrets. This ciphersuite uses the AES algorithm with 128-bit keys and CCM as the mode of operation. The label "_8" means an 8-octet authentication tag is used. ⚠️ Heads up: the shorter authentication tag increases the chance that an adversary with no knowledge of the secret key can present a message with a MAC that passes the verification procedure. The likelihood of accepting forged data is explained in Section 5.3.5 of [SP800-107-rev1], and it depends on the lengths of the authentication tag and the allowed numbers of MAC verifications using a given key. 🥺
This ciphersuite makes use of the default TLS 1.2 PRF, which uses an HMAC with the SHA-256 hash function. Note: starting with TLS 1.2 (and consequently DTLS 1.2), ciphersuites have to specify the PRF. RFC 5246 states that "New cipher suites MUST explicitly specify a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function." The ciphersuites recommended in this document use the SHA-256 construct defined in Section 5 of RFC 5246. 🦋
A device compliant with the profile in this section MUST implement TLS_PSK_WITH_AES_128_CCM_8 and follow the guidance from this section. ✨
4.3. Raw Public Key 🦋
The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is the first entry point into public key cryptography without having to pay the price of certificates and a public key infrastructure (PKI). 🧚 The specification reuses the existing Certificate message to convey the raw public key encoded in the SubjectPublicKeyInfo structure. To indicate support, two new extensions had been defined, as shown in Figure 9: the server_certificate_type and the client_certificate_type.
Client Server
------ ------
ClientHello -------->
#client_certificate_type#
#server_certificate_type#
ServerHello
#client_certificate_type#
#server_certificate_type#
Certificate
ServerKeyExchange
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- FinishedNote: Extensions marked with "#" were introduced with RFC 7250.
Figure 9: DTLS Raw Public Key Exchange
The CoAP-recommended ciphersuite for this credential type is TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This AES-CCM TLS ciphersuite is based on elliptic curve cryptography (ECC). It uses Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) as the key establishment mechanism and the Elliptic Curve Digital Signature Algorithm (ECDSA) for authentication. The named DH groups [FFDHE-TLS] are not applicable to this profile, since it relies on the ECC-based counterparts. ✨ This ciphersuite makes use of the AEAD capability in DTLS 1.2 and utilizes an 8-octet authentication tag. The use of a DH key exchange provides perfect forward secrecy (PFS). More details about PFS can be found in Section 9. 🔥
[RFC6090] provides valuable info for implementing ECC algorithms, especially for choosing methods that have been around in the literature for a long time (i.e., 20 years and more). 📚
A device compliant with the profile in this section MUST implement TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this section. 💜
4.4. Certificates 💅
The use of mutual certificate-based authentication is shown in Figure 10, which makes use of the "cached_info" extension [RFC7924]. Support of the "cached_info" extension is REQUIRED. Caching certificate chains lets the client cut down communication overhead significantly. Otherwise, the server would have to send the end-entity certificate and the certificate chain with every full DTLS handshake. 🌈
Client Server
------ ------
ClientHello -------->
*cached_info*
ServerHello
*cached_info*
Certificate
ServerKeyExchange
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- FinishedNote: Extensions marked with "*" were introduced with RFC 7924.
Figure 10: DTLS Mutual Certificate-Based Authentication
TLS/DTLS offers a lot of choices when selecting ECC-based ciphersuites. This document restricts the use to named curves defined in RFC 4492 [RFC4492]. At the time of writing, the recommended curve is secp256r1, and the use of uncompressed points follows the recommendation in CoAP. 🧠 Standardization for Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for this curve will likely be required in the future. 👀
A device compliant with the profile in this section MUST implement TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this section. 🫶
4.4.1. Certificates Used by Servers 🎀
Okay so, the algorithm for checking the service identity from RFC 6125 [RFC6125] is literally essential for staying secure when certificates are involved. 🔐 Here's the quick recap of the steps:
- The client builds a list of acceptable reference identifiers based on the source domain and, optionally, the type of service it's connecting to.
- The server gives its identifiers in the form of a PKIX certificate.
- The client checks each of its reference identifiers against the presented identifiers to find a match.
- When checking a reference identifier against a presented identifier, the client matches the source domain of the identifiers and, optionally, their application service type.
For the terms used in the algorithm above, go check out RFC 6125. It's super important that comparing the reference identifier against the presented identifier from the certificate is required so the client knows it's talking to the intended server. 💅✨
Also, the algorithm and the text in RFC 6125 assume that fully qualified DNS domain names are in use. 🌐 If a server node is provisioned with a fully qualified DNS domain, then the server certificate MUST contain the fully qualified DNS domain name or "FQDN" as dNSName [RFC5280]. For CoAP, the coaps URI scheme is described in Section 6.2 of [RFC7252]. This FQDN is stored in the SubjectAltName or in the leftmost Common Name (CN) component of the subject name, as explained in Section 9.1.3.3 of [RFC7252]. The client then uses it to match against the FQDN used during the lookup process, as described in [RFC6125]. For other protocols, you have to consult the appropriate URI scheme specification. 📖
Here's the recommendation, bestie 🫶:
- Certificates MUST NOT use DNS domain names in the CN of certificates and instead use the
subjectAltNameattribute, as described in the previous paragraph. - Certificates MUST NOT contain domain names with wildcard characters.
- Certificates MUST NOT contain multiple names (e.g., more than one
dNSNamefield).
Now, not every server is set up with DNS domain names. Think IoT devices that offer resources to nearby devices on a local network, like the one in Figure 7. 🧚 For these constrained servers, the use of certificates as described in Section 4.4.2 applies. Heads up though: the SNI extension can't be used here, because SNI doesn't let you convey a 64-bit Extended Unique Identifier (EUI-64) [EUI64]. 🙈 And this document doesn't recommend using IP addresses in certificates, nor does it discuss what happens when you put IP addresses in certificates. Just so you know. 🌸
4.4.2. Certificates Used by Clients 🦋
For client certificates, the identifier used in the SubjectAltName or in the leftmost CN component of the subject name MUST be an EUI-64. 💜
4.4.3. Certificate Revocation 🍓
For certificate revocation, neither the Online Certificate Status Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. Instead, this profile relies on a software update mechanism to provision information about revoked certificates. 🔄 Multiple OCSP stapling [RFC6961] has recently been introduced as a way to piggyback OCSP request/responses inside the DTLS/TLS handshake, so you don't have to pay for a separate protocol handshake. Still, more investigation is needed to figure out whether it's suitable for the IoT environment. 🤔
As mentioned earlier in this section, changes to the trust anchor store also depend on a software update mechanism. Ngl, that comes with limits, because certain types of keys might be impossible to change, such as those provisioned during manufacturing. 😬 For this reason, manufacturer-provisioned credentials are typically used only to get further certificates (for example, through a key distribution server) for the servers the IoT device is actually communicating with. 🔑
4.4.4. Certificate Content 👑
All certificate elements listed in Table 1 MUST be implemented by clients and servers that claim support for certificate-based authentication. No other certificate elements are used by this specification. ✨
When using certificates, IoT devices MUST provide support for a server certificate chain of at least 3, not including the trust anchor. They MAY reject connections from servers offering chains longer than 3. IoT devices MAY have client certificate chains of any length. Obviously, longer chains need more digital signature verification operations and lead to larger certificate messages in the TLS handshake. 🙃
Here's the summary of the elements in a certificate for this profile, bestie:
+----------------------+--------------------------------------------+
| Element | Notes |
+----------------------+--------------------------------------------+
| version | This profile uses X.509 v3 certificates |
| | [RFC5280]. |
| | |
| serialNumber | Positive integer unique per certificate. |
| | |
| signature | This field contains the signature |
| | algorithm, and this profile uses ecdsa- |
| | with-SHA256 or stronger [RFC5758]. |
| | |
| issuer | Contains the DN of the issuing CA. |
| | |
| validity | Values expressed as UTC time in notBefore |
| | and notAfter fields. No validity period |
| | mandated. |
| | |
| subject | See rules outlined in this section. |
| | |
| subjectPublicKeyInfo | The SubjectPublicKeyInfo structure |
| | indicates the algorithm and any associated |
| | parameters for the ECC public key. This |
| | profile uses the id-ecPublicKey algorithm |
| | identifier for ECDSA signature keys, as |
| | defined and specified in [RFC5480]. |
| | |
| signatureAlgorithm | The ECDSA signature algorithm with ecdsa- |
| | with-SHA256 or stronger. |
| | |
| signatureValue | Bit string containing the digital |
| | signature. |
| | |
| Extension: | See rules outlined in this section. |
| subjectAltName | |
| | |
| Extension: | Indicates whether the subject of the |
| BasicConstraints | certificate is a CA and the maximum depth |
| | of valid certification paths that include |
| | this certificate. This extension is used |
| | for CA certs only, and then the value of |
| | the "cA" field is set to TRUE. The |
| | default is FALSE. |
| | |
| Extension: Key Usage | The KeyUsage field MAY have the following |
| | values in the context of this profile: |
| | digitalSignature or keyAgreement, |
| | keyCertSign for verifying signatures on |
| | public key certificates. |
| | |
| Extension: Extended | The ExtKeyUsageSyntax field MAY have the |
| Key Usage | following values in context of this |
| | profile: id-kp-serverAuth for server |
| | authentication, id-kp-clientAuth for |
| | client authentication, id-kp-codeSigning |
| | for code signing (for software update |
| | mechanism), and id-kp-OCSPSigning for |
| | future OCSP usage in TLS. |
+----------------------+--------------------------------------------+
Table 1: Certificate ContentOkay, so as the table shows, certificates are signed using ECDSA in this profile. 🔏 That's true for the end-entity certificates and for every other certificate in the chain, including CA certificates. The point is that fewer algorithm options means less flash memory is needed on an IoT device to store the code for several algorithm implementations. 💾 The algorithms that can sign digital certificates include RSA, the Digital Signature Algorithm (DSA), and ECDSA, so this narrowing is a big deal. 🧠
Further details about X.509 certificates can be found in Section 9.1.3.3 of [RFC7252]. 📚
4.4.5. Client Certificate URLs 🌈
RFC 6066 [RFC6066] lets you avoid sending client-side certificates and uses URLs instead, which reduces over-the-air transmission. 📡 Note that the TLS "cached_info" extension doesn't help with caching client certificates at all. 🙅♀️
TLS/DTLS clients MUST implement support for client certificate URLs for those environments where client-side certificates are used and the server side is not constrained. For constrained servers, this functionality is NOT RECOMMENDED, since it forces the server to execute an additional protocol exchange, potentially using a protocol it doesn't even support. 😵 The use of this extension also increases the risk of a DoS attack against the constrained server because of the extra workload. 🚨
4.4.6. Trusted CA Indication 💖
RFC 6066 [RFC6066] lets clients indicate which trust anchor they support. With certificate-based authentication, a DTLS server sends its end-entity certificate to the client during the DTLS handshake. The server doesn't necessarily know what trust anchors the client has stored, so to help with certification path construction and validation, it includes intermediate CA certs in the certificate payload. 🧩
Today, most IoT deployments have a pretty static relationship between the IoT device (and the software running on it) and the server-side infrastructure. 🏠 For these deployments, where IoT devices interact with a fixed, preconfigured set of servers, this extension is NOT RECOMMENDED. ⭐
In cases where clients interact with dynamically discovered TLS/DTLS servers, for example in the use cases described in Section 3.2.2, the use of this extension is RECOMMENDED. 🦄✨
5. Signature Algorithm Extension ✨
okay so the signature_algorithms extension (defined in Section 7.4.1.4.1 of RFC 5246 [RFC5246]) is how the client tells the server which signature/hash algorithm pairs it's down to use for digital signatures 💅. The client MUST send this extension to select the use of SHA-256 🔐. If the extension is absent, RFC 5246 defaults to SHA-1 / ECDSA for the ECDH_ECDSA and ECDHE_ECDSA key exchange algorithms, and that's giving very different energy 💀.
The signature_algorithms extension is not applicable to the PSK-based ciphersuite described in Section 4.2. 🙈
6. Error Handling 🚨
bestie, TLS/DTLS uses the alert protocol to send errors and there's a long list of error types 📜. Not all of them apply to this profile though, so don't stress. There are two categories of errors (as defined in Section 7.2 of RFC 5246), which are fatal errors and warnings ⚠️. Alerts with a level of "fatal" immediately end the connection 🛑. If possible, developers should try to come up with strategies to react to those fatal errors, like restarting the handshake or telling the user through the (often limited) user interface 🫶. Warnings can be ignored by the application, since lots of IoT devices have either limited ways to log errors or no ability at all 🤖. Either way, implementers have to carefully figure out the impact of errors and how to fix the situation, because the usual approach of letting users make the call is hard (or impossible) to pull off in a timely way ⏰.
Every error message marked as RESERVED is only there for backwards compatibility with the Secure Socket Layer (SSL), so they MUST NOT be used with this profile 🙅♀️. That includes decryption_failed_RESERVED, no_certificate_RESERVED, and export_restriction_RESERVED.
A bunch of the error messages MUST only be used for certificate-based ciphersuites 📄. So the following error messages MUST NOT be used with PSK and raw public key authentication:
bad_certificate,unsupported_certificate,certificate_revoked,certificate_expired,certificate_unknown,unknown_ca, andaccess_denied.
This profile doesn't use compression at the TLS layer, so the decompression_failure error message MUST NOT be used either 🙃.
RFC 4279 introduced the new alert message unknown_psk_identity for PSK ciphersuites. As Section 2 of RFC 4279 says, the decrypt_error error message may also be used instead. For this profile, the TLS server MUST return the decrypt_error error message instead of unknown_psk_identity, since the two mechanisms exist and do the same job 🔁.
Also, the following errors shouldn't happen with devices and servers that support this specification, but implementations MUST be prepared to process them anyway, for dealing with servers that aren't compliant with the profiles in this document 🧐:
protocol_version: While this document only focuses on one version of the TLS/DTLS protocol, namely version 1.2, ongoing work on TLS/DTLS 1.3 is in progress at the time of writing 🔮.insufficient_security: This error message means the server wants ciphers that are more secure. This document only specifies one ciphersuite per profile, but it's likely that more ciphersuites will get added over time 📈.user_canceled: Lots of IoT devices are unattended, so this error message is unlikely to happen 😴.
7. Session Resumption 🔄
Session resumption is a feature of the core TLS/DTLS specifications that lets a client pick up an earlier established session state, and it's honestly iconic ✨. The exchange looks like Figure 11. The server might also skip the cookie exchange when a session is resumed. Still, clients have to be ready to do a cookie exchange with every handshake 🍪. The cookie exchange isn't shown in the figure.
Client Server
------ ------
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Figure 11: DTLS Session ResumptionConstrained clients MUST implement session resumption to boost the performance of the handshake 🚀. That means fewer message exchanges, less computational overhead (since a session resumption exchange only uses symmetric cryptography), and less bandwidth needed. It's a whole vibe 🌸.
For cases where the server is constrained (but not the client), the client MUST implement RFC 5077 [RFC5077]. Quick note: a constrained server is a device with limits on RAM and flash memory, which restrict how much TLS/DTLS security state it can store 💾. RFC 5077 specifies a version of TLS/DTLS session resumption that doesn't need per-session state to be kept by the constrained server. It does this with 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 don't want to use session resumption can always send a ClientHello message with an empty session_id to go back to a full handshake 🔙.
8. Compression 🗜️
Section 3.3 of [RFC7525] recommends disabling TLS-/DTLS-level compression because of attacks like CRIME [CRIME]. For IoT apps, compression at the TLS/DTLS layer isn't needed, since application-layer protocols are already highly optimized, and compression algorithms at the DTLS layer make the code bigger and more complicated 📦.
TLS/DTLS layer compression is NOT RECOMMENDED by this TLS/DTLS profile 🙅♀️.
9. Perfect Forward Secrecy 🔐
PFS is a property that keeps past protocol interactions confidential even when the long-term secret gets compromised 🕰️. It's a big deal, bestie.
The PSK ciphersuite recommended in Section 4.2 doesn't have this property, because it doesn't use a DH exchange 😬. New ciphersuites that support PFS for PSK-based authentication, like the one proposed in [PSK-AES-CCM-TLS], might become standardized ciphersuites in the (near) future 👀. The recommended PSK-based ciphersuite has excellent performance, a very small memory footprint, and the lowest on-the-wire overhead, at the cost of not using any public cryptography 🧚. For deployments where public key cryptography is okay, raw public keys might be a middle ground between the PSK ciphersuite in terms of out-of-band validation and what asymmetric cryptography can do 🦋.
Physical attacks open up extra chances to get access to the crypto material stored on IoT devices 🔓. A PFS ciphersuite stops an attacker from getting the communication content exchanged before a successful long-term key compromise. However, an implementation that has been reusing the same ephemeral DH keys across multiple sessions (for performance or energy efficiency reasons) partially defeats PFS, which increases the damage 💥. So implementations SHOULD NOT reuse ephemeral DH keys over multiple protocol exchanges 🙏.
The impact of disclosing past communication and the wish to make pervasive monitoring more expensive (as demanded by [RFC7258]) have to be taken into account when picking a ciphersuite that doesn't support the PFS property 🕵️♀️.
Client implementations claiming support of this profile MUST implement the ciphersuites listed in Section 4 according to the selected credential type 🎀.
10. Keep-Alive ✨
Okay bestie, so apps can make state on the endpoints, and that state can expire 🥲 That's why apps have ways to refresh it when they need to. The app-layer exchanges mostly live outside the TLS/DTLS exchange, but TLS/DTLS has its own state considerations too 💅 Both the client and the server keep a security context (the security parameter from Appendix A.6 in RFC 5246), and that state does not expire 🔐 The catch is that network middleboxes can also allocate state and need it kept alive. If state isn't kept alive at a stateful packet filtering firewall or a NAT, one node may be unable to reach the other because those middleboxes block the packets 🙈 Periodic keep-alive messages between the TLS/DTLS client and server keep that middlebox state alive ✨ According to the measurements in [HomeGateway], residential gateways handle state management a bit differently from each other. The timeouts are strongly affected by the transport-layer protocol, though: UDP timeouts are usually much shorter than TCP timeouts 🦋
RFC 6520 [RFC6520] defines a heartbeat mechanism for checking whether the other peer is still alive 💜 The same mechanism can also be used for Path Maximum Transmission Unit (MTU) Discovery, which is a fun bonus 🎀
Whether you should use RFC 6520 depends on the kind of message exchange an IoT device does and how many messages the app needs to swap for its functionality. There are three exchange types to look at 👀
Client-Initiated, One-Shot Messages
This is super common: IoT devices upload data to a server on the Internet on an irregular basis 📦 The upload might be triggered by a specific event, like a door opening 🚪
The DTLS handshake may need to restart if the IP address changes. Ideally you'd use session resumption for that, if it's possible 🔁
In this case there's no need for a keep-alive extension 🙌
Client-Initiated, Regular Data Uploads
This is a variation of the last case where data gets uploaded on a regular schedule, like frequent temperature readings 🌡️ If neither NAT bindings nor IP address changes happen, the record layer won't notice anything 😌 If the IP address and port number do change, the record layer has to be recreated using session resumption 🔄
In this scenario there's no need for a keep-alive extension either. The device will also probably go into a sleep cycle between transmissions to save power 🔋💤
Server-Initiated Messages
In the two scenarios above, the client starts the protocol interaction and keeps it going 💁♀️ Messages to the client can get blocked by middleboxes, so the client triggers the initial connection setup and the server keeps it alive 🫶
For this pattern, DTLS heartbeat messages are really useful 🙌 They may need to be coordinated with application exchanges (for example, when the CoAP resource directory is used) so you don't send redundant keep-alive messages 🧚 The MTU discovery mechanism, which is also part of [RFC6520], is less likely to matter here. For lots of IoT deployments, the most constrained link is the wireless interface between the IoT device and the network itself, not some link along the end-to-end path 📡 Path MTU discovery might only be appropriate in more complex topologies, like multi-hop mesh networks 🕸️ It's also worth noting that DTLS already has a basic path discovery mechanism (see Section 4.1.1.1 of RFC 6347), since it uses the handshake protocol's fragmentation capability 🧩
For server-initiated messages, the heartbeat extension is RECOMMENDED 💖
11. Timeouts ⏰
Lots of wired and wireless tech can connect devices to the Internet 🌐 Many low-power radio technologies, like IEEE 802.15.4 or Bluetooth Smart, only support small frame sizes. For example, IEEE 802.15.4 has 127 bytes, as explained in [RFC4919] 🐣 Other radio tech, like GSM using SMS, has similar payload size limits. SMS has 140 bytes without the optional segmentation and reassembly scheme called "Concatenated SMS", but it has higher latency 😬
The DTLS handshake protocol adds fragmentation and reassembly to the TLS handshake protocol, because each DTLS record has to fit within a single transport layer datagram (see Section 4.2.3 of [RFC6347]) 📏 Handshake messages can be bigger than the maximum record size, so the mechanism splits a handshake message across several DTLS records. Each one can be sent separately 📨
To deal with the unreliable delivery of UDP, DTLS adds timeouts and "per-flight" retransmissions (see Section 4.2.4 of [RFC6347]) 🔄 The timeout values are implementation specific, but recommendations are in Section 4.2.4.1 of [RFC6347]. They start with an initial timer value of 1 second, double it at each retransmission, and go up to no less than 60 seconds ⏳
TLS protocol steps can take longer on the constrained side because processing takes more time 🐢 Also, DTLS retransmits per-flight instead of per-segment, which tends to interact poorly with low-bandwidth networks 😩
So it's essential that a spurious retransmit is as unlikely as possible, and that the sending endpoint doesn't overreact on timeout 🙅♀️ This matters most when the Wireless Sensor Network (WSN) is temporarily congested. If lost packets get reinjected too quickly, the congestion gets worse 🚦
An initial timer value of 9 seconds, with exponential back off up to no less than 60 seconds, is therefore RECOMMENDED ⭐
This value is big enough to absorb large latency variance, whether it comes from slow computation on constrained endpoints or from intrinsic network characteristics (such as GSM-SMS). It also keeps the number of retransmission events low and relaxes the pacing between them 🧘♀️ The worst case wait time is the same as using a 1s timeout (that's 63s), but it triggers less than half of the retransmissions (2 instead of 5) 📉
To minimize wake time during the DTLS handshake, sleepy nodes might pick a lower threshold and, as a result, a smaller initial timeout value 😴 If they do, the implementation MUST keep into account the considerations about network stability described in this section 🫡
12. Random Number Generation 🎲
The TLS/DTLS protocol needs random numbers to be available during the protocol run 🔢 For example, the client and the server exchange random numbers during the ClientHello and ServerHello exchange. The DH exchange also needs random numbers when generating the key pair 🔑
It's important to know that laptops and desktop PCs get randomness from sources that many IoT devices don't have, like mouse movement, keystroke timing, air turbulence on hard drive heads, and so on 🖱️ Other sources have to be found, or dedicated hardware has to be added 🛠️
If an embedded system lacks sources of randomness, it may generate the same keys again and again 😱
The ClientHello and ServerHello messages contain the "Random" structure, which has two parts: 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 midnight starting Jan 1, 1970, GMT) 🕰️ A lot of IoT devices don't have access to an accurate clock, so it is RECOMMENDED that the receiver of a ClientHello or ServerHello does not assume the value in Random.gmt_unix_time is an accurate representation of the current time. Instead, the receiver should treat it as an opaque random string 🫧
When TLS uses certificate-based authentication, time information is needed to check whether a certificate is valid ⏳ Higher-layer protocols may provide secure time information. The gmt_unix_time component of the ServerHello isn't used for this purpose 🙅♀️
IoT devices using TLS/DTLS must offer ways to generate quality random numbers 🎰 There are different ways to integrate a hardware-based random number generator into a product. One option is an implementation inside the microcontroller itself, but dedicated crypto chips are also reasonable 💅 The best choice depends on various factors that are outside the scope of this document 🤷♀️ For guidelines and requirements on random number generation, check RFC 4086 [RFC4086] and the NIST Special Publication 800-90a [SP800-90A] 📚
Chip manufacturers are highly encouraged to document their random number generator designs well, so customers can feel confident about the quality of the numbers 🥰 That confidence grows when there's information about the procedures used to verify the randomness of the numbers generated by the hardware modules. For example, NIST Special Publication 800-22b [SP800-22b] describes statistical tests that can verify random number generators 📊
13. Truncated MAC and Encrypt-then-MAC Extension 🧁
The truncated MAC extension came out in RFC 6066 [RFC6066] to reduce the size of the MAC used at the record layer 📉 It was made for TLS ciphersuites that used older modes of operation, where the MAC and the encryption operation were performed independently 🕰️
The recommended ciphersuites in this document use the newer AEAD construct, namely the CCM mode with 8-octet authentication tags. That means the truncated MAC extension doesn't apply to them 🚫
RFC 7366 [RFC7366] introduced the encrypt-then-MAC extension, which replaced the older MAC-then-encrypt approach, since MAC-then-encrypt has been the subject of a number of security vulnerabilities 😬 RFC 7366 doesn't apply to the AEAD ciphers recommended in this document either 🙃
Implementations conformant to this specification MUST use AEAD ciphers 🔐 RFC 7366 ("encrypt-then-MAC") and RFC 6066 ("truncated MAC extension") are not applicable to this specification and MUST NOT be used 🛑
14. Server Name Indication (SNI) 🌸
The SNI extension [RFC6066] gives a client a way to tell a TLS/DTLS server the name of the server it wants to contact 📛 It's super useful in hosting environments where multiple virtual servers run on a single IP address 🏠
Implementing the Server Name Indication extension is REQUIRED, unless it's known that a TLS/DTLS client doesn't interact with a server in a hosting environment 💖
15. Maximum Fragment Length Negotiation 🧚
okay so this RFC 6066 extension shrinks the max fragment length the record layer has to support, from 2^14 bytes down to 2^9 bytes 📉 bestie that's so smart
the whole point is that the client can tell the server how much memory buffer it has for incoming messages 🫶 the big win is lower RAM usage for clients, since they don't have to accept huge packets like the 16K ones that plain TLS/DTLS requires 💾 that's giving tiny-device-friendly energy 🦋
Client implementations MUST support this extension. 💅
16. Session Hash 🔐
okay this one is lowkey important 😭 before the record protocol can start protecting a connection, it needs a suite of algorithms, a master secret, and the client and server random values 🎀 the master secret math is defined in Section 8.1 of RFC 5246, but it only uses a handful of handshake parameters and doesn't include stuff like the client and server identities 🙈
that gap is exactly what an attacker can exploit for a man-in-the-middle attack, because the master secret isn't guaranteed to be unique across sessions 💀 this was found in the "triple handshake" attack [Triple-HS]
[RFC7627] defines a TLS extension that binds the master secret to a log of the full handshake that computes it, which blocks this kind of attack ✨
Client implementations SHOULD implement this extension even though the ciphersuites recommended by this profile are not vulnerable to this attack 🫶 for DH-based ciphersuites, both parties contribute keying material, and for the pre-shared secret key ciphersuite, both parties need the shared secret so the handshake can complete successfully 🔑 it's still possible that some application-layer protocols tunnel other authentication protocols on top of DTLS, which can make this attack relevant again 👀
17. Renegotiation Attacks ⚠️
so TLS/DTLS lets a client and server that already have a connection negotiate new parameters and generate new keys through renegotiation 🔄 it happens inside the existing connection, the new handshake packets are encrypted along with application data, and once it finishes the new channel replaces the old one 🌸
as described in RFC 5746 [RFC5746], there's no cryptographic binding between the two handshakes 😬 the new handshake still uses the cryptographic parameters from the original handshake, though 🤷♀️
to prevent the renegotiation attack [RFC5746], this specification REQUIRES the TLS renegotiation feature to be disabled 🚫 clients MUST respond to server-initiated renegotiation attempts with an alert message (no_renegotiation), and clients MUST NOT initiate them 💅
18. Downgrading Attacks 📉
this section is giving "don't let the bad guys push you backwards" 😤 when a client sends a ClientHello with a version higher than the highest version the server knows, the server is supposed to reply with a ServerHello.version equal to its highest known version, and then the handshake can carry on 🎀 that's called version tolerance 🌈
version intolerance is when the server (or a middlebox) breaks the handshake as soon as it sees a ClientHello.version higher than what it knows about 🙅♀️ and that's the behavior that makes some clients rerun the handshake with a lower version 💀 so if a system is still running an old TLS/SSL version (say, to work with legacy systems), that opens a real security hole 🕳️ in the worst case, an attacker can downgrade the handshake all the way to SSL 3.0 😱 and SSL 3.0 is so broken that there's no secure cipher available for it (see [RFC7568]) 🥀
the downgrade vulnerability above is solved by the TLS Fallback Signaling Cipher Suite Value (SCSV) [RFC7507] extension ✨ BUT this profile's implementations don't need it, because version negotiation MUST use TLS/DTLS version 1.2 (or higher) 🙌 more specifically, that means:
- 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.2cannot be negotiated. Note that the aborted connection is non-resumable. 🪦
19. Crypto Agility 🦋
this section is all about being future-proof bestie 🔮 this document recommends that software and chip manufacturers implement AES and the CCM mode of operation 💜 it references the CoAP-recommended ciphersuite choices, which were picked based on real implementation and deployment experience from the IoT community 🧚
the thing is, preferences for algorithms will change over time 🔄 not every part of a ciphersuite changes at the same speed either ⏳ ciphers, the mode of operation, and hash algorithms are the most likely to change 👀 recommended key lengths have to be adjusted over time too 📏 some deployments are also shaped by local regulation, which might dictate a certain algorithm and key size combo 🌍 ongoing discussions about specific ECC curves will probably affect implementations as well 🫧 and note that this document does not recommend or mandate a specific ECC curve 🙅♀️
the recommendations for chip manufacturers are:
- 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 support 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 reuse 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 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 reusable by a DTLS stack. 🧩
- Offer access to building blocks in addition to (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 implementation. Another example is making a special instruction available that speeds up carryless multiplications. ⚡
as a recommendation for developers and product architects, sufficient headroom should be provided to allow an upgrade to a newer cryptographic algorithm over the product's lifetime 🆙 for 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 that a robust software update mechanism is offered 💖
20. Key Length Recommendations 📏
okay so RFC 4492 [RFC4492] gives approximate comparable key sizes for symmetric and asymmetric cryptosystems, based on the best-known attacks against them 🧠 other publications suggest slightly different numbers (like [Keylength]), but the approximate relationship still holds 💅 Figure 12 shows 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 | 15360Figure 12: Comparable Key Sizes (in Bits) Based on RFC 4492 📊
at the time of writing, the key size recommendations for TLS-based ciphers in [RFC7525] suggest DH key lengths of at least 2048 bits, which lines up with a 112-bit symmetric key and a 233-bit ECC key ✨ these recommendations are roughly in line with those from other organizations, like the National Institute of Standards and Technology (NIST) or the European Network and Information Security Agency (ENISA) 🏛️ the authors of [ENISA-Report2013] add that an 80-bit symmetric key is sufficient for legacy applications for the coming years, but a 128-bit symmetric key is the minimum for new systems being deployed 🆕 they also note you have to think about how long data needs to stay secure 🕰️ 80-bit symmetric keys might be acceptable for transactional data in the near future, but you have to insist on 128-bit symmetric keys for long-lived data 🔐
note that the 112-bit symmetric key recommendations are chosen conservatively, assuming IoT devices have a long expected lifetime (like 10+ years) and that this key length recommendation refers to the long-term keys used for device authentication 🤖 keys that get provisioned dynamically, for protecting transactional data (like the ephemeral DH keys used in various TLS/DTLS ciphersuites), may be shorter given how sensitive the exchanged data is 🌸
21. False Start 🏃♀️
so a full TLS handshake under [RFC5246] needs two full protocol rounds (four flights) before the handshake is complete and the parties can start sending application data 😩
an abbreviated handshake (resuming an earlier TLS session) is complete after three flights, so it only adds one round-trip time if the client sends application data first ⏱️
if the conditions in [TLS-FALSESTART] are met, application data can be sent once the sender has sent its own "ChangeCipherSpec" and "Finished" messages 🚀 that gets you an improvement of one round-trip time for full handshakes if the client sends application data first, and for abbreviated handshakes if the server sends application data first 🙌
the public-key-based ciphersuites in this document meet the conditions for the TLS False Start mechanism 💖 in summary, the conditions are:
- Modern symmetric ciphers with an effective key length of 128 bits, such as AES-128-CCM 🔐
- Client certificate types, such as ecdsa_sign 🎀
- Key exchange methods, such as ECDHE_ECDSA 🫧
based on the improvement over a full round-trip for the full TLS/DTLS exchange, this specification RECOMMENDS using the False Start mechanism when clients send application data first 🌈 ily bestie, that's a whole vibe ✨
22. Privacy Considerations 🕵️♀️🔒
Okay bestie, privacy is a whole mood here. The DTLS handshake shares a bunch of identifiers that an on-path eavesdropper can see 👀. The DTLS PSK exchange reveals the PSK identity, the supported extensions, the session ID, algorithm parameters, and more. If session resumption is used, an on-path adversary can link individual TLS sessions together 🔗. And since so many IoT devices are expensive to update, their keying material and identifiers tend to stick around for a really long time 🥲.
Another challenge: a lot of IoT devices run unattended, even though a human set them up at the start 🤖. That means control over data sharing and preferences has to live at the system level, not inside the DTLS exchange itself. That's out of scope for this document 💅. Mutual authentication with DTLS also lets a TLS server gather authentication info about the IoT device, probably over a long stretch of time 📚. That strong authentication stops misattribution, but it also makes strong identification possible 😬. Device data like sensor recordings can be super useful when combined with other data types, but that extra data might include personal information about the device owner or details about the environment the device senses 🌡️. So the data stored on the server side is exposed to stored data compromise 💀.
The good news: between client and server, this specification keeps eavesdroppers from getting at the communication content 🛡️. The PSK-based ciphersuite doesn't provide PFS, but the asymmetric versions do ✨. That means an adversary who gets hold of a long-term secret still can't read past communication content 🙌. Just note that the recommendations in this document don't add any extra effort to make traffic analysis harder 🙈.
Also, the mere presence or absence of communication can reveal things to an adversary 👻. For example, a presence sensor might start messaging the moment someone walks into a building 🚪. TLS/DTLS protects the confidentiality of what's sent, but it doesn't hide all the communication patterns 🫣. The IP header isn't protected by TLS/DTLS, so it also reveals information about the other communication endpoint 📡. For applications where these privacy concerns matter, extra safeguards are required, such as injecting dummy traffic and onion routing 🧅. A detailed treatment of those solutions is outside the scope of this document and needs a system-level view 🧚.
23. Security Considerations 🔐
Plot twist: this entire document is about security 💖.
We'd also like to point out that designing a software update mechanism into an IoT system is crucial 🚨. It's how functionality gets enhanced and how potential vulnerabilities get fixed 🔧. The same mechanism matters for changing configuration information, like trust anchors and other keying-related information 🔑. A suitable software update mechanism is available with the LWM2M protocol published by the OMA [LWM2M] 🎀.
24. References 📚
24.1. Normative References
- [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)", Registration Authority,
https://standards.ieee.org/regauth/oui/tutorials/EUI64.html. - [GSM-SMS] ETSI, "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Technical realization of the Short Message Service (SMS) (Release 13)", 3GPP TS 23.040 V13.1.0, March 2016.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
http://www.rfc-editor.org/info/rfc2119. - [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005,
http://www.rfc-editor.org/info/rfc4279. - [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008,
http://www.rfc-editor.org/info/rfc5246. - [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
http://www.rfc-editor.org/info/rfc5746. - [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011,
http://www.rfc-editor.org/info/rfc6066. - [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011,
http://www.rfc-editor.org/info/rfc6125. - [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012,
http://www.rfc-editor.org/info/rfc6347. - [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012,
http://www.rfc-editor.org/info/rfc6520. - [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014,
http://www.rfc-editor.org/info/rfc7250. - [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,
http://www.rfc-editor.org/info/rfc7251. - [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015,
http://www.rfc-editor.org/info/rfc7627. - [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016,
http://www.rfc-editor.org/info/rfc7924. - [WAP-WDP] Open Mobile Alliance, "Wireless Datagram Protocol", Wireless Application Protocol, WAP-259-WDP, June 2001.
24.2. Informative References
- [ACE-WG] IETF, "Authentication and Authorization for Constrained Environments (ACE) Working Group",
https://datatracker.ietf.org/wg/ace/charter. - [AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", NIST FIPS PUB 197, November 2001,
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf. - [CCM] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", NIST Special Publication 800-38C, May 2004,
http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf. - [COAP-TCP-TLS] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", Work in Progress, draft-ietf-core-coap-tcp-tls-03, July 2016.
- [CoRE-RD] Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource-directory-08, July 2016.
- [CRIME] Wikipedia, "CRIME", May 2016,
https://en.wikipedia.org/w/index.php?title=CRIME&oldid=721665716. - [ENISA-Report2013] ENISA, "Algorithms, Key Sizes and Parameters Report - 2013", October 2013,
https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report. - [FFDHE-TLS] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS", Work in Progress, draft-ietf-tls-negotiated-ff-dhe-10, June 2015.
- [HomeGateway] Eggert, L., Hatoen, S., Kojo, M., Nyrhinen, A., Sarolahti, P., and S. Strowes, "An Experimental Study of Home Gateway Characteristics", In Proceedings of the 10th ACM SIGCOMM conference on Internet measurement, DOI 10.1145/1879141.1879174, 2010,
http://conferences.sigcomm.org/imc/2010/papers/p260.pdf. - [IANA-TLS] IANA, "Transport Layer Security (TLS) Parameters",
https://www.iana.org/assignments/tls-parameters. - [ImprintingSurvey] Chilton, E., "A Brief Survey of Imprinting Options for Constrained Devices", March 2012,
http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/EricRescorla.pdf. - [Keylength] Giry, D., "Cryptographic Key Length Recommendations", September 2015,
http://www.keylength.com. - [LWM2M] Open Mobile Alliance, "Lightweight Machine-to-Machine Requirements", Candidate Version 1.0, OMA-RD-LightweightM2M-V1_0-20131210-C, December 2013,
http://openmobilealliance.org/about-oma/work-program/m2m-enablers. - [PSK-AES-CCM-TLS] Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy for Transport Layer Security (TLS)", Work in Progress, draft-schmertmann-dice-ccm-psk-pfs-01, August 2014.
- [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996,
http://www.rfc-editor.org/info/rfc1981. - [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997,
http://www.rfc-editor.org/info/rfc2104. - [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000,
http://www.rfc-editor.org/info/rfc2865. - [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003,
http://www.rfc-editor.org/info/rfc3610. - [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
http://www.rfc-editor.org/info/rfc3748.
[Note: the environment details above are attached automatically and are not part of the rewrite task. My output is the rewritten document only.]
References (continued) 📚✨
Okay bestie, here's the rest of the reference list, so every citation is still right there 🦋
24.1. Normative References (continued)
- [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>. 🎲
- [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>. 🔐
- [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>. 📦
- [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <http://www.rfc-editor.org/info/rfc4919>. 📡
- [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <http://www.rfc-editor.org/info/rfc5077>. 🎟️
- [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>. 🔒
- [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <http://www.rfc-editor.org/info/rfc5216>. 🪪
- [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, DOI 10.17487/RFC5247, August 2008, <http://www.rfc-editor.org/info/rfc5247>. 🗝️
- [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>. 📜
- [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, DOI 10.17487/RFC5288, August 2008, <http://www.rfc-editor.org/info/rfc5288>. 💜
- [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <http://www.rfc-editor.org/info/rfc5480>. 🌸
- [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", RFC 5758, DOI 10.17487/RFC5758, January 2010, <http://www.rfc-editor.org/info/rfc5758>. ✨
- [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, DOI 10.17487/RFC5934, August 2010, <http://www.rfc-editor.org/info/rfc5934>. 🧭
- [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2010, <http://www.rfc-editor.org/info/rfc6024>. 📋
- [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <http://www.rfc-editor.org/info/rfc6090>. 🧮
- [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>. 🔑
- [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/RFC6655, July 2012, <http://www.rfc-editor.org/info/rfc6655>. 🎀
- [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>. 🔗
- [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>. 🛰️
- [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, <http://www.rfc-editor.org/info/rfc6943>. 🔍
- [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, <http://www.rfc-editor.org/info/rfc6961>. 🧾
- [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>. 🧱
- [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>. 🪶
- [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>. 👀
- [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, <http://www.rfc-editor.org/info/rfc7366>. 🫶
- [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, <http://www.rfc-editor.org/info/rfc7390>. 👯
- [RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart Object Security Workshop", RFC 7397, DOI 10.17487/RFC7397, December 2014, <http://www.rfc-editor.org/info/rfc7397>. 🗒️
- [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 2014, <http://www.rfc-editor.org/info/rfc7400>. 🗜️
- [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, "Architectural Considerations in Smart Object Networking", RFC 7452, DOI 10.17487/RFC7452, March 2015, <http://www.rfc-editor.org/info/rfc7452>. 🏠
- [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, <http://www.rfc-editor.org/info/rfc7465>. 🚫
- [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, <http://www.rfc-editor.org/info/rfc7507>. 🛡️
- [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>. 💅
- [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, <http://www.rfc-editor.org/info/rfc7539>. 🌊
- [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, DOI 10.17487/RFC7568, June 2015, <http://www.rfc-editor.org/info/rfc7568>. 🪦
- [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <http://www.rfc-editor.org/info/rfc7748>. 🌙
- [SP800-107-rev1] National Institute of Standards and Technology, "Recommendation for Applications Using Approved Hash Algorithms", NIST Special Publication 800-107, Revision 1, DOI 10.6028/NIST.SP.800-107r1, August 2012, <http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf>. 📗
- [SP800-22b] National Institute of Standards and Technology, "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications", NIST Special Publication 800-22, Revision 1a, April 2010, <http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/SP800-22rev1a.pdf>. 🧪
- [SP800-90A] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST Special Publication 800-90A Revision 1, DOI 10.6028/NIST.SP.800-90Ar1, June 2015, <http://csrc.nist.gov/publications/drafts/800-90/sp800-90a_r1_draft_november2014_ver.pdf>. 🎰
- [TLS-FALSESTART] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", Work in Progress, draft-ietf-tls-falsestart-02, May 2016. 🚧
- [Triple-HS] Bhargavan, K., Delignat-Lavaud, C., Pironti, A., and P. Yves Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", In Proceedings of the IEEE Symposium on Security and Privacy, Pages 98-113, DOI 10.1109/SP.2014.14, 2014. 🍪
Appendix A. Conveying DTLS over SMS ✉️
This section is normative for the use of DTLS over SMS. Timer recommendations are already outlined in Section 11 and also applicable to the transport of DTLS over SMS. 💖
This section requires readers to be familiar with the terminology and concepts described in [GSM-SMS] and [WAP-WDP]. 📖
The remainder of this section assumes Mobile Stations are capable of producing and consuming Transport Protocol Data Units (TPDUs) encoded as 8-bit binary data. 📱✨
A.1. Overview 🦋
okay bestie, so DTLS bolts an extra round-trip onto the TLS [RFC5246] handshake 🔄. That round-trip is a return-routability test, which basically checks that the other side really lives at the address it claims, so it can dodge certain types of DoS attacks 🛡️. A full-blown DTLS handshake can have up to 6 "flights" (aka logical message exchanges), and each flight gets mapped onto one or more DTLS records using the segmentation and reassembly (SaR) scheme from Section 4.2.3 of [RFC6347] 🧩. That scheme costs 6 bytes per handshake message. With a realistic handshake of 10+ messages, that adds up to around 60 bytes across the whole sequence 💅.
Note that the DTLS SaR scheme is only for handshake messages 👀. DTLS records are never fragmented, and they MUST fit within a single transport layer datagram 🎀.
SMS has its own optional segmentation and reassembly scheme too, called Concatenated short messages (see Section 9.2.3.24.1 of [GSM-SMS]) 📱. But since the DTLS SaR scheme can't be skipped, the Concatenated short messages mechanism SHOULD NOT be used during the handshake, or you're just paying redundant overhead for nothing 🙃. Before the handshake starts (whether you're in it actively or passively), the DTLS implementation MUST be explicitly configured with the Path MTU (PMTU) of the SMS transport so the SaR function can work properly 🔧. The PMTU SHALL be 133 bytes if multiplexing based on the Wireless Datagram Protocol (WDP) is used (see Appendix A.3), and 140 bytes otherwise 📏.
It is RECOMMENDED that the established security context be kept for the longest possible period (possibly until a Closure Alert message is received, or after a very long inactivity timeout) so you dodge the expensive re-establishment of the security association 💖.
A.2. Message Segmentation and Reassembly 🧩
The content of an SMS message lives in the TP-UserData field, and it can be up to 140 bytes 📨. As mentioned in Appendix A.1, longer messages (up to 34170 bytes) can be sent using Concatenated SMS 📚.
This scheme eats 6-7 bytes of the TP-UserData field (depending on whether the short or long segmentation format is used), so the room left for actual content drops to 133-134 bytes per TPDU 🥲.
Though in principle a PMTU higher than 140 bytes could be used, which might look dreamy since it uses the transport more efficiently, there are downsides to think about 🤔. First, there's an extra 7 bytes of overhead per TPDU paid to the SaR function, on top of the overhead from the DTLS SaR mechanism. Second, some networks only partially support Concatenated SMS, and others don't support it at all 😬.
So for these reasons the Concatenated short messages mechanism SHOULD NOT be used, and it is RECOMMENDED to keep the same PMTU settings used during the handshake phase: 133 bytes if WDP-based multiplexing is enabled, 140 bytes otherwise 🎯.
Note that once the DTLS handshake has completed, any fragmentation and reassembly logic that applies to the application layer (e.g., segmenting CoAP messages into DTLS records and reassembling them after the crypto operations have been successfully performed) has to be handled by the application using the established DTLS tunnel 🔐.
A.3. Multiplexing Security Associations 🌸
Unlike IPsec Encapsulating Security Payload (ESP) / Authentication Header (AH), DTLS records don't carry any association identifiers 🙈. So applications have to arrange multiplexing between associations on the same endpoint, which over UDP/IP is usually done with the host/port number 🔀.
If the DTLS server lets more than one client be active at any given time, the Wireless Application Protocol (WAP) User Datagram Protocol [WAP-WDP] can be used to multiplex the different security associations 🧚. (Using WDP has the bonus that upper-layer protocols can operate independently of the underlying wireless network, which gets you application-agnostic transport handover 🦋.) The total overhead for encoding the WDP source and destination ports is either 5 or 7 bytes out of what's available for the SMS content, depending on whether 1-byte or 2-byte port identifiers are used, as shown in Figures 13 and 14 📊.
0 1 2 3 4
+--------+--------+--------+--------+--------+
| ... | 0x04 | 2 | ... | ... |
+--------+--------+--------+--------+--------+
UDH IEI IE Dest Source
Length Length Port Port
Legend:
UDH = user data header
IEI = information element identifierFigure 13: Application Port Addressing Scheme (8-Bit Address)
0 1 2 3 4 5 6
+--------+--------+--------+--------+--------+--------+--------+
| ... | 0x05 | 4 | ... | ... |
+--------+--------+--------+--------+--------+--------+--------+
UDH IEI IE Dest Source
Length Length Port PortFigure 14: Application Port Addressing Scheme (16-Bit Address)
The receiving side gets the source address from the originator address (TP-OA) field of the SMS-DELIVER TPDU. This way, a unique 4-tuple identifying the security association can be rebuilt at both ends 🎉. (When replying to its DTLS peer, the sender swaps the TP-OA and destination address (TP-DA) parameters, and the source and destination ports in the WDP 🔁.)
A.4. Timeout ⏰
If SMS-STATUS-REPORT messages are enabled, getting one does not mean the receiving party has acted on that particular handshake message 📭. So it MUST NOT be taken into account by the DTLS timeout and retransmission function 🚫.
Handshake messages MUST carry a validity period (that's the TP-VP parameter in an SMS-SUBMIT TPDU) that is not less than the current retransmission timeout 🕰️. To avoid leaving zombie messages floating around the network that the receiver is just going to toss 🧟, handshake messages SHOULD carry a validity period that is the same as, or just slightly higher than, the current retransmission timeout ✨.
Appendix B. DTLS Record Layer Per-Packet Overhead 💜
Figure 15 shows the overhead for the DTLS record layer when it's protecting data traffic with AES-128-CCM and an 8-octet Integrity Check Value (ICV) 🔐.
DTLS Record Layer Header................13 bytes
Nonce (Explicit).........................8 bytes
ICV..................................... 8 bytes
------------------------------------------------
Overhead................................29 bytes
------------------------------------------------Figure 15: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead
The DTLS record layer header is 13 octets and has these pieces 🧱:
- 1-octet content type field,
- 2-octet version field,
- 2-octet epoch field,
- 6-octet sequence number, and
- 2-octet length field.
The "nonce" input to the AEAD algorithm is exactly that of [RFC5288], i.e., 12 bytes long 📏. It has two parts, a 4-octet salt and an 8-octet nonce_explicit:
- The salt is the "implicit" part and is not sent in the packet. Instead, the salt is generated as part of the handshake process 🧂.
- The
nonce_explicitvalue is 8 octets long and it is chosen by the sender and carried in each TLS record. RFC 6655 [RFC6655] allows thenonce_explicitto be a sequence number or something else. This document makes this use more restrictive for use with DTLS: the 64-bitnone_explicitvalue MUST be the 16-bit epoch concatenated with the 48-bitseq_num. The sequence number component of thenonce_explicitfield 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] helps 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 of this document 📱.
Appendix C. DTLS Fragmentation 🧩
Section 4.2.3 of [RFC6347] advises DTLS implementations to not produce overlapping fragments 🙅. However, it requires receivers to be able to cope with them. The need for the latter is explained in Section 4.1.1.1 of [RFC6347]: accurate PMTU estimation may be traded for shorter handshake completion time ⏱️.
In many cases, handling fragment overlaps has proved to be unaffordable for constrained implementations, mostly because of the extra complexity in buffer management 😵💫.
In order to reduce the likelihood of producing different fragment sizes and the overlaps that follow within the same handshake, this document RECOMMENDs:
- clients (handshake initiators) to use reliable PMTU information for the intended destination; and
- servers to mirror the fragment size selected by their clients.
The PMTU information comes from either a "fresh enough" discovery performed by the client [RFC1981] [RFC4821], or some other reliable out-of-band channel 🗺️.
Acknowledgments 💐
Huge thanks to Derek Atkins, Paul Bakker, Olaf Bergmann, Carsten Bormann, Ben Campbell, Brian Carpenter, Robert Cragie, Spencer Dawkins, Russ Housley, Rene Hummen, Jayaraghavendran K, Sye Loong Keoh, Matthias Kovatsch, Sandeep Kumar, Barry Leiba, Simon Lemay, Alexey Melnikov, Gabriel Montenegro, Manuel Pegourie-Gonnard, Akbar Rahman, Eric Rescorla, Michael Richardson, Ludwig Seitz, Zach Shelby, Michael StJohns, Rene Struik, Tina Tsou, and Sean Turner for their helpful comments and discussions that shaped the document 🫶.
A big thanks also to Klaus Hartke, who wrote the initial draft version of this document 🌟.
Finally, we'd like to thank our area director (Stephen Farrell) and our working group chairs (Zach Shelby and Dorothy Gellert) for their support 👑.
Authors' Addresses 🖋️
Hannes Tschofenig (editor)
ARM Ltd.
110 Fulbourn Rd
Cambridge CB1 9NJ
United Kingdom
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Thomas Fossati
Nokia
3 Ely Road
Milton, Cambridge CB24 6DD
United Kingdom
Email: thomas.fossati@nokia.comand that's the whole spec, bestie!! 🌈💖 the end ✨
📦 where this page comes from
- ietf: rfc7925 2016-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms