[AVTCORE] Notes from SRTP Header Encryption Side Meeting.

[Cullen Jennings <[e-mail]>]

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.