Subject: [AVTCORE] Notes from SRTP Header Encryption Side Meeting.

From: Cullen Jennings <[email-masked]>
Date: Thu, 30 Jul 2020 11:44:06 -0600

Conclusion from the call:
—————————————

Option C1 from Justin's slides of encrypt CCRC plus stuff after header extension length was the option people on call were leaning towards. 

Prefer to negotiate turning this on and off with SDP. (could look at negotiating in DTLS later )

For the WebRTC API could do on WebRTC RTCConfiguration API - or WebRTC extension document HTA is writing. ( RTP Header Extension Parameter ). Or it could be on Transceiver with a header policy. 

Next Steps:
—————————————

Justin and Cullen take stab at SDP / SRTP doc. 

Bernard & Sergio to help draft W3C doc. 

Someone to write a PR for libsrtp. ????

Need to improve testing on this. Need reference vectors in spec. 

Do on avtcore mailing list

Notes from Discussion 
---------------------------

As part of general IETF move towards encryption, there are things in RTP headers we would like to encrypt. 

RFC 6904 exists. Allows negotiation of each header separately. Probably overkill.  RFC 8285 makes it even more complicated. 

Implementors view this as complicated and have not spent time on it. Recent bugs in webrtc / libsrp indicate this is not all easy to do. 

That header IDs are sent as cleartext, it reveals what type of headers you are exchanging, but not the info. 

Audio Level might want to encrypt over DTLS-SRTP particular in use cases in SFrame. 

One proposal is start SRTP payload encryption earlier in packet. Say, do all the headers (if it was negotated course ). 

That leads to encrypt CSRCs, everything from CSRC forward to end of payload. 

That leads to encrypt everything but v=2, seq num, and ssrc. 

So the discussion was about how much of the packet do we encrypt?

Proposal: Encrypt everything from start of CSRC forward. 

Proposal: Encrypt everything but V=2, seq num, ssrc.

Proposal: Encrypt from after the header extension length 

Mo points out people look at header extension length. 

Mo point out setting the x bit to zero for this so things don't try to interpret it. 

Questions about if changing some of fields would cause firewalls to barf on the packets. 

We run into problem of how to send x bit when no header extension in a given packet. 

A key issue with C is what to do if no header extension but do have CSRC.  Possible answer is have to add a null extention to encrypt CCSRC. 

For WebRTC, would be on by default.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 30 Jul 2020 10:51:58 -0700

Thanks Cullen for taking notes. I've created a repo for the SDP/SRTP doc at
https://github.com/juberti/cryptex.

On Thu, Jul 30, 2020 at 10:44 AM Cullen Jennings <[email-masked]> wrote:

> Option C1 from Justin's slides of encrypt CCRC plus stuff after header
> extension length was the option people on call were leaning towards.
>
> For the WebRTC API could do on WebRTC RTCConfiguration API - or WebRTC
> extension document HTA is writing. ( RTP Header Extension Parameter ). Or
> it could be on Transceiver with a header policy.
>
> Next Steps:
> —————————————
>
> RFC 6904 exists. Allows negotiation of each header separately. Probably
> overkill.  RFC 8285 makes it even more complicated.
>
> Implementors view this as complicated and have not spent time on it.
> Recent bugs in webrtc / libsrp indicate this is not all easy to do.
>
> One proposal is start SRTP payload encryption earlier in packet. Say, do
> all the headers (if it was negotated course ).
>
> A key issue with C is what to do if no header extension but do have CSRC.
> Possible answer is have to add a null extention to encrypt CCSRC.
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 30 Jul 2020 22:20:15 +0200

What would be the best way of moving this forward, adding issues to the 
github repo or keep the discussion on the mailing list?

I can volunteer to do the PR against libsrtp too, should we create an 
issue on libsrtp repo for discussing the implementation details?

Best regards
Sergio
On 30/07/2020 19:51, Justin Uberti wrote:
> Thanks Cullen for taking notes. I've created a repo for the SDP/SRTP 
> doc at https://github.com/juberti/cryptex.
>
> On Thu, Jul 30, 2020 at 10:44 AM Cullen Jennings <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     Option C1 from Justin's slides of encrypt CCRC plus stuff after
>     header extension length was the option people on call were leaning
>     towards.
>
>     For the WebRTC API could do on WebRTC RTCConfiguration API - or
>     WebRTC extension document HTA is writing. ( RTP Header Extension
>     Parameter ). Or it could be on Transceiver with a header policy.
>
>     Next Steps:
>     —————————————
>
>     RFC 6904 exists. Allows negotiation of each header separately.
>     Probably overkill.  RFC 8285 makes it even more complicated.
>
>     Implementors view this as complicated and have not spent time on
>     it. Recent bugs in webrtc / libsrp indicate this is not all easy
>     to do.
>
>     That header IDs are sent as cleartext, it reveals what type of
>     headers you are exchanging, but not the info.
>
>     One proposal is start SRTP payload encryption earlier in packet.
>     Say, do all the headers (if it was negotated course ).
>
>     That leads to encrypt CSRCs, everything from CSRC forward to end
>     of payload..
>
>     A key issue with C is what to do if no header extension but do
>     have CSRC.  Possible answer is have to add a null extention to
>     encrypt CCSRC.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 30 Jul 2020 14:41:30 -0700

Let's have the discussion on the list, but let's add items to the cryptex
issues list as we define what needs to be done.

I think we'll want an initial draft we can point people at before opening
an issue in the libsrtp repo.

On Thu, Jul 30, 2020 at 1:21 PM Sergio Garcia Murillo <
[email-masked]> wrote:

> Thanks Cullen for taking notes. I've created a repo for the SDP/SRTP doc
> at https://github.com/juberti/cryptex.
>
>> That leads to encrypt CSRCs, everything from CSRC forward to end of
>> payload..
>>
>> A key issue with C is what to do if no header extension but do have
>> CSRC.  Possible answer is have to add a null extention to encrypt CCSRC.
>>
> Audio/Video Transport Core [email-masked]://www.ietf.org/mailman/listinfo/avt
>
>