Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items

Jonathan Lennox <jonathan@vidyo.com> Fri, 14 October 2016 15:03 UTC

Return-Path: <prvs=4095d6e134=jonathan@vidyo.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208AC12983C for <rtcweb@ietfa.amsl.com>; Fri, 14 Oct 2016 08:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.896
X-Spam-Level:
X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.496, SPF_PASS=-0.001] autolearn=no 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 EJp7OrZ8dr1J for <rtcweb@ietfa.amsl.com>; Fri, 14 Oct 2016 08:03:07 -0700 (PDT)
Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE8F129831 for <rtcweb@ietf.org>; Fri, 14 Oct 2016 08:03:00 -0700 (PDT)
Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9EExFF0016712; Fri, 14 Oct 2016 11:02:57 -0400
Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 2615ba2563-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Oct 2016 11:02:57 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Fri, 14 Oct 2016 10:02:55 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: Cullen Jennings <fluffy@cisco.com>
Thread-Topic: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items
Thread-Index: AQHSJX1b6MtzUuyRZUS84VuzdzWIraCn4VEAgABOwoCAADDZgA==
Date: Fri, 14 Oct 2016 15:02:56 +0000
Message-ID: <AD4526C1-A878-471E-8713-A7DF1813027D@vidyo.com>
References: <e536bad2-08b1-4f77-8c75-6bc3b639c398@ericsson.com> <998B7677-E967-45B0-8FE5-FD71930C380F@cisco.com> <dca597f3-e23a-3dc6-f0e0-5c588729d7e1@ericsson.com> <3C0E8E83-3623-4D5C-A093-B26981F13477@cisco.com>
In-Reply-To: <3C0E8E83-3623-4D5C-A093-B26981F13477@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [160.79.219.114]
Content-Type: multipart/alternative; boundary="_000_AD4526C1A878471E8713A7DF1813027Dvidyocom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-14_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610140268
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/uWGURbhEN6f4zDVy3QHEXZbcSbY>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Mandating encryption of RTP header extensions for MID and RID SDES items
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2016 15:03:12 -0000

On Oct 14, 2016, at 9:08 AM, Cullen Jennings (fluffy) <fluffy@cisco.com<mailto:fluffy@cisco.com>> wrote:

So the audio levels are recommended in WebRTC but this MID stuff is a very generic mechanism that will like be broadly used to deal with RTP lack of extensibility of size PT space. Lot of stuff does not implement audio levels and some stuff that implements it does not encrypt it. The 6904 mechanism is not exactly elegant, not easy to implement, and doubles the size the headers which is not great for audio. I think it is fair to say we might do it differently if doing it over again.

Not elegant is a matter of taste, but I have to disagree with your other two claims about 6904.

It doesn’t expand the size of the RTP header extensions at all, over what standard 5285 header extensions do. (Now, 5285 itself is fairly space-wasteful, but that’s a separate issue.)

And I don’t think it was very hard to implement, either — the patch to add it to libsrtp is only 800 lines of code (https://github.com/cisco/libsrtp/commit/ce37ef61444400370f699c44985949ba44557d00), more than half of which is test cases.

Are you actually criticizing the 5285 mechanism itself?

—
Jonathan Lennox
jonathan@vidyo.com<mailto:jonathan@vidyo.com>