Skip to main content

5. Security Considerations

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:

  1. The DTLS implementation is secure and free from vulnerabilities
  2. Strong cipher suites are used
  3. The endpoints properly authenticate each other's certificates
  4. 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.