IETF Logo Mail Archive

Re: [Perc] Last Call: <draft-ietf-perc-private-media-framework-08.txt> (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard

Cullen Jennings <fluffy@iii.ca> Thu, 14 February 2019 23:10 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F203012F1A5 for <ietf@ietfa.amsl.com>; Thu, 14 Feb 2019 15:10:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 i-UDPhjbuorT for <ietf@ietfa.amsl.com>; Thu, 14 Feb 2019 15:10:55 -0800 (PST)
Received: from smtp78.iad3a.emailsrvr.com (smtp78.iad3a.emailsrvr.com [173.203.187.78]) (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 22E521289FA for <ietf@ietf.org>; Thu, 14 Feb 2019 15:10:54 -0800 (PST)
Received: from smtp34.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp34.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0C1A824C39; Thu, 14 Feb 2019 18:10:54 -0500 (EST)
X-Auth-ID: fluffy@iii.ca
Received: by smtp34.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 1479024BB7; Thu, 14 Feb 2019 18:10:52 -0500 (EST)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 14 Feb 2019 18:10:53 -0500
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: [Perc] Last Call: <draft-ietf-perc-private-media-framework-08.txt> (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <8136dee9-74c9-8ac1-3cb8-f18f08b1ff3b@gmail.com>
Date: Thu, 14 Feb 2019 16:10:51 -0700
Cc: Nils Ohlmeier <nohlmeier@mozilla.com>, Emil Ivov <emcho@jitsi.org>, IETF Crazy <ietf@ietf.org>, Emad Omara <emadomara@google.com>, perc@ietf.org, Harald Alvestrand <hta@google.com>, Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io>, Lorenzo Miniero <lorenzo@meetecho.com>, Bernard Aboba <bernard.aboba@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FFB5A169-46FD-4AD2-BE12-EFA145BFE73E@iii.ca>
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com> <CAOW+2dtxnSYOPPWxodN633O=dPOQaUnu7eYvgUYkPYRt6iWbaw@mail.gmail.com> <CAPvvaaK_VUXvy2=1TBGfBWWYxiBdXBzuR=Y-rnAdJyg=M8OfQQ@mail.gmail.com> <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com> <C6FEAEB9-CF8E-48AF-B03F-1406FF9CB303@cosmosoftware.io> <CAOW+2ducgj400pk3xPFAkRYxnYvqwhMsE9rOO0u9PgLpniaaRA@mail.gmail.com> <CAPvvaaLYFeNkZ4Pfdh4pa2btNW6EGZBnAOvXzVZ9egU8V-gBNQ@mail.gmail.com> <CAOW+2dvom822NgjF7OAa2A8YDeqZ+mbCqA=fUcq-Y49oFyGpsA@mail.gmail.com> <CAPvvaa+EzwgMXB_t7ZVTBgZH2y4=neUm1RymUNKnMV-6zyGPaQ@mail.gmail.com> <a74a8239-27dc-5704-096b-05cc5e02bd18@gmail.com> <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> <CAPvvaaJDo6vYj00NMVQEKHnrMHr1EoQydTsZ+7WtdEgyoy_GAQ@mail.gmail.com> <1F1100AC-B9D2-4650-8663-A6D380721688@mozilla.com> <8136dee9-74c9-8ac1-3cb8-f18f08b1ff3b@gmail.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/HwJZLarSisBHX3T4FMlv0qbCU0g>
X-Mailman-Approved-At: Sun, 17 Feb 2019 19:46:41 -0800
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2019 23:10:57 -0000



> On Feb 13, 2019, at 5:03 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
> 
> On 13/02/2019 23:48, Nils Ohlmeier wrote:
>> While implementation convenience was part of the discussion it was raised a few times that the people in favor of allowing SSRC mutability never provided any written description of why mutating the SSRC is not a problem as pointed out by the design team.
>> 
> Moreover, in the (maybe not so) near future of ssrc-less signaling (at least in webrtc), where the MID extensions are HBH, how would ssrc rewriting even be a potential risk?
> 
> Has this group analyzed the implications and new attacks that this may cause?
> 
> Best regards
> 
> Sergio


I know you understand this stuff too well to really believe what you just wrote so it comes across as feeling like FUD. You know that most WebRTC does not use any SSRC in the signaling at all and the WebRTC security dose not change if the ssrc are signaled or not. 

Has it been analyzed? YES OF COURSE IT HAS - the whole of webrtc security drafts and security section of of the related WebRTC drafts are written based on the security being ssrc-less signaling.

v2.23.0 | Report a Bug | By Email