Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-ip-handling (part 1)

From: Justin Uberti <[email-masked]>
Date: Tue, 4 Jul 2017 19:53:18 -0700

Thanks for the review. Most of these comments have been resolved in the
latest version of the document,
https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-04.

On Tue, May 9, 2017 at 3:43 PM, Bernard Aboba <[email-masked]>
wrote:

>
>
> General points:
>
> a. Please expand acronyms on first use (e.g. HTTP, VPN, ICE, etc.).
>

Done.

>
>
>
> Details
>
> 1 <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03#section-1>.  Introduction
>
>
>    As a technology that supports peer-to-peer connections, WebRTC may
>    send data over different network paths than the path used for HTTP
>    traffic.  This may allow a web application to learn additional
>    information about the user, which may be problematic in certain
>    cases.  This document summarizes the concerns, and makes
>    recommendations on how best to handle the tradeoff between privacy
>    and media performance.
>
>
> [BA] There are a number of distinct privacy issues that WebRTC
>
> needs to address. I believe this document is focussed on IP
>
> address info that can be gleaned by Web applications (the
>
> second sentence).  That is somewhat distinct from what information
>
> a web server might glean, or what a passive observer might be
>
> able to obtain looking at traffic generated by a WebRTC client.
>
> The first sentence therefore is a bit confusing to me.
>
>
> A suggestion:
>
>
> "As a technology that attempts to optimize peer-to-peer
>
> connections by testing connectivity between available
>
> addresses, WebRTC may allow a web application to learn
>
> additional information about the user compared to an
>
> application which only utilizes HTTP.  This may be
>
> problematic in certain cases."
>
>
Done.

>
> 2 <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03#section-2>.  Problem Statement
>
>
>    WebRTC enables real-time peer-to-peer communications by enumerating
>    network interfaces and discovering the best route through the ICE
>    [RFC5245 <https://tools.ietf.org/html/rfc5245>]protocol.  During the ICE process, the peers involved in a
>    session gather and exchange all the IP addresses they can discover,
>    so that the connectivity of each IP pair can be checked, and the best
>    path chosen.  The addresses that are gathered usually consist of an
>    endpoint's private physical/virtual addresses, and its public
>    Internet addresses.
>
>
> [BA] The terms "route" and "path" used here do not refer to IP
>
> routing and so is a bit confusing.  How about this?
>
>
>    "In order to enable peer-to-peer communications, WebRTC
>
>    peers utilize ICE [RFC5245] which gathers and exchanges
>
>    all the IP addresses it can discover, so that the
>
>    connectivity of each IP pair can be checked, and the best
>    pair can be chosen.  The addresses that are gathered
>
>    usually consist of an endpoint's private physical/virtual
>
>    addresses, and its public Internet addresses."
>
>
Done.

>    2.  If the client tries to hide its physical location through a VPN,
>        and the VPN and local OS support routing over multiple interfaces
>        (i.e., a "split-tunnel" VPN), WebRTC will discover the public
>        address for the VPN as well as the ISP public address that the
>        VPN runs over.
>
>
> [BA] Even if the local OS doesn't support split-tunnel,
>
> isn't it still possible for an ICE implementation to
>
> discover other addresses?
>
>  <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03#section-3>
>
>
Yes, but these addresses are typically RFC1918 addresses, and thereby
covered by the prior bullet.

> 3 <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03#section-3>.  Goals
>
>    Being peer-to-peer, WebRTC represents a privacy-enabling technology,
>    and therefore we want to avoid solutions that disable WebRTC or make
>    it harder to use.  This means that WebRTC should be configured by
>    default to only reveal the minimum amount of information needed to
>    establish a performant WebRTC session, while providing options to
>    reveal additional information upon user consent, or further limit
>    this information if the user has specifically requested this.
>    Specifically, WebRTC should:
>
>
>    o  Provide a privacy-friendly default behavior which strikes the
>       right balance between privacy and media performance for most users
>       and use cases.
>
>
>    o  For users who care more about one versus the other, provide a
>       means to customize the experience.
>
>
> [BA] This section might state whether it is a
>
> goal to enable WebRTC to be used with
>
> The Onion Routing network (Tor). There
>
> are a number of reasons why enabling Javascript
>
> for  use with Tor may represent a problem so that
>
> use of WebRTC might not be advisable:
>
> https://security.stackexchange.com/questions/95046/why-disable-javascript-in-tor
>
>
I checked, and it looks like the default Tor bundle does allow use of JS,
which makes it somewhat problematic to argue against here, given that one
could support Tor with Mode 4.

Tracking this issue in https://github.com/juberti/draughts/issues/60.

>  4 <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03#section-4>.  Detailed Design
>
>
>    1.  By default, WebRTC should follow normal IP routing rules, to the
>        extent that this is easy to determine (i.e., not considering
>        proxies).  This can be accomplished by binding local sockets to
>        the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which
>        allows the OS to route WebRTC traffic the same way as it would
>        HTTP traffic, and allows only the 'typical' public addresses to
>        be discovered.
>
>
> [BA] This paragraph discusses routing behavior and
> address binding together and leads me to wonder whether
> some assumptions aren't being made (e.g. weak versus
> strong host model). My suggestion is to simplify the
> the paragraph and leave details to later on. For example:
>
> "1. By default WebRTC should only allow applications
> to discover the same address information made available
> by an HTTP application: the 'typical' public address
>
> "
>
>
Agree that the info about wildcard binding could be moved later to the mode
definitions, although I don't follow exactly what you mean by 'weak vs
strong host model'.

Tracking in https://github.com/juberti/draughts/issues/61.

---

From: Justin Uberti <[email-masked]>
Date: Sat, 8 Jul 2017 10:37:13 -0700

Bernard, any more thoughts on these points?

On Tue, Jul 4, 2017 at 7:53 PM, Justin Uberti <[email-masked]> wrote:

> latest version of the document, https://tools.ietf.
> org/html/draft-ietf-rtcweb-ip-handling-04.
>
> Agree that the info about wildcard binding could be moved later to the
> mode definitions, although I don't follow exactly what you mean by 'weak vs
> strong host model'.
>