IoT Security
Datagram TLS (DTLS)
Mridul Sankar Barik
Jadavpur University
2024-25
Introduction
▶ Session layer protocol for secure datagram-based
communication
▶ Introduced by Nagendra Modadugu and Eric Rescorla in 2004
▶ Standardized in RFC 4347
▶ RFC 6347: Datagram Transport Layer Security (DTLS)
Version 1.2
▶ RFC 9147: Datagram Transport Layer Security (DTLS),
Version 1.3
▶ Enables end-to-end security (authentication, confidentiality,
integrity) between applications in multihop networks
▶ Similar to TLS but does not inherit security issues related to
TCP
DTLS Design Overview I
▶ Target applications for DTLS are the client-server variety for
which TLS was designed
▶ Why not IPSec?
▶ IPsec is a peer-to-peer protocol
▶ IPsec resides at the network layer and implemented in OS
kernel
▶ AH and ESP are implemented in kernel
▶ IKE is implemented as a user daemon
▶ Lack of standardized IPSec APIs
▶ As key negotiation over an unreliable channel is complicated,
adopt a split design
▶ Use a TCP connection for key negotiation
▶ Use those keys to secure a datagram channel
▶ Drawback: TCP connection has to be kept open for key
renagotiation OR close the TCP connection, renegotiate keys
over UDP but with retransmission mechanism
DTLS Design Requirement
▶ Datagram Transport
▶ DTLS must be able to complete key negotiation and bulk data transfer
over a single datagram channel
▶ Applications can simply replace each datagram socket with a secure
datagram socket managed by DTLS
▶ Reliable Session Establishment
▶ DTLS must provide a mechanism for authenticating endpoints, reliably
establishing keying material and negotiating algorithms and parameters
▶ DTLS must implement a simple and lightweight retransmission
mechanism for ensuring that handshake messages are reliably delivered
▶ Security Services
▶ DTLS must provide confidentiality and integrity for the data transmitted
over it. It should optionally provide the ability to detect replayed packets.
▶ Ease of Deployment
▶ DTLS should be implementable solely in user space allowing developers to
bundle a DTLS implementation with their application without dependence
on operating system vendors
▶ Semantics
▶ DTLS semantics should mimic UDP semantics thus allowing DTLS
implementations to mimic the UDP API
▶ Minimal Changes: DTLS should be easily implemented based on existing
TLS implementations
DTLS Non-Requirements
▶ DTLS is not intended to provide any congestion control
functionality - must be addressed by applications
▶ Applications that do not implement congestion control can
use the Datagram Congestion Control Protocol (DCCP)
DTLS Record Protocol (1)
▶ All DTLS data are carried in records
▶ In order to avoid dealing with fragmentation, we require
DTLS records to fit within a single datagram
▶ DTLS layer does not need to buffer partial records making
them less susceptible to a DoS attack
▶ Received fragments are useless and cannot be processed if
datagrams carrying the remaining record fragments are lost
▶ It is not clear how long received fragments should be buffered
before being discarded
▶ IP fragmentation and re-assembly: No effect on DTLS as it is
transparently handled by the kernel
DTLS Record Protocol (2)
▶ Two new fields (in addition to what TLS
have)
▶ Epoch:
▶ Identify which cipher state has been used to
secure the payload
▶ Resolves ambiguity that arises when data loss
occurs during a session renegotiation
▶ Incremented during handshake
(ChangeCipherSpec message)
▶ Sequence Number:
▶ Used to reorder datagrams as they may be
delivered out of order
▶ Protects against replay attacks
DTLS Record Protocol Message Format ▶ Incremented by 1 for each record and are reset to
Figure Source: [Modadugu and Rescorla, 2004] zero whenever the cipher state is rolled over due
to a session renegotiation
▶ DTLS sequence numbers are 48 bits (TLS’s are
64 bits) and therefore the total space occupied by
epoch and sequence number is the same as the
sequence number in TLS
DTLS Handshake Protocol (1)
▶ Identical to TLS with two major changes:
▶ Stateless cookie exchange to prevent denial
of service
▶ Message fragmentation and re-assembly
▶ Uses three round trips
▶ Vulnerable to two denial of service attacks
that TLS is not
▶ Resource consumption attack
▶ Amplification attack where the attacker
sends a ClientHello message apparently
sourced by the victim
▶ Mitigation: DTLS uses the cookie exchange
technique
▶ Before the handshake proper begins, the
DTLS Handshake Protocol
client must replay a “cookie” provided by
Figure Source: [Roepke et al., 2016] the server in order to demonstrate that it is
capable of receiving packets at its claimed
IP address
DTLS Handshake Protocol (2)
▶ Initial ClientHello contains an empty
(zero-length) cookie or potentially one cached
from a prior exchange
▶ A server that is unable to verify the incoming
cookie and wishes to establish the liveness of
the DTLS client sends a
HelloVerifyRequest message
▶ Contains a cookie, that should be
generated in such a way that it does not
require keeping state on the server
DTLS Handshake Protocol Message Format ▶ Example, the cookie can be generated from
Figure Source: [Modadugu and Rescorla, 2004]
a keyed hash of the client IP address, using
a global key
DTLS Handshake Protocol (3)
▶ Servers that are willing to resume sessions
can skip the cookie exchange phase if a valid
session ID is presented by the client
▶ Servers that do not support session
resumption is to maintain a cache of recent
(client, cookie) pairs, so that cookie exchange
can be skipped if a match is made on the first
ClientHello
▶ Client sends the ClientHello with same
parameters but adds the received cookie
DTLS Handshake Protocol
Figure Source: [Roepke et al., 2016]
DTLS Handshake Protocol (4)
▶ In the second round, server responds with
multiple messages
▶ ServerHello message
▶ Certificate message for server
authentication (optional)
▶ ServerKeyExchange message containing a
RSA public key (if the server has no
certificate or the certificate is only for
signing)
▶ CertificateRequest message to request
client certificates
▶ ServerHelloDone message indicates no
other message is to be expected after this
DTLS Handshake Protocol
Figure Source: [Roepke et al., 2016]
DTLS Handshake Protocol (5)
▶ If the client received a certificate of the
server, verifies it
▶ If the client received a
CertificateRequest message from the
server, it sends its certificates
▶ ClinetKeyExchange message contains a
pre-master secret encrypted with servers
public key. If no certificate was sent by
the server, the public key in the
ServerKeyExchange message is used to
encrypt the pre-master secret.
▶ Both the client and server computes a
master secret from the pre-master secret
from which they derive the keys for the
chosen cipher suite.
▶ If the client only has signing certificate, it
DTLS Handshake Protocol sends a CertificateVerify message
Figure Source: [Roepke et al., 2016]
containing a signed hash over all
previously transmitted handshake
messages sent. This way, the server can
verify the authenticity of the client.
Timeout and Retransmission
▶ DTLS handshake messages may be lost
▶ DTLS implements a state machine for
re-transmission using a single timer at each
endpoint
▶ Each end-point keeps retransmitting its last
message until a reply is received.
▶ An endpoint continues to retransmit its last
message until a response is received or a
maximum timer value is reached
Timer State Machine
Figure Source: [Modadugu and Rescorla, 2004]
.
DTLS ChangeCipherSpec Protocol
▶ The purpose of the ChangeCipherSpec message is to commit
to the agreed cipher suite. It is sent in the third round of the
handshake protocol.
▶ The Finished message contains a message authentication
code (MAC) of the previous handshake messages encrypted
with the agreed cipher suite.
▶ When receiving the Finished message, the server changes its
cipher suite and acknowledges it too.
▶ To finalize the handshake, the server sends a Finished
message like the client did before.
▶ Both Finished messages, contain a MAC over all sent
messages computed with the master secret.
▶ If the MAC values are equal, the handshake was successful
and both parties can begin transmitting application data.
DTLS Handshake Message Ordering and Fragmentation
▶ Handshake messages may be fragmented
when they are larger than PMTU
▶ Handshake message header contains the
▶ Overall message length
▶ A message sequence number (MSN)
▶ Fragment offset (frag offset) and its length
(frag length)
▶ Fragmentation is only supported for
handshake messages
DTLS Alert Messages
▶ DTLS reuses all of the TLS alerts
▶ Most TLS alerts signal the end of the connection–either
graceful or abortive–and therefore no data should come after
them
References I
Modadugu, N. and Rescorla, E. (2004).
The design and implementation of datagram TLS.
In Proceedings of the Network and Distributed System Security Symposium,
NDSS 2004, San Diego, California, USA. The Internet Society.
Roepke, R., Thraem, T., Wagener, J., and Wiesmaier, A. (2016).
A survey on protocols securing the internet of things: Dtls, ipsec and ieee
802.11i.
Technical report, TU Darmstadt, Darmstadt.
