[AVTCORE] Re: cryptex questions

[Sergio Garcia Murillo <[e-mail]>]

Hi Philipp,

Yes, that is my reading too.

Negotiating both mechanisms means that the receiver is able to handle both
formats. It does not mean that the sender should apply both, and in fact
RFC 9335 explicitly says:

Peers MAY negotiate both Cryptex and the Encryption of Header Extensions
mechanism defined in [RFC6904
<https://datatracker.ietf.org/doc/html/rfc6904>] via SDP offer/answer as
described in Section 4
<https://datatracker.ietf.org/doc/html/rfc9335#sdp-considerations>, and if
both mechanisms are supported, either one can be used for any given packet.
However, if a packet is encrypted with Cryptex, it MUST NOT also use header
extension encryption [RFC6904
<https://datatracker.ietf.org/doc/html/rfc6904>], and vice versa.
So if the peer has advertised support for both Cryptex and RFC6904 for that
extension, the sender should normally send the extension under Cryptex,
rather than wrapping that individual extension with RFC6904.

For this concrete case, I would negotiate both the rfc6904 and the plain
header extensions ids and cryptex, then if cryptex is available, send the
plain header id on a cryptex encrypted packet, and if cryptex is not
available, send the rfc6904 encrypted one.

Best,
Sergio

On Wed, Apr 22, 2026 at 3:15 PM Philipp Hancke <philipp.hancke=
[e-mail]> wrote:

> I came up with one more question.
>
> For context, libWebRTC introduced a "corruption detection" extension
> described in
>
> https://datatracker.ietf.org/doc/html/draft-sprang-avtcore-corruption-detection-01
> Since this extension should not be sent unencrypted WebRTC would currently
> only offer the encrypted variant of this, i.e.
>   a=extmap:11 urn:ietf:params:rtp-hdrext:encrypt
> http://www.webrtc.org/experiments/rtp-hdrext/corruption-detection
> Now with cryptex this might end up negotiating both encryption variants.
>
> https://www.rfc-editor.org/rfc/rfc9335.html#section-5 says
>   If one of the peers has advertised the ability to receive both Cryptex
> and header extensions encrypted as per [RFC6904] in the SDP exchange, it is
> RECOMMENDED
>   that the other peer use Cryptex rather than the mechanism in [RFC6904]
> when sending RTP packets so that all the header extensions and CSRCS are
> encrypted
>
> which I interpret as
>   "use cryptex, even if you did negotiate the extension and the RFC 6904
> variant including "urn:ietf:params:rtp-hdrext:encrypt" should be
> negotiated  in the SDP.
>
> Is that correct?
>
> Am Mo., 16. März 2026 um 07:57 Uhr schrieb Harald Alvestrand <
> [e-mail]>:
>
>> There is one scenario where applications want to control whether cryptex
>> is used or not independently of whether the endpoints support it:
>>
>> It's when there's an intermediate RTP-forwarding relay that does *not*
>> terminate the RTP session (and therefore doesn't participate in the SDP
>> offer/answer function) depends for its function on inspecting RTP header
>> extensions (such as a forwarder that is capable of dropping layers out of a
>> SVC encoded video).
>>
>> In that case, even though both ends of the SDP offer/answer support
>> cryptex, cryptex needs to be turned off.
>>
>> Do such relays exist?
>> On 3/15/26 22:20, Philipp Hancke wrote:
>>
>> Thanks Sergio for pointing that out! This means the W3C API needs to
>> account for this though. I read
>>
>> https://w3c.github.io/webrtc-extensions/#rtp-header-extension-encryption-policy
>> as "mandatory to negotiate", not "mandatory to use".
>>
>> This should be possible to clarify, in particular since no browser
>> shipped that yet.
>>
>> Am So., 15. März 2026 um 21:47 Uhr schrieb Sergio Garcia Murillo <
>> [e-mail]>:
>>
>>> Hi Philipp,
>>>
>>> I think this case is already considered in the RFC:
>>>
>>> 5.2. Receiving
>>> When receiving an RTP packet that contains header extensions, the
>>> "defined by profile" field MUST be checked to ensure the payload is
>>> formatted according to this specification. If the field does not match one
>>> of the values defined above, the implementation MUST instead handle it
>>> according to the specification that defines that value.
>>>
>>> Alternatively, if the implementation considers the use of this
>>> specification mandatory and the "defined by profile" field does not match
>>> one of the values defined above, it MUST stop the processing of the RTP
>>> packet and report an error for the RTP stream.
>>>
>>> I would say that a "sane" implementation of cryptex would always be
>>> sending the RTP headers encrypted if the other receiving side supports it.
>>> For WebRTC I would reject any non header encrypted packet if the header
>>> encryption is set to "require", and maybe allow receiving them on
>>> "negotiate".
>>>
>>> Best regards
>>> Sergio
>>>
>>> El mar, 10 mar 2026, 21:16, Philipp Hancke <philipp.hancke=
>>> [e-mail]> escribió:
>>>
>>>> (too later for the next IETF but I hope that list discussion will
>>>> clarify things)
>>>>
>>>> https://github.com/pion/webrtc/pull/3357#discussion_r2838855495
>>>> raised a few interesting questions.
>>>>
>>>> https://www.rfc-editor.org/rfc/rfc9335.html#name-sdp-considerations
>>>> says that it is possible to disable cryptex in a session. I.e. the
>>>> following renegotiation test should pass:
>>>>    O: cryptex
>>>>    A: no cryptex
>>>>    O: cryptex
>>>>    A: cryptex
>>>>    O: cryptex
>>>>    A: no cryptex
>>>> To me that seems like a downgrade attack but then cryptex is
>>>> "declarative" and senders can unilaterally decide not to use it.
>>>>
>>>> This poses a problem for the W3C WebRTC API described in
>>>>
>>>> https://w3c.github.io/webrtc-extensions/#rtp-header-extension-encryption
>>>> The API there describes the negotiation of the envelope.
>>>> It does not allow telling whether encryption was used (on the receiving
>>>> side) or let a sender control whether it is used.
>>>> But if negotiation is required and the sender chooses not to use
>>>> cryptex, what happens?
>>>>
>>>> I assume that receivers capable of cryptex will unconditionally process
>>>> packets accordingly so in-flight packets during renegotiation are not an
>>>> issue at least.
>>>>
>>>> Most of these problems should disappear if you can not change your mind
>>>> on whether to use encryption once it is established that the peer does
>>>> support cryptex.
>>>>
>>>> Thoughts?
>>>>
>>>> Philipp
>>>> _______________________________________________
>>>> Audio/Video Transport Core Maintenance
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> To unsubscribe send an email to [e-mail]
>