IETF Logo Mail Archive

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

"Wyss, Felix" <Felix.Wyss@inin.com> Sat, 11 October 2014 07:21 UTC

Return-Path: <Felix.Wyss@inin.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 8D5861A001E for <rtcweb@ietfa.amsl.com>; Sat, 11 Oct 2014 00:21:32 -0700 (PDT)
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, SPF_HELO_PASS=-0.001, SPF_PASS=-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 H7MbXd6q5Npd for <rtcweb@ietfa.amsl.com>; Sat, 11 Oct 2014 00:21:30 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0054.outbound.protection.outlook.com [65.55.169.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA371A001D for <rtcweb@ietf.org>; Sat, 11 Oct 2014 00:21:30 -0700 (PDT)
Received: from CY1PR0501MB1578.namprd05.prod.outlook.com (25.161.161.152) by CY1PR0501MB1259.namprd05.prod.outlook.com (25.160.225.17) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Sat, 11 Oct 2014 07:21:28 +0000
Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (25.161.161.153) by CY1PR0501MB1578.namprd05.prod.outlook.com (25.161.161.152) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Sat, 11 Oct 2014 07:21:27 +0000
Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) with mapi id 15.00.1049.012; Sat, 11 Oct 2014 07:21:27 +0000
From: "Wyss, Felix" <Felix.Wyss@inin.com>
To: Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt> (WebRTC Data Channels) to Proposed Standard
Thread-Index: AQHP5CPxgL7/P4TbxUqqTVTHzTRXYJwplZVAgAA1HQCAAKtdYA==
Date: Sat, 11 Oct 2014 07:21:26 +0000
Message-ID: <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com>
References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <CABkgnnWE7czWqi4vQRb5d50N2k95joc_Zcvw6w6g7SOjU9b+9g@mail.gmail.com>
In-Reply-To: <CABkgnnWE7czWqi4vQRb5d50N2k95joc_Zcvw6w6g7SOjU9b+9g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [107.147.12.61]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1578;UriScan:;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0361212EA8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(164054003)(189002)(13464003)(199003)(95666004)(99286002)(99396003)(105586002)(97736003)(122556002)(4396001)(74316001)(87936001)(85852003)(2656002)(230783001)(77096002)(86362001)(76482002)(92566001)(120916001)(107046002)(80022003)(46102003)(106356001)(76576001)(106116001)(108616004)(110136001)(33646002)(85306004)(31966008)(76176999)(54356999)(101416001)(50986999)(21056001)(64706001)(66066001)(20776003)(19580405001)(19580395003)(40100003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1578; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1259;
X-OriginatorOrg: inin.com
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Jtp1_cC6QOPtjUFi3H8Ql0dF0-A
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 07:21:32 -0000

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 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?

v2.23.0 | Report a Bug | By Email