Layer 6 · Security · TLS for traffic that cannot wait

DTLS

Datagram Transport Layer Security

DTLS is TLS with TCP’s assumptions removed. TLS needs an ordered, reliable stream; datagram traffic has neither. DTLS adds sequence numbers and its own retransmission to the handshake, makes each record independently decryptable, and lets a lost packet stay lost.

DTLS gives UDP TLS-grade encryption without demanding reliability — each record stands on its own.

Operates at

Layer 6

over UDP

Port

The app’s own

no port of its own

Based on

TLS

1.2 and 1.3

Used by

WebRTC

and CoAP, and VPNs

How it works

What had to change to run TLS over datagrams

1 · The handshake retransmits itself

TCP used to guarantee the handshake arrived. DTLS numbers its own handshake messages and retransmits any that go unanswered.

2 · A cookie stops amplification

The server answers a ClientHello with a HelloVerifyRequest carrying a cookie; only a client that echoes it is real.

Nothing is allocated and no large response is sent until that address is proven.

3 · Records are independent

Each record carries an explicit sequence number and can be decrypted alone. A dropped datagram costs one record — it does not desynchronise the cipher.

That last change is the whole point: TLS over UDP without it would break permanently on the first lost packet. With it, DTLS can carry real-time media that would rather drop a frame than wait.

The main points

What DTLS does, step by step

Hello, then a cookie

The client’s ClientHello is answered with a cookie it must echo — proving its source address is real.

Complete the handshake

The rest proceeds as TLS, with DTLS numbering and retransmitting messages that go missing.

Protect each record

Every record gets an explicit sequence number so it can be decrypted independently of the others.

Tolerate loss

Missing records are simply absent; a replay window catches duplicates and old packets.

Where you meet it

WebRTC — DTLS-SRTP keys every browser call

CoAP — securing constrained IoT devices

OpenVPN / AnyConnect — UDP-mode VPNs

In cybersecurity

DTLS inherits TLS’s cryptography and its configuration mistakes alike — plus the amplification risk that comes with answering UDP at all.

Always require the cookie

Skipping HelloVerifyRequest turns the server into a DDoS amplifier for spoofed sources.

Replay protection

The sliding receive window must be enabled, or an old captured record can be replayed.

Same cipher hygiene

DTLS 1.3, modern AEAD suites, and no version older than 1.2.

Certificate validation

As with TLS, a chain not checked against a trusted root proves nothing at all.

Fragmentation care

Handshake messages larger than the MTU are fragmented by DTLS itself — a known source of bugs.

Constrained devices

IoT stacks often ship weak defaults; pre-shared keys must still be long and unique.

Rides in the stack

IPUDPDTLSSRTP, CoAP, …

It has no port of its own — DTLS secures whatever UDP port the application it protects already uses.

Works with

TLS UDP WebRTC

TLS or DTLS?

TLSDTLS

TransportTCPUDP

Lost packetTCP resendsRecord is gone

Handshake lossTCP handles itDTLS retransmits

Anti-amplificationNot neededCookie required