5. Security Considerations

This document describes a method for establishing SRTP keys using DTLS. The security properties of the final SRTP session are determined by the combination of DTLS and SRTP.

5.1 Security of the DTLS Handshake

The security of the keying material depends entirely on the security of the DTLS handshake. If an attacker can compromise the DTLS handshake (e.g., through a man-in-the-middle attack), they can obtain the SRTP master key and authenticate and decrypt all SRTP traffic.

Therefore, it is critical that:

The DTLS implementation is secure and free from vulnerabilities
Strong cipher suites are used
The endpoints properly authenticate each other's certificates
The certificates are properly validated

5.2 Packet Routing and Multiplexing

DTLS-SRTP implementations MUST properly demultiplex incoming packets between:

DTLS packets (handshake and alert messages)
SRTP packets (encrypted media)
SRTCP packets (encrypted control)
STUN packets (NAT traversal)

Failure to properly distinguish between these packet types could lead to security vulnerabilities. The demultiplexing algorithm is based on the first byte of the packet and is designed to be unambiguous.

5.3 Replay Protection

SRTP includes replay protection mechanisms. However, DTLS-SRTP implementations MUST ensure that DTLS record sequence numbers are not reused across rekeying operations to prevent replay attacks.

5.4 Confidentiality and Authentication

DTLS-SRTP provides both confidentiality (through encryption) and authentication (through message authentication codes). Both properties are essential for secure media transmission. Implementations SHOULD NOT use SRTP protection profiles that provide only one of these properties unless there are specific application requirements that justify doing so.

5.5 Perfect Forward Secrecy

DTLS can provide perfect forward secrecy (PFS) if appropriate key exchange algorithms are used (e.g., ephemeral Diffie-Hellman). When PFS is important, implementations SHOULD use cipher suites that provide this property.

5.6 Identity Binding

The identity authenticated in the DTLS handshake SHOULD be cryptographically bound to the identity used in the signaling channel to prevent various forms of identity misbinding attacks.