How is an SRTP protection profile named and chosen in an SDES a=crypto offer versus a DTLS-SRTP use_srtp handshake?
answer
- two registries, two spellings
- text string versus two-byte code
- offer order is preference order
- answer echoes the tag
- server returns exactly one
basics
~20 sSDES names a profile as a text crypto-suite, one per a=crypto line in preference order, and the answerer echoes the tag and suite of the first it supports. DTLS-SRTP lists two-byte SRTPProtectionProfile codes in use_srtp; the server returns one it was offered.
solid answer
~40 sThe same transforms carry two spellings. SDP Security Descriptions (RFC 4568) use crypto-suite strings such as `AES_CM_128_HMAC_SHA1_80` or `AEAD_AES_128_GCM`; DTLS-SRTP (RFC 5764) uses `SRTPProtectionProfile` code points such as `SRTP_AES128_CM_HMAC_SHA1_80 {0x00,0x01}` or `SRTP_AEAD_AES_128_GCM {0x00,0x07}`. In SDES the offerer writes one `a=crypto` line per suite, most preferred first, each with a unique tag; the answerer SHOULD take the first valid one it supports and returns that tag and suite, and the same suite then applies in both directions. If none is acceptable, the media stream MUST be rejected. In DTLS-SRTP the client's `use_srtp` lists profiles in descending preference and the server returns exactly one it was offered; with no shared profile it SHOULD omit `use_srtp`, or alert if that is unacceptable. How keys travel differs too, but that is keying, not naming.
go deeper
Recall that SDES writes the profile as text in an a=crypto line and DTLS-SRTP sends a two-byte code in the use_srtp extension.
Walk through who proposes and who picks in each mechanism, what the SDES tag is for, and what happens when nothing matches.
Translate between the two spellings when reading logs, explain why a 256-bit counter-mode suite exists only on the SDES side, and design offers whose order expresses a real preference.
Treat naming as an observability problem: insist the negotiated profile is recorded consistently across keying paths so policy drift and downgrades are visible across the platform.
## Two namespaces for one set of transforms An **SRTP protection profile** is a named bundle: cipher, master key length, salt length, authentication function and tag length. The cryptography is defined once (RFC 3711, RFC 6188, RFC 7714), but two signalling mechanisms name it differently: - **SDP Security Descriptions (SDES, RFC 4568)** carry a text **crypto-suite** inside an `a=crypto` attribute of the SDP. - **DTLS-SRTP (RFC 5764)** carries a two-byte **`SRTPProtectionProfile`** code point inside the `use_srtp` extension of the DTLS handshake. | Transform | SDES crypto-suite | DTLS-SRTP profile and code point | |---|---|---| | AES-128 counter mode, 80-bit HMAC-SHA1 tag | `AES_CM_128_HMAC_SHA1_80` | `SRTP_AES128_CM_HMAC_SHA1_80` `{0x00,0x01}` | | AES-128 counter mode, 32-bit HMAC-SHA1 tag | `AES_CM_128_HMAC_SHA1_32` | `SRTP_AES128_CM_HMAC_SHA1_32` `{0x00,0x02}` | | NULL cipher, 80-bit HMAC-SHA1 tag | `AES_CM_128_HMAC_SHA1_80` plus the `UNENCRYPTED_SRTP` session parameter | `SRTP_NULL_HMAC_SHA1_80` `{0x00,0x05}` | | AES-128-GCM, 16-octet tag | `AEAD_AES_128_GCM` | `SRTP_AEAD_AES_128_GCM` `{0x00,0x07}` | | AES-256-GCM, 16-octet tag | `AEAD_AES_256_GCM` | `SRTP_AEAD_AES_256_GCM` `{0x00,0x08}` | | AES-256 counter mode, 80-bit tag | `AES_256_CM_HMAC_SHA1_80` | none defined in RFC 6188 | Note the word order flips (`AES_CM_128` versus `AES128_CM`), and RFC 6188 registers its AES-192 and AES-256 counter-mode suites **only as SDES crypto-suites**. An engineer grepping logs for one spelling will miss the other. ## Choosing a profile in SDES The crypto-suite is a negotiated parameter of the SDP offer/answer exchange (RFC 4568 §5.1): 1. The offerer writes one `a=crypto` line per acceptable suite on the media line, each with a **unique decimal tag**, **most preferred first**; a more preferred suite SHOULD be cryptographically stronger. 2. The answerer SHOULD select the **first valid line it supports**, according to its own capabilities and policy. 3. The answer carries the **same tag and crypto-suite** it accepted, plus the answerer's own key; the same crypto-suite MUST be used in the send and receive directions. 4. If no offered line is valid and supported, the offered media stream **MUST be rejected**. The tag matters because one media line can offer several lines with the same suite but different keys or parameters; the tag says which one was taken. Key carriage in `inline:` key-params and its exposure to the signalling path belong to keying, not to the profile. ## Choosing a profile in DTLS-SRTP 1. The DTLS client sends `use_srtp` with `SRTPProtectionProfiles`, a list **in descending order of preference**, plus an optional `srtp_mki`. 2. A server willing to use SRTP returns `use_srtp` with **a single profile** it has chosen; it **MUST NOT** select one the client did not offer. RFC 5764 lists the client's order as preference but does not oblige the server to take the first entry. 3. With **no shared profile**, the server SHOULD NOT return `use_srtp`, and the connection falls back to the negotiated DTLS cipher suite with no SRTP keys; if that is unacceptable, the server SHOULD send a DTLS alert. The profile also fixes how much keying material the DTLS exporter must produce, because master key and salt lengths differ by profile; that derivation is a keying subject. ## What the name does and does not carry - **Carries:** cipher, key length, salt length, authentication function, tag length, and (for `_32`) the separate 80-bit RTCP tag. - **Does not carry in DTLS-SRTP:** replay window size or FEC order; RFC 5764 uses the defaults and needs a separate specification to change them. - **Carried beside it in SDES:** key lifetime and MKI ride in the key-params, and session parameters such as `UNENCRYPTED_SRTP` modify the suite. Lifetimes are a place where the documents read differently. RFC 3711 and RFC 4568 allow 2^48 SRTP packets and 2^31 SRTCP packets per master key, whichever comes first; RFC 5764 lists `maximum_lifetime: 2^31` for each of its profiles, and RFC 7714 restates the 2^48 and 2^31 pair for GCM. Because SRTP and SRTCP keys come from one master key by default, the 2^31 SRTCP limit is the one that binds in practice. WebRTC removes one variable altogether: RFC 8827 forbids an MKI. ## Operator takeaways - Order your offer deliberately: in SDES the answerer follows your order; in DTLS-SRTP the server need not. - Record the negotiated profile per call in both spellings, so a silent downgrade to a weaker suite is visible. - A failed match surfaces differently: a rejected media line in SDES, a missing `use_srtp` or an alert in DTLS-SRTP. - When a peer offers only profiles your policy refuses, failing the media line is the correct outcome, not a bug to work around.
- Why might an SDES offer name AES_256_CM_HMAC_SHA1_80 while a DTLS-SRTP endpoint that wants a 256-bit key picks a GCM profile instead?RFC 6188 registers its AES-192 and AES-256 counter-mode suites only as SDES crypto-suites and defines no `SRTPProtectionProfile` code point for them. On DTLS-SRTP the 256-bit profile RFC 7714 defines is `SRTP_AEAD_AES_256_GCM {0x00,0x08}`, so the same intent produces different profiles on the two keying paths.
- In SDES, why must the answer repeat the offer's tag as well as its crypto-suite?One media line may offer several `a=crypto` lines, even with the same crypto-suite and different keys or session parameters. The tag is unique per media line, so echoing it tells the offerer exactly which line was accepted; the suite alone could be ambiguous (RFC 4568 §4.1 and §5.1).
saying these in an interview costs you the question
- SDES and DTLS-SRTP use the same string for the default profile.
- RFC 5764 requires the DTLS-SRTP server to take the client's first listed profile.
- In SDES each direction of a stream may use a different crypto-suite.
- When no DTLS-SRTP profile matches, the media quietly continues as plain RTP.
- The SDES crypto-suite name itself carries the master key.