[AVTCORE] Re: cryptex questions

[Philipp Hancke <[e-mail]>]

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]
>