The DTLS protocol ([RFC 6347]) is based on TLS protocol to provide similar security for the network traffic transported on datagram transport protocols (e.g. UDP). Usually the real time applications like media streaming and internet telephony are delay sensitive for the transported data so they use datagram transport to carry their data. DTLS runs on UDP to secure the data in a transparent way (inserted between the application layer and transport layer). DTLS runs in application space without any kernel modifications. The DTLS preserves the in-order delivery of data which is not provided by the datagram transport. Current version of DTLS is 1.2
Why DTLS and NOT TLS for Datagram Transport
The answer is simply because using datagram transport like UDP means the packets could be lost or reordered and TLS cannot handle this (this is handled by TCP when it is used). So we take the TLS and add minimal changes to fix the unreliability problem and we call the result DTLS.
More specifically, the problems that are in TLS if datagram transport are used:
- In TLS there is what is called integrity check which depends on the sequence number. For example record N is lost –> then the integrity check on record N+1 will fail because the wrong sequence number. The sequence numbers are implicit in the records. The record could also reach but in a wrong order. For example record N+1 reached before the record N.
- The record could reach many times (replayed).
- The TLS handshake will break if the handshake messages are lost.
- Handshake message size is big (many kilobytes): as we know in UDP, datagrams are limited to 1500 bytes.
So the goal is changing TLS to solve the above problems and then we get DTLS. Briefly DTLS solves the problems by:
- Banning the stream ciphers to make the records independent (don’t have the same cryptographic context – cipher key).
- Adding explicit sequence numbers in the records.
- Using retransmission timer for packet loss handling.
- Handshake message fragmentation –> Each DTLS handshake message must contain fragment offset and fragment length.
- Maintaining a bitmap window of received records so if a record is previously received it will be discarded.
The client automatically generates self-signed certificates for each peer. This means there is no certificate chain verification. The certificates themselves cannot be used to authenticate the peer because they are self-signed. So the DTLS provides encryption and integrity, but let the authentication to be done by the application.
Library Support For DTLS 1.2