Re: [rtcweb] PeerConnection Data Channel

Eric Rescorla <ekr@rtfm.com> Sat, 03 September 2011 15:12 UTC

Return-Path: <ekr@rtfm.com>
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 946AA21F8B36 for <rtcweb@ietfa.amsl.com>; Sat, 3 Sep 2011 08:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.972
X-Spam-Level:
X-Spam-Status: No, score=-102.972 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 uB58Vj97vuOC for <rtcweb@ietfa.amsl.com>; Sat, 3 Sep 2011 08:12:55 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF93921F8AFA for <rtcweb@ietf.org>; Sat, 3 Sep 2011 08:12:54 -0700 (PDT)
Received: by wyg8 with SMTP id 8so3323925wyg.31 for <rtcweb@ietf.org>; Sat, 03 Sep 2011 08:14:33 -0700 (PDT)
Received: by 10.227.165.202 with SMTP id j10mr2219249wby.18.1315062873130; Sat, 03 Sep 2011 08:14:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.3.5 with HTTP; Sat, 3 Sep 2011 08:14:13 -0700 (PDT)
In-Reply-To: <CAOJ7v-2QyB+jd7UoDKy+-oGwG926KNdgbwoJZcm6twUcKrGZjg@mail.gmail.com>
References: <CAOJ7v-1xEEA3+AX0hN4kR=9YggX7EW=wr4b67ASjibG_T=m2mQ@mail.gmail.com> <4E610B78.7000103@skype.net> <4E615505.70508@jesup.org> <BLU152-W197013CA571F772294FFF6931B0@phx.gbl> <CAOJ7v-2QyB+jd7UoDKy+-oGwG926KNdgbwoJZcm6twUcKrGZjg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 3 Sep 2011 08:14:13 -0700
Message-ID: <CABcZeBNV-AEr9w9K8YTcsETxOkkCV95Dkjby2mamaDhAtKK3_g@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: rtcweb@ietf.org, public-webrtc@w3.org
Subject: Re: [rtcweb] PeerConnection Data Channel
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: Sat, 03 Sep 2011 15:12:55 -0000

On Fri, Sep 2, 2011 at 8:46 PM, Justin Uberti <juberti@google.com> wrote:
>
>
> On Fri, Sep 2, 2011 at 8:13 PM, Bernard Aboba <bernard_aboba@hotmail.com>
> wrote:
>>
>> > >> Section 5 in the WEBRTC spec
>> > >> (http://dev.w3.org/2011/webrtc/editor/webrtc.html) discusses at
>> > >> length a mechanism for transmitting and securing datagrams over the
>> > >> PeerConnection transport.
>> [BA] The objective here appears to be "masking" (e.g. to prevent sending
>> of arbitrary datagrams) rather than providing a full set of security
>> services.
>
> The current spec provides an encryption and authentication mechanism, in
> addition to the masking. From the spec: "The data is made to appear
> pseudo-random, so that it cannot be used in a cross-protocol attack, even if
> somehow the stream were to be directed at an unsuspecting remote host. The
> data is hashed in such a way that it cannot be modified in transit. That
> data is encrypted so that it cannot be read in transit."

I believe Justin is correct here: the protocol appears to be designed
to provide rather
more than masking.

With that said, in my opinion it is likely not necessary to mask UDP
data. Masking is
designed to prevent cross-protocol attacks on intermediaries, which
are not really
a common feature of UDP data transmission (as opposed to HTTP intercepting
proxies, which are quite common and for which masking was originally designed.

-Ekr