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

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 <fluffy@iii.ca 
> <mailto:fluffy@iii.ca>> wrote:
>
>
>     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.
>
>
>
>
>
>
>     _______________________________________________
>     Audio/Video Transport Core Maintenance
>     avt@ietf.org <mailto:avt@ietf.org>
>     https://www.ietf.org/mailman/listinfo/avt
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt