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

Harald Alvestrand <harald@alvestrand.no> Tue, 29 October 2013 20:54 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 9C37121E80A6 for <rtcweb@ietfa.amsl.com>; Tue, 29 Oct 2013 13:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.298
X-Spam-Level:
X-Spam-Status: No, score=-110.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KxWyklZ8bGy2 for <rtcweb@ietfa.amsl.com>; Tue, 29 Oct 2013 13:54:29 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 57D9411E824C for <rtcweb@ietf.org>; Tue, 29 Oct 2013 13:54:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 49D2D39E1BB; Tue, 29 Oct 2013 21:54:06 +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 3yoSw25oFidR; Tue, 29 Oct 2013 21:54:05 +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 ACCE439E18D; Tue, 29 Oct 2013 21:54:04 +0100 (CET)
User-Agent: K-9 Mail for Android
In-Reply-To: <527005A1.7000007@alum.mit.edu>
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> <CABcZeBOiKboabmjRqWxzD8-SD9M01FkuQEH9M4+jN8dV=t0Z8Q@mail.gmail.com> <526FFEBC.7090302@alum.mit.edu> <CABcZeBMdqJuRdrrRmxq8M-1AiX2cikxRN2NbPTg2k9rRytmpjQ@mail.gmail.com> <527005A1.7000007@alum.mit.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----HVKEM7EFT0DL9F33YWH52FKDMOZGLG"
From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 29 Oct 2013 21:54:09 +0100
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Eric Rescorla <ekr@rtfm.com>
Message-ID: <8cb687a9-17dc-46d3-b794-d22aff4c1212@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:54:34 -0000

If a mitm attack is being performed, one may perhaps assume that the attacker will also terminate and reinitialize the data channels?

Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>(trimming)
>
>On 10/29/13 2:46 PM, Eric Rescorla wrote:
>
>>              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?
>>
>>         There is a separate role negotiation for DTLS (actpass, etc.)
>>         that works
>>         even if both sides think they are the offerer or answerer.
>>
>>
>>     I know about that. That mechanism is also used for TCP
>negotiation
>>     in SDP. And that is one place where an intermediary sometimes
>sticks
>>     its nose in explicitly to manipulate the roles, allowing both
>ends
>>     to be active.
>>
>>     In the current case, ICE and possible TURN result in getting the
>>     media path established without those games. So maybe there is
>less
>>     motivation for an intermediary. But still, they still seem to
>show
>>     up because administrators think they need them. And once there,
>>     couldn't the intermediary still end up making both ends think
>they
>>     are active?
>>
>> Well, it could but then they wouldn't be able to negotiate DTLS.
>
>Couldn't it negotiation independently on each side - becoming a true
>MITM.
>
>(I'm not advocating this as a good thing. But if it is possible, there 
>will be someone who wants to do it, and somebody willing to sell them 
>stuff to do it.)
>
>	Thanks,
>	Paul
>
>_______________________________________________
>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.