IETF Logo Mail Archive

Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt

Harald Alvestrand <harald@alvestrand.no> Tue, 29 October 2013 20:51 UTC

Return-Path: <harald@alvestrand.no>
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 127AE11E8282 for <rtcweb@ietfa.amsl.com>; Tue, 29 Oct 2013 13:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.998
X-Spam-Level:
X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmDkBv0aGVBB for <rtcweb@ietfa.amsl.com>; Tue, 29 Oct 2013 13:51:25 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0975E11E829D for <rtcweb@ietf.org>; Tue, 29 Oct 2013 13:51:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A1D8A39E8A5; Tue, 29 Oct 2013 21:51:14 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2BelmNXZAnZ; Tue, 29 Oct 2013 21:51:12 +0100 (CET)
Received: from [10.184.8.24] (host-95-199-136-24.mobileonline.telia.com [95.199.136.24]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5894039E18D; Tue, 29 Oct 2013 21:51:12 +0100 (CET)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAHZ_z=yc5=mQMG3QZP=KtpDF0AxYAtiBYDRkCj0b9hbbe8EKag@mail.gmail.com>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com> <A87B4291-FA11-43BB-B8F0-55C59CF63421@lurchi.franken.de> <CAOJ7v-20YkvazNLqmbjQcOkhaedd+MKm8d6x2oeL46imvuLrzA@mail.gmail.com> <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <526FD2D8.7000709@alum.mit.edu> <CAHZ_z=yc5=mQMG3QZP=KtpDF0AxYAtiBYDRkCj0b9hbbe8EKag@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----57RKKW5QLKY7YKT9PUQFTMEP96Q64D"
From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 29 Oct 2013 21:51:12 +0100
To: Matt Fredrickson <creslin@digium.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <43f5e30f-f001-4060-b19b-05ea33a865ad@email.android.com>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 29 Oct 2013 20:51:30 -0000

Sorry, you are wrong. Since signalling is left 100% to the application, the browser can make no assumption about the integrity of signalling messages.

Matt Fredrickson <creslin@digium.com> wrote:
>On Tue, Oct 29, 2013 at 10:23 AM, Paul Kyzivat
><pkyzivat@alum.mit.edu>wrote:
>
>> On 10/27/13 5:45 AM, Randell Jesup wrote:
>>
>>> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
>>>
>>
>>  My proposal has three elements, which together can guarantee that
>>>>> there are no stream id allocation conflicts between peers:
>>>>>     1. The browser and application select stream ids based on
>initial
>>>>> SDP offerer/answerer role rather than DTLS role (e.g., initial
>>>>> offerer uses even ids, initial answerer uses odd ids). With this
>>>>> rule, the offering application knows its role immediately without
>>>>> waiting for the DTLS or SDP handshake to occur.
>>>>>
>>>>
>>>> A similar issue has come up in the discussion of partial
>>>> offers/answers. (Regarding how to assign a=mid values.) And a
>similar
>>>> solution was proposed.
>>>>
>>>> It was then rejected on the basis that sometimes both "ends" think
>>>> they are offerers or answerers. This comes about as a result of
>>>> signaling-only B2BUAs that play games with O/A on two legs.
>>>>
>>>
>>> Exactly why we went with DTLS roles.
>>>
>>
>> I'm not sure this eliminates the problem.
>>
>> Is it not possible for an intermediary on the signaling path to
>insert
>> itself in the media path, manipulating the SDP such that the two ends
>both
>> establish the DTLS with the intermediary?
>
>
>Correct me if I'm wrong, but I thought that the SDP itself was supposed
>to
>be signed and able to be validated (perhaps using the identity
>mechanism),
>to explicitly catch nefarious man in the middle type scenarios such as
>this.
>
>Matthew Fredrickson
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

v2.23.0 | Report a Bug | By Email