Re: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt> (WebRTC Data Channels) to Proposed Standard

tim panton <tim@phonefromhere.com> Sat, 11 October 2014 09:59 UTC

Return-Path: <tim@phonefromhere.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9564D1A01E1 for <rtcweb@ietfa.amsl.com>; Sat, 11 Oct 2014 02:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
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 RAB_fMh3NL37 for <rtcweb@ietfa.amsl.com>; Sat, 11 Oct 2014 02:59:22 -0700 (PDT)
Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175AA1A01D8 for <rtcweb@ietf.org>; Sat, 11 Oct 2014 02:59:21 -0700 (PDT)
Received: (qmail 39174 invoked from network); 11 Oct 2014 09:59:19 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 1219
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 11 Oct 2014 09:59:19 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 79B2018A0B9A; Sat, 11 Oct 2014 10:59:19 +0100 (BST)
Received: from [192.168.157.34] (unknown [192.67.4.66]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 3521518A0242; Sat, 11 Oct 2014 10:59:19 +0100 (BST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8428B698-3512-4570-90F9-C5E74B3D6C98"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: tim panton <tim@phonefromhere.com>
In-Reply-To: <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de>
Date: Sat, 11 Oct 2014 10:59:20 +0100
Message-Id: <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com>
References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <CABkgnnWE7czWqi4vQRb5d50N2k95joc_Zcvw6w6g7SOjU9b+9g@mail.gmail.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5o8M79npjENTcnDFVK2ULP1ejd4
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt> (WebRTC Data Channels) to Proposed Standard
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sat, 11 Oct 2014 09:59:24 -0000

On 11 Oct 2014, at 08:41, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:

> On 11 Oct 2014, at 09:21, Wyss, Felix <Felix.Wyss@inin.com> wrote:
> 
>> I'm not looking at this in terms of MitM attacks but for topologies where we want to have back-to-back WebRTC sessions going through a legitimate middlebox.  That middlebox passes the media and data between these sessions while recording and/or performing analytics on it.  Requiring the 
> So doesn't it terminate the DTLS connections of both peers?

Yes, it does. I think the worry is that the middle box may end up as DTLS server to both legs.
That leaves both endpoints as DTLS clients. This then breaks the odd-even split and risks the endpoints allocating
the same stream numbers.

For this to happen you have to have a middle box that offers actpass to both endpoints, agrees to passive 
on both legs and then proceeds to terminate the DTLS but bridge the SCTP. Which only works if it also
re-writes the signalling fingerprints ‘correctly' too.

Tim.


> 
> Best regards
> Michael
>> middlebox to worry about how the two endpoints might pick SCTP stream identifiers and possibly having to map or rewrite them unnecessarily complicates their implementation.  
>> 
>> IMHO from the perspective of the data channels, the DTLS layer should be an opaque tunnel ("bump in the stack") that passes packets between endpoints.  The DTLS role of an endpoint that emerges during connection establishment should not be relevant to the operation of the data channels.  Hence my concerns about the abstraction leak.  
>> 
>> Thanks,
>> --Felix
>> 
>>> -----Original Message-----
>>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>>> Sent: Friday, October 10, 2014 16:34
>>> To: Wyss, Felix
>>> Cc: rtcweb@ietf.org
>>> Subject: Re: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt>
>>> (WebRTC Data Channels) to Proposed Standard
>>> 
>>> On 10 October 2014 12:11, Wyss, Felix <Felix.Wyss@inin.com> wrote:
>>>> I feel it would be better to explicitly require that applications are
>>> responsible for identifier collision avoidance instead of allowing them to rely
>>> on the DTLS roles.
>>> 
>>> Are you suggesting that we might want to consider the effect of a MitM
>>> attack on the robustness of this?
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb