[AVTCORE] Notes from SRTP Header Encryption Side Meeting.

Cullen Jennings <fluffy@iii.ca> Thu, 30 July 2020 17:44 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1395B3A1096 for <avt@ietfa.amsl.com>; Thu, 30 Jul 2020 10:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnQzST_69guh for <avt@ietfa.amsl.com>; Thu, 30 Jul 2020 10:44:07 -0700 (PDT)
Received: from smtp120.ord1d.emailsrvr.com (smtp120.ord1d.emailsrvr.com [184.106.54.120]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70E93A1086 for <avtcore@ietf.org>; Thu, 30 Jul 2020 10:44:07 -0700 (PDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp24.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 030AFA03E6; Thu, 30 Jul 2020 13:44:06 -0400 (EDT)
From: Cullen Jennings <fluffy@iii.ca>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
Date: Thu, 30 Jul 2020 11:44:06 -0600
Message-Id: <5DA92063-55EF-4CB4-A299-2375575A7D11@iii.ca>
To: avtcore@ietf.org
X-Mailer: Apple Mail (2.3445.104.15)
X-Classification-ID: 7a406ad4-4777-4e62-a0e8-6f554fad2c4a-1-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/tUZjCTEk3szF3cTptQlMMkJk95I>
Subject: [AVTCORE] Notes from SRTP Header Encryption Side Meeting.
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2020 17:44:09 -0000

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.