Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)
Extracted elements (28)
The combination of both the offerer's and answerer's 'tls-id' values is required to uniquely identify a DTLS association because the offerer's value alone may be reused across associations (e.g., in SIP forking, or when an answerer initiates a new association in response to an unchanged offer).
The 'tls-id' attribute was introduced because previously there was no way to explicitly signal in an SDP offer or answer whether a new DTLS association was required. ICE ufrag changes occur for both ICE negotiation and ICE restart, neither of which necessarily requires a new DTLS association, creating ambiguity that the 'tls-id' attribute resolves.
ICE connectivity checks are performed before the DTLS handshake begins. Aggressive nomination (deprecated but still supported for backward compatibility) may mark multiple candidate pairs valid before ICE converges; endpoints must handle this correctly.
When a new DTLS association is established over an unordered transport using ICE, at least one endpoint MUST allocate a completely new set of ICE candidates not recently used for any other DTLS association. An answerer cannot unilaterally initiate a new DTLS association without an ICE restart initiated by the offerer.
When SIP forking occurs, an offerer may receive DTLS ClientHello messages and SDP answers from multiple remote locations. The offerer MUST NOT declare a fingerprint mismatch until it determines that no additional SDP answers will arrive from other remote locations.
Because the offerer inserts 'actpass', it MUST be prepared to receive a DTLS ClientHello from the answerer before the SDP answer arrives. Any data received on the DTLS association before the fingerprint is verified MUST be treated as coming from an unverified source.
Endpoints MUST NOT use the SDP 'setup' attribute value 'holdconn' when negotiating a DTLS association.
Every time an endpoint requests to establish a new DTLS association, the endpoint MUST generate a new local 'tls-id' attribute value. An unchanged local 'tls-id' value combined with non-changed fingerprints indicates reuse of the existing DTLS association.
If an endpoint modifies its local transport parameters and the modification requires a new DTLS association, the endpoint MUST change its local 'tls-id' attribute value. Similarly, if the 5-tuple changes for a transport prohibiting multi-5-tuple DTLS (e.g., SCTP), it MUST change the 'tls-id' value.
If an endpoint uses ICE and modifies a local ufrag value requiring a new DTLS association, the endpoint MUST change its local 'tls-id' attribute value.
If an offer/answer contains a 'connection' attribute with value 'new' and also a 'tls-id' attribute, the 'tls-id' value MUST be new and unique. If 'connection' is 'existing' and the endpoint previously sent a 'tls-id' for the same connection, it MUST reuse that same 'tls-id' value.
If conflicting 'connection' and 'tls-id' attribute values are received, the offerer/answerer MUST process the offer/answer as misformed.
If the answerer receives an offer without a 'tls-id' attribute, the answerer MUST NOT insert a 'tls-id' in the answer.
Implementations wishing to use the 'tls-id' attribute MUST explicitly include it in SDP offers and answers. No default value is defined. If an offer or answer lacks 'tls-id', modifications of DTLS setup role, fingerprint set, or local transport parameters MUST be treated as indication of a new DTLS association.
The certificate received during the DTLS handshake MUST match a certificate fingerprint in the SDP 'fingerprint' attributes per RFC 8122. If fingerprints do not match, an endpoint MUST immediately tear down the media session.
The mux category for the 'tls-id' attribute is 'IDENTICAL', meaning the attribute value applies to all multiplexed media descriptions; to avoid duplication it is only associated with the 'm=' line representing the BUNDLE tag.
The 'tls-id' attribute MUST NOT be defined per source using the SDP 'ssrc' attribute. For RTP-based media, it applies to the whole media description.
The 'tls-id' attribute value MUST be generated using a strong random function and include at least 120 bits of randomness.
When a SIP 'offerless INVITE' results in the receiver generating an offer: if a DTLS association already exists, the offer MUST include the previously assigned 'tls-id' and 'fingerprint' values; if not, the offer is generated as a new offer. In either case, if ICE is used, ICE restart MUST be initiated per RFC 8839.
When an offerer sends a subsequent offer without wanting a new DTLS association, it MUST insert the previously assigned 'tls-id' value, an 'actpass' setup attribute, and fingerprint attributes that do not change the previously sent fingerprint set.
When establishing a new DTLS association over an unordered transport (e.g., UDP), a new 3-tuple (transport/source address/source port) MUST be allocated by at least one endpoint so that DTLS packets for different associations can be demultiplexed.
When generating the initial SDP offer, the offerer MUST insert an SDP 'setup' attribute with 'actpass', one or more 'fingerprint' attributes per RFC 8122, and a 'tls-id' attribute with a unique value.
When the answerer determines a new DTLS association is required, it MUST insert a new unique 'tls-id' in the answer. If the answerer does not accept a new DTLS association that the offer requires, it MUST reject the associated 'm=' lines.
When using the 'tls-id' attribute with TLS (RFC 4145), offerers and answerers MUST ensure that the 'connection' attribute value and the 'tls-id' attribute value do not conflict regarding whether a new TLS connection is to be established. Both attributes MUST always be used together.
The 'tls-id' SDP media-level attribute is defined to uniquely identify a DTLS association or TLS connection. The pair of 'tls-id' attribute values from the offerer and answerer together uniquely identifies the association.
This document registers the 'tls-id' SDP attribute in the 'Session Description Protocol Parameters' registry (Section 8.2.2 of RFC 4566) as a media-level attribute, not subject to charset, with mux category IDENTICAL.
This specification does not modify the security considerations of DTLS or the SDP offer/answer mechanism. The 'tls-id' attribute cannot by itself correlate an SDP offer/answer exchange with a TLS connection setup, so no new security considerations are introduced for that correlation. Certificate fingerprint verification per RFC 8122 remains the authentication mechanism.
The 'tls-id' attribute value syntax is: tls-id-value = 20*255(tls-id-char), where tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_". The value must be between 20 and 255 characters drawn from this base64url-like alphabet.