Encryption of Header Extensions in SRTP [RFC6904] was proposed in 2013 as a solution to the problem of unprotectedheader extension values. However, it has not seen significant adoption andhas a few technical shortcomings.¶
First, the mechanism is complicated. Since it allows encryption to benegotiated on a per-extension basis, a fair amount of signaling logic isrequired. And in the SRTP layer, a somewhat complex transform is requiredto allow only the selected header extension values to be encrypted. One ofthe most popular SRTP implementations had a significant bug in this areathat was not detected for five years.¶
Second, the mechanism only protects the header extension values and not their identifiers orlengths. It also does not protect the CSRCs. As noted above, this leavesa fair amount of potentially sensitive information exposed.¶
Third, the mechanism bloats the header extension space. Because each extension mustbe offered in both unencrypted and encrypted forms, twice as many headerextensions must be offered, which will in many cases push implementationspast the 14-extension limit for the use of one-byte extension headersdefined in [RFC8285]. Accordingly, in many cases, implementations will need to usetwo-byte headers, which are not supported well by someexisting implementations.¶
Finally, the header extension bloat combined with the need for backwardcompatibility results in additional wire overhead. Because two-byteextension headers may not be handled well by existing implementations,one-byte extension identifiers will need to be used for the unencrypted(backward-compatible) forms, and two-byte for the encrypted forms.Thus, deployment of encryption for header extensions [RFC6904] willtypically result in multiple extra bytes in each RTP packet, comparedto the present situation.¶