DTLS is not recommended for Media Keep-Alive usage because sending STUN Binding Indications in a separately negotiated non-SRTP DTLS session alongside DTLS-SRTP would add overhead with minimal security benefit.

tls, rtp, realtime

DTLS is not recommended for the Connectivity Check usage because adding DTLS on top would delay and impair the ICE process. MESSAGE-INTEGRITY already protects STUN responses against injection attacks without requiring the overhead of DTLS.

tls, nat, webrtc

DTLS-over-UDP offers the same security advantages as TLS-over-TCP but without TCP's undesirable properties for real-time communications. TCP (and TLS-over-TCP) is not optimal when STUN is used to support multimedia sessions, which is its originally intended purpose.

tls, nat, realtime

The TURN resolution mechanism (RFC 5928) is updated to recognize 'dtls' as an acceptable transport name value and to map <secure>=true plus <transport>='udp' to the DTLS TURN transport with default port 5349.

tls, nat, dns

The usage of 'udp' as a transport parameter with the 'stuns' URI scheme (for STUN over DTLS) and the 'turns' URI scheme (for TURN over DTLS) does not introduce security issues beyond those discussed in RFC 7064 and RFC 7065 respectively.

tls, nat, dns

A STUN server implementing the NAT Discovery usage with DTLS MUST implement the denial-of-service countermeasure described in Section 4.2.1 of RFC 6347.

tls, security, nat

A TURN server using DTLS MUST implement the denial-of-service countermeasure described in Section 4.2.1 of RFC 6347. TCP allocations MUST NOT be obtained using a DTLS association between client and server.

tls, security, nat

By default, STUN over DTLS MUST use port 5349. When using SRV records, the service name MUST be set to 'stuns' and the protocol name to 'udp'.

tls, dns

Classic STUN (RFC 3489) defines only UDP as a transport, and DTLS MUST NOT be used with it. Any STUN request or indication without the magic cookie over DTLS MUST always result in an error.

tls, security

Future STUN usages MUST take into account DTLS as a transport and discuss its applicability, and MUST explicitly state if implementing the denial-of-service countermeasure in Section 4.2.1 of RFC 6347 is mandatory.

tls, security

Implementations of STUN over DTLS MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, replacing TLS_RSA_WITH_AES_128_CBC_SHA as the default cipher suite used for STUN over TLS.

tls, crypto, security

In the TURN resolution mechanism, if <secure> is true and <transport> is 'udp' but the application does not support DTLS, the resolution MUST stop with an error. If <secure> is true and <transport> is not defined but neither TLS nor DTLS is supported, resolution MUST stop with an error.

tls, dns, nat

Perfect Forward Secrecy (PFS) cipher suites MUST be preferred over non-PFS cipher suites. Cipher suites with known weaknesses such as those based on (single) DES and RC4 MUST NOT be used. Implementations MUST disable TLS-level compression.

tls, crypto, security

Secure transports like STUN over TLS and STUN over DTLS MUST use the 'stuns' URI scheme. A STUN URI containing an IP address MUST be rejected unless the domain name is provided by the same mechanism that provided the STUN URI.

tls, dns, security

Secure TURN transports (TURN over TLS and TURN over DTLS) MUST use the 'turns' URI scheme. When using 'turns' to designate TURN over DTLS, the transport value of the TURN URI, if set, MUST be 'udp'.

tls, dns, nat

STUN over DTLS MUST use the same retransmission rules as STUN over UDP (Section 7.2.1 of RFC 5389) and MUST use the same rules in Section 7.2.2 of RFC 5389 to verify server identity.

tls, dns, security

A new S-NAPTR application protocol tag 'turn.dtls' is defined for use in TURN resolution, mapping the combination of <secure>=true and <transport>='udp' to the DTLS TURN transport.

tls, dns, nat, registry

This document adds DTLS as a fourth valid transport for STUN, complementing the existing UDP, TCP, and TLS transports defined in RFC 5389.

tls, nat

This document adds DTLS/UDP as a valid combination for TURN, complementing the existing UDP/UDP, TCP/UDP, and TLS/UDP combinations defined in RFC 5766.

tls, nat

IANA S-NAPTR Application Protocol Tags registry updated with new tag 'turn.dtls' for TURN over DTLS, as defined in Section 4.6.2 of this document.

registry, dns, nat

IANA Service Names and Transport Protocol Port Numbers registry entry for 'turns' (port 5349/udp) updated from 'Reserved for a future enhancement of TURN' (RFC 5766) to 'TURN over DTLS' (RFC 7350).

registry, nat

STUN over DTLS does not introduce any specific security considerations beyond those for STUN over TLS detailed in RFC 5389. Similarly, TURN over DTLS does not introduce considerations beyond those for TURN over TLS in RFC 5766. The new S-NAPTR tag and TURN resolution modifications do not introduce additional considerations beyond RFC 5928.

tls, security, nat

When the path MTU is unknown, STUN messages over DTLS must be adjusted to account for the 13-byte DTLS Record header, the MAC size, and the padding size, in addition to the path MTU rules in Section 7.1 of RFC 5389.

tls, nat