IETF Logo Mail Archive

Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))

Eric Rescorla <ekr@rtfm.com> Sun, 03 February 2013 23:48 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 074DD21F8864 for <rtcweb@ietfa.amsl.com>; Sun, 3 Feb 2013 15:48:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level:
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXUI2eCBvzNT for <rtcweb@ietfa.amsl.com>; Sun, 3 Feb 2013 15:48:45 -0800 (PST)
Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id A6D1521F883E for <rtcweb@ietf.org>; Sun, 3 Feb 2013 15:48:45 -0800 (PST)
Received: by mail-ob0-f179.google.com with SMTP id un3so5835348obb.10 for <rtcweb@ietf.org>; Sun, 03 Feb 2013 15:48:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=LoeUcdDG4PUuZcBMLjyVHqIGwkzjkN1t/+EUuheT/CM=; b=aCgkCKCS+q0gl/CMMkG4lnQOwutV1UG/SlZN3hZhc+sevY8X3Ra+dbQJPjbjXD9eNk CC58/lT9hYweLFShgK7a5ukFU66T3J3bS60jKDBvyrltYaAxB2XilEoPT3Fp+7EnTVjj BNpHbBfHMGJ/aLNrBUIettcM07QSi5goVJbg04CPFYt0SIqij65HVz3vTZBbaejePWnb Ey+gn5iiCZFuFbLAF9DvQXMHoJWe9gtlcAhCmE7ycKGywive4pNaMpfzr+nBdh4xMWiS 4sBj+H6JdQHZE4PmJnUzN9BM0ZhkTVXXaduZdcMrpNYGfAWuBcrOUij4pXpnuARRA3wr AMBg==
X-Received: by 10.60.21.104 with SMTP id u8mr2739107oee.99.1359935325155; Sun, 03 Feb 2013 15:48:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.3.106 with HTTP; Sun, 3 Feb 2013 15:48:04 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <984674BE-1A5C-4728-89C1-F2EAAD1A3D6B@standardstrack.com>
References: <50F97303.4070906@ericsson.com> <CABkgnnWcqZ+dU+87djBQ0z47ufB-Go13mWyPi_ZQA8BPinQJEA@mail.gmail.com> <BLU002-W1705DC54006131B55B432A931F0@phx.gbl> <BLU002-W210B8DBB897CAF5BECC501A931F0@phx.gbl> <5109265F.6040106@ericsson.com> <BLU002-W123BE6BAA58BE0B26DEA28F931E0@phx.gbl> <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com> <510CEAF9.6020509@alvestrand.no> <510D0D14.4050301@ericsson.com> <510D6039.3060501@alvestrand.no> <CABcZeBMyH7KThkrqZRy4b2eLOpELnPhNsaYpL3D4EcbwG9XRyg@mail.gmail.com> <479FFA31-EE78-4E6E-A8BB-440DF9A82A74@cs.georgetown.edu> <CABcZeBPz2X+CkcrVqdGk-Xzf98VEdND8H+Drxs+0=Mou=xNzKg@mail.gmail.com> <984674BE-1A5C-4728-89C1-F2EAAD1A3D6B@standardstrack.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 03 Feb 2013 15:48:04 -0800
Message-ID: <CABcZeBPk+9-qJhScSGcVhTr9=077TiU8NERqNabpq-LtVXKTjQ@mail.gmail.com>
To: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/alternative; boundary="e89a8ff1c6d6f930ae04d4da9d09"
X-Gm-Message-State: ALoCoQlP4YPkh08q0JXB1rdbNCudVZcIipFoWy5PJA7B1qPVLRVFJtSonMu88JgwdSKVlJj+OAM0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
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: Sun, 03 Feb 2013 23:48:47 -0000

On Sun, Feb 3, 2013 at 10:56 AM, Eric Burger <eburger@standardstrack.com>wrote:

> To be clear, I think ekr's formulation is the best:
> > 1. If you don't want the server learning your global IP, you need to use
> Tor or the like.
>
> To me, this means it is totally orthogonal to RTCweb. If you want to use
> Tor, a TURN server, an ALG, or foo, that is up to you. That does not impact
> the protocol.


That's certainly what I meant to be saying, with the small caveat that
if you are using media relays (e.g., TURN) they are supposed to be
reflected in ICE candidate lines.


> 2. I would suggest that it is simplest to divide the world into host
addresses, server/peer

> > reflexive, and relayed and say that the requirement is that the browser
> must be able
> > to send packets without revealing either of the former two, but that it
> is not a requirement
> > that it be able to do so in the face of an adversarial server.
> And this is the most reasonable. I guess the concern is we will forget all
> of this list discussion, and someone will require hard-coded endpoint IP
> addresses in the protocol, which is what sunk SIP in the early days.
>
> Inline…
>
> On Feb 3, 2013, at 1:32 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric <eburger@cs.georgetown.edu>
> wrote:
> > Is what we are really asking for is the ability of the protocol to be
> TOR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in one
> particular anonymity network or another into the RTCweb protocol suite.
> >
> > I'm certainly not suggesting that.
> >
> >
> > On the one hand, with my purist hat on, saying it is a requirement to
> make sure we do not need to have end-to-end connectivity smells a bit weird.
> >
> >> I don't understand this... I don't think anyone is suggesting that.
>
> Saying we will bake into the protocol the REQUIREMENT that it support good
> or bad boxes in the middle of the network does not sound like the
> end-to-end Internet. It sounds more like IMS.


Which requirement do you think suggests that? I certainly favor
requirements that we be
able to work in the face of as many known classes of intermediaries (NATs,
firewalls,
etc. as possible.) I mean, isn't that the point of ICE supporting TURN and
other types
of relays?

Is there something wrong with this? Do you think people are suggesting some
other requirement?


 > On the other hand, with my practical hat on, saying it is a requirement
> to make sure the protocol works in situations that are NOT the Internet
> (NATs, a need for an overlay privacy network, etc.) seems like a good thing
> to do.
> >
> >> As far as I know, the only novel requirement here is that there be a
> way for Web
> >> application to tell the browser to solely use relayed
> addresses/candidates
> >> (and hopefully thus not reveal the user's actual location) when
> communicating
> >> with the peer. There is of course a requirement to be able to work when
> >> behind NATs but that is a functional requirement, not an anonymity one.
>
> That is asking an awful lot of an application. Moreover, as the
> cat-and-mouse game of anonymous application communication is ever evolving,
> I would challenge how meaningful it is to specify a Hidden Bit or Anonymous
> Bit in the protocol. I would offer that will work as well as the Evil Bit.


I really am not following what you are saying here about a "hidden bit"?

There is a very specific requirement being suggested here, namely that
applications
should be able to instruct browsers not to use host or srvflx candidates.
This is
neither a hidden bit, nor an anonymous bit. Rather, it is a mechanism
designed
to allow the site, *if it wishes* to offer a calling service that doesn't
immediately
reveal the caller's location. This isn't a complete anonymity service
against
sophisticated attackers. For that you need something like Tor. Rather, it's
an
easy-to-implement measure that offers location protection against a
(relatively common) class of limited attackers.

What is it you object to about this requirement?

-Ekr

v2.23.0 | Report a Bug | By Email