17. Renegotiation Attacks
TLS/DTLS allows a client and a server that already have a TLS/DTLS
connection to negotiate new parameters, generate new keys, etc., by
using the renegotiation feature. Renegotiation happens in the
existing connection, with the new handshake packets being encrypted
along with application data. Upon completion of the renegotiation
procedure, the new channel replaces the old channel.
As described in RFC 5746 [RFC5746], there is no cryptographic binding
between the two handshakes, although the new handshake is carried out
using the cryptographic parameters established by the original
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
When a client sends a ClientHello with a version higher than the
highest version known to the server, the server is supposed to reply
with ServerHello.version equal to the highest version known to the
server, and then the handshake can proceed. This behavior is known
as version tolerance. Version intolerance is when the server (or a
middlebox) breaks the handshake when it sees a ClientHello.version
higher than what it knows about. This is the behavior that leads
some clients to rerun the handshake with a lower version. As a
result, a potential security vulnerability is introduced when a
system is running an old TLS/SSL version (e.g., because of the need
to integrate with legacy systems). In the worst case, this allows an
attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is
so broken that there is no secure cipher available for it (see
The above-described downgrade vulnerability is solved by the TLS
Fallback Signaling Cipher Suite Value (SCSV) [RFC7507] extension.
However, the solution is not applicable to implementations conforming
to this profile since the version negotiation MUST use TLS/DTLS
version 1.2 (or higher). More specifically, this implies:
o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in
o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS
version lower than 1.2.
o Servers MUST fail the handshake by sending a protocol_version
fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated.
Note that the aborted connection is non-resumable.
19. Crypto Agility
This document recommends that software and chip manufacturers
implement AES and the CCM mode of operation. This document
references the CoAP-recommended ciphersuite choices, which have been
selected based on implementation and deployment experience from the
IoT community. Over time, the preference for algorithms will,
however, change. Not all components of a ciphersuite are likely to
change at the same speed. Changes are more likely expected for
ciphers, the mode of operation, and the hash algorithms. The
recommended key lengths have to be adjusted over time as well. Some
deployment environments will also be impacted by local regulation,
which might dictate a certain algorithm and key size combination.
Ongoing discussions regarding the choice of specific ECC curves will
also likely impact implementations. Note that this document does not
recommend or mandate a specific ECC curve.
The following recommendations can be made to chip manufacturers:
o Make any AES hardware-based crypto implementation accessible to
developers working on security implementations at higher layers in
the protocol stack. Sometimes hardware implementations are added
to microcontrollers to offer support for functionality needed at
the link layer and are only available to the on-chip link-layer
protocol implementation. Such a setup does not allow application
developers to reuse the hardware-based AES implementation.
o Provide flexibility for the use of the crypto function with future
extensibility in mind. For example, making an AES-CCM
implementation available to developers is a first step but such an
implementation may not be usable due to parameter differences
between an AES-CCM implementation. AES-CCM in IEEE 802.15.4 and
Bluetooth Smart use 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.
o Offer access to building blocks in addition (or as an alternative)
to the complete functionality. For example, a chip manufacturer
who gives developers access to the AES crypto function can use it
to build an efficient AES-GCM implementation. Another example is
to make a special instruction available that increases the speed
of speed-up carryless multiplications.
As a recommendation for developers and product architects, we suggest
that sufficient headroom is provided to allow an upgrade to a newer
cryptographic algorithm over the lifetime of the product. As an
example, while AES-CCM is recommended throughout this specification,
future products might use the ChaCha20 cipher in combination with the
Poly1305 authenticator [RFC7539]. The assumption is made that a
robust software update mechanism is offered.
20. Key Length Recommendations
RFC 4492 [RFC4492] gives approximate comparable key sizes for
symmetric- and asymmetric-key cryptosystems based on the best-known
algorithms for attacking them. While other publications suggest
slightly different numbers, such as [Keylength], the approximate
relationship still holds true. Figure 12 illustrates the comparable
key sizes in bits.
Symmetric | ECC | DH/DSA/RSA
80 | 163 | 1024
112 | 233 | 2048
128 | 283 | 3072
192 | 409 | 7680
256 | 571 | 15360
Figure 12: Comparable Key Sizes (in Bits) Based on RFC 4492
At the time of writing, the key size recommendations for use with
TLS-based ciphers found in [RFC7525] recommend DH key lengths of at
least 2048 bits, which corresponds to a 112-bit symmetric key and a
233-bit ECC key. These recommendations are roughly in line with
those from other organizations, such as the National Institute of
Standards and Technology (NIST) or the European Network and
Information Security Agency (ENISA). The authors of
[ENISA-Report2013] add that a 80-bit symmetric key is sufficient for
legacy applications for the coming years, but a 128-bit symmetric key
is the minimum requirement for new systems being deployed. The
authors further note that one needs to also take into account the
length of time data needs to be kept secure for. The use of 80-bit
symmetric keys for transactional data may be acceptable for the near
future while one has to insist on 128-bit symmetric keys for long-
Note that the recommendations for 112-bit symmetric keys are chosen
conservatively under the assumption that IoT devices have a long
expected lifetime (such as 10+ years) and that this key length
recommendation refers to the long-term keys used for device
authentication. Keys, which are provisioned dynamically, for the
protection of transactional data (such as ephemeral DH keys used in
various TLS/DTLS ciphersuites) may be shorter considering the
sensitivity of the exchanged data.
21. False Start
A full TLS handshake as specified in [RFC5246] requires two full
protocol rounds (four flights) before the handshake is complete and
the protocol parties may begin to send application data.
An abbreviated handshake (resuming an earlier TLS session) is
complete after three flights, thus adding just one round-trip time if
the client sends application data first.
If the conditions outlined in [TLS-FALSESTART] are met, application
data can be transmitted when the sender has sent its own
"ChangeCipherSpec" and "Finished" messages. This achieves 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 conditions for using the TLS False Start mechanism are met by the
public-key-based ciphersuites in this document. In summary, the
o Modern symmetric ciphers with an effective key length of 128 bits,
such as AES-128-CCM
o Client certificate types, such as ecdsa_sign
o 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 the use of the False Start
mechanism when clients send application data first.
22. Privacy Considerations
The DTLS handshake exchange conveys various identifiers, which can be
observed by an on-path eavesdropper. For example, the DTLS PSK
exchange reveals the PSK identity, the supported extensions, the
session ID, algorithm parameters, etc. When session resumption is
used, then individual TLS sessions can be correlated by an on-path
adversary. With many IoT deployments, it is likely that keying
material and their identifiers are persistent over a longer period of
time due to the cost of updating software on these devices.
User participation poses a challenge in many IoT deployments since
many of the IoT devices operate unattended, even though they are
initially provisioned by a human. The ability to control data
sharing and to configure preferences will have to be provided at a
system level rather than at the level of the DTLS exchange itself,
which is the scope of this document. Quite naturally, the use of
DTLS with mutual authentication will allow a TLS server to collect
authentication information about the IoT device (likely over a long
period of time). While this strong form of authentication will
prevent misattribution, it also allows strong identification.
Device-related data collection (e.g., sensor recordings) associated
with other data types will prove to be truly useful, but this extra
data might include personal information about the owner of the device
or data about the environment it senses. Consequently, the data
stored on the server side will be vulnerable to stored data
compromise. For the communication between the client and the server,
this specification prevents eavesdroppers from gaining access to the
communication content. While the PSK-based ciphersuite does not
provide PFS, the asymmetric versions do. This prevents an adversary
from obtaining past communication content when access to a long-term
secret has been gained. Note that no extra effort to make traffic
analysis more difficult is provided by the recommendations made in
Note that the absence or presence of communication itself might
reveal information to an adversary. For example, a presence sensor
may initiate messaging when a person enters a building. While TLS/
DTLS would offer confidentiality protection of the transmitted
information, it does not help to conceal all communication patterns.
Furthermore, the IP header, which is not protected by TLS/DTLS,
additionally reveals information about the other communication
endpoint. For applications where such privacy concerns exist,
additional safeguards are required, such as injecting dummy traffic
and onion routing. A detailed treatment of such solutions is outside
the scope of this document and requires a system-level view.
23. Security Considerations
This entire document is about security.
We would also like to point out that designing a software update
mechanism into an IoT system is crucial to ensure that both
functionality can be enhanced and that potential vulnerabilities can
be fixed. This software update mechanism is important for changing
configuration information, for example, trust anchors and other
keying-related information. Such a suitable software update
mechanism is available with the LWM2M protocol published by the OMA
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.
DTLS adds an additional round-trip to the TLS [RFC5246] handshake to
serve as a return-routability test for protection against certain
types of DoS attacks. Thus, a full-blown DTLS handshake comprises up
to 6 "flights" (i.e., logical message exchanges), each of which is
then mapped on to one or more DTLS records using the segmentation and
reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. The
overhead for said scheme is 6 bytes per handshake message which,
given a realistic 10+ messages handshake, would amount to around 60
bytes across the whole handshake sequence.
Note that the DTLS SaR scheme is defined for handshake messages only.
In fact, DTLS records are never fragmented and MUST fit within a
single transport layer datagram.
SMS provides an optional segmentation and reassembly scheme as well,
known as Concatenated short messages (see Section 220.127.116.11.1 of
[GSM-SMS]). However, since the SaR scheme in DTLS cannot be
circumvented, the Concatenated short messages mechanism SHOULD NOT be
used during handshake to avoid redundant overhead. Before starting
the handshake phase (either actively or passively), the DTLS
implementation MUST be explicitly configured with the Path MTU (PMTU)
of the SMS transport in order to correctly instrument its SaR
function. The PMTU SHALL be 133 bytes if multiplexing based on the
Wireless Datagram Protocol (WDP) is used (see Appendix A.3); 140
It is RECOMMENDED that the established security context over the
longest possible period be used (possibly until a Closure Alert
message is received or after a very long inactivity timeout) to avoid
the expensive re-establishment of the security association.
A.2. Message Segmentation and Reassembly
The content of an SMS message is carried in the TP-UserData field,
and its size may be up to 140 bytes. As already mentioned in
Appendix A.1, longer (i.e., up to 34170 bytes) messages can be sent
using Concatenated SMS.
This scheme consumes 6-7 bytes (depending on whether the short or
long segmentation format is used) of the TP-UserData field, thus
reducing the space available for the actual content of the SMS
message to 133-134 bytes per TPDU.
Though in principle a PMTU value higher than 140 bytes could be used,
which may look like an appealing option given its more efficient use
of the transport, there are disadvantages to consider. First, there
is an additional overhead of 7 bytes per TPDU to be paid to the SaR
function (which is in addition to the overhead introduced by the DTLS
SaR mechanism. Second, some networks only partially support the
Concatenated SMS function, and others do not support it at all.
For these reasons, the Concatenated short messages mechanism SHOULD
NOT be used, and it is RECOMMENDED to leave the same PMTU settings
used during the handshake phase, i.e., 133 bytes if WDP-based
multiplexing is enabled; 140 bytes otherwise.
Note that, after the DTLS handshake has completed, any fragmentation
and reassembly logic that pertains the application layer (e.g.,
segmenting CoAP messages into DTLS records and reassembling them
after the crypto operations have been successfully performed) needs
to be handled by the application that uses the established DTLS
A.3. Multiplexing Security Associations
Unlike IPsec Encapsulating Security Payload (ESP) / Authentication
Header (AH), DTLS records do not contain any association identifiers.
Applications must arrange to multiplex between associations on the
same endpoint which, when using UDP/IP, is usually done with the
If the DTLS server allows more than one client to be active at any
given time, then the Wireless Application Protocol (WAP) User
Datagram Protocol [WAP-WDP] can be used to achieve multiplexing of
the different security associations. (The use of WDP provides the
additional benefit that upper-layer protocols can operate
independently of the underlying wireless network, hence achieving
application-agnostic transport handover.)
The total overhead cost for encoding the WDP source and destination
ports is either 5 or 7 bytes out of the total available for the SMS
content depending on if 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
UDH = user data header
IEI = information element identifier
Figure 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 Port
Figure 14: Application Port Addressing Scheme (16-Bit Address)
The receiving side of the communication 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
reconstructed at both ends. (When replying to its DTLS peer, the
sender will swap the TP-OA and destination address (TP-DA) parameters
and the source and destination ports in the WDP.)
If SMS-STATUS-REPORT messages are enabled, their receipt is not to be
interpreted as the signal that the specific handshake message has
been acted upon by the receiving party. Therefore, it MUST NOT be
taken into account by the DTLS timeout and retransmission function.
Handshake messages MUST carry a validity period (TP-VP parameter in a
SMS-SUBMIT TPDU) that is not less than the current value of the
retransmission timeout. In order to avoid persisting messages in the
network that will be discarded by the receiving party, handshake
messages SHOULD carry a validity period that is the same as, or just
slightly higher than, the current value of the retransmission
Appendix B. DTLS Record Layer Per-Packet Overhead
Figure 15 shows the overhead for the DTLS record layer for protecting
data traffic when AES-128-CCM with an 8-octet Integrity Check Value
(ICV) is used.
DTLS Record Layer Header................13 bytes
Nonce (Explicit).........................8 bytes
ICV..................................... 8 bytes
Figure 15: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead
The DTLS record layer header has 13 octets and consists of:
o 1-octet content type field,
o 2-octet version field,
o 2-octet epoch field,
o 6-octet sequence number, and
o 2-octet length field.
The "nonce" input to the AEAD algorithm is exactly that of [RFC5288],
i.e., 12 bytes long. It consists of two values, namely 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_explicit value is 8 octets long and it is chosen by the
sender and carried in each TLS record. RFC 6655 [RFC6655] allows
the nonce_explicit to be a sequence number or something else.
This document makes this use more restrictive for use with DTLS:
the 64-bit none_explicit value MUST be the 16-bit epoch
concatenated with the 48-bit seq_num. The sequence number
component of the nonce_explicit field at the AES-CCM layer is an
exact copy of the sequence number in the record layer header
field. This leads to a duplication of 8-bytes per record.
To avoid this 8-byte duplication, RFC 7400 [RFC7400] provides help
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 requisite is
explained in Section 18.104.22.168 of [RFC6347]: accurate PMTU estimation
may be traded for shorter handshake completion time.
In many cases, the cost of handling fragment overlaps has proved to
be unaffordable for constrained implementations, particularly because
of the increased complexity in buffer management.
In order to reduce the likelihood of producing different fragment
sizes and consequent overlaps within the same handshake, this
o clients (handshake initiators) to use reliable PMTU information
for the intended destination; and
o 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
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 have shaped the document.
A big thanks also to Klaus Hartke, who wrote the initial draft
version of this document.
Finally, we would like to thank our area director (Stephen Farrell)
and our working group chairs (Zach Shelby and Dorothy Gellert) for