Re: [rtcweb] Security implications of host candidates

Martin Thomson <martin.thomson@gmail.com> Mon, 09 July 2018 06:35 UTC

Return-Path: <martin.thomson@gmail.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 DF38C130F36 for <rtcweb@ietfa.amsl.com>; Sun, 8 Jul 2018 23:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tamVESOYsaVN for <rtcweb@ietfa.amsl.com>; Sun, 8 Jul 2018 23:35:01 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D27130DE0 for <rtcweb@ietf.org>; Sun, 8 Jul 2018 23:35:01 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id w126-v6so33823124oie.7 for <rtcweb@ietf.org>; Sun, 08 Jul 2018 23:35:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z4Stw8KgQZk/IFL8Bmun7CMSXkduwtg1cJlWq6TVD1M=; b=DGniu04SYF4xi2BB5kgll3aDqHi/2LNUlrofnjO63H2oOSkNPF8Na2SFtFmyTPRbSN RxOC1v2AWdvbtq3EDKjd0jKQeOjZmMxhZlsCFly0nWp1wtGS2rN0FXTZacMKt3gdV2Nc zTbh/kYm8S0WBMAgAA2TD8n/QizLCvIwRcvba6IvWMZxqhLsbTQsiNJCVbUjRmywd7yK rpyNVreemxUTkpbHdlPFjK4OmA+UC7iyBwroRopUqgkCO+Woo+CmYaUdJ9bYZqkLkrU3 apu36TBFAQgK9iir9sUxwsdCVb3/INPRwVx8103GQQSLFZTUfBU/W2azrb9U0WdtG1oh VF1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z4Stw8KgQZk/IFL8Bmun7CMSXkduwtg1cJlWq6TVD1M=; b=pOIN3Mtg2h2XJRO9Iv+hZEfw1nhRXrlpa7gIQyjVZLv5VKIxhtKArme9tElIWx7+mz K9+XywyrVDbnM/tspZoy4vbehVta36ZCVd5Fr4VTfC0PcXPtC0orEzart884nKLKq4bl bEMz4NTsxZhRjf8vinYNlVB7c+d5sG+1ccMP2LqR5hLEjlpPwObBMVKEu0f7Z7uHClnA H2U3jIfVsYCZcwq/ZIJlX0MitBxvqBpga9+5S1O9f0CWUtyI6WRZp8KSiUB6PMt+HuJh w12i7j/IwKYJQrSL/r58thN0QRU2QnL7APFUXEotF95IvuclV0WCBik2SpMrvPYdrGsI RRcw==
X-Gm-Message-State: AOUpUlECvZwkLtAyJ7hWUAlH5njHmFz4M7ltaO+hUApJnqvE7cGZLTgt WmrZDSLH7myMtQFJNmoSX3+6oPQ/cJNfw9VgQ0o=
X-Google-Smtp-Source: AAOMgpfNdMUEmP5a0YCVg5ZjA62hM/PrHiOcyNT2RMguvST6sP4m/dqBmgSNhwQWEhRSfN7T+CM/LxjMmTZuqiSWIZs=
X-Received: by 2002:aca:df42:: with SMTP id w63-v6mr3541960oig.295.1531118100173; Sun, 08 Jul 2018 23:35:00 -0700 (PDT)
MIME-Version: 1.0
References: <CAOJ7v-1t_BDEEHmA4eqiS9ksYOOyHUz9LFLhQxs8FhjTdswP5w@mail.gmail.com> <CANN+akZLRdZdexjU44zPCA6vdQR0hVYT17_4P8DefC0JbRL5mA@mail.gmail.com> <CAOJ7v-2JdiMJ9iWE_cL8G7xDM6iekexJL8KLEbz0jD=p7hiGZg@mail.gmail.com> <CANN+akbv2mpyhgV5vxDHKcsA8UPsSEr0bEjJK4xYxtvbkXNA7w@mail.gmail.com> <CAOJ7v-3gHMCxHU02YG3NoqvWHtXgOSWSm+y88GNDW0qc=Sqq=A@mail.gmail.com> <CAOJ7v-3moUqwgxkz1Fek4vy-XV+WpDaO-PsQZEw4ougoCHjLww@mail.gmail.com> <CANN+akZ=Ebw41mA2wEX7-4u6q5WcZbFtM=VMLX4nDK39S=QGOQ@mail.gmail.com> <CAOJ7v-3X2Sj8Yid+i0=xadyH_Hmf4pMOF_iuOV+56Ty8HNnJuw@mail.gmail.com> <0ED74BE5-AC02-44C5-80E1-18532BD3D1FF@westhawk.co.uk> <CAOJ7v-0TGqvp=MUmeEUjYZTcvV37qbYSTV0pFMoi1J0CJQ7Q4A@mail.gmail.com>
In-Reply-To: <CAOJ7v-0TGqvp=MUmeEUjYZTcvV37qbYSTV0pFMoi1J0CJQ7Q4A@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 09 Jul 2018 16:34:49 +1000
Message-ID: <CABkgnnXBTC5TERquJPO4dgiAKz037Cm0Omw4YrobtCW=wmGPyQ@mail.gmail.com>
To: juberti=40google.com@dmarc.ietf.org
Cc: tim panton <thp@westhawk.co.uk>, RTCWeb IETF <rtcweb@ietf.org>, youenn fablet <yfablet@apple.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/buGkK4MY_ANPLiJjR8ivrwP0HuY>
Subject: Re: [rtcweb] Security implications of host candidates
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.26
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 09 Jul 2018 06:35:03 -0000

On Sat, Jul 7, 2018 at 5:36 AM Justin Uberti
<juberti=40google.com@dmarc.ietf.org> wrote:
> The issue is that two pages (probably of the same origin) can determine that they are on the same host even when running in different browsing contexts (e.g., one being in private browsing mode), by establishing a p2p connection and measuring latency.
>
> The key questions are a) whether this gives up information that is not already present (e.g., by looking at your own IPv6 address), and b) what mitigations might exist.

This seems like a fair analysis.  I read the draft and thought a
little about this angle, and I think that it's worth doing something
about, even if I'm not 100% sure of what that would look like.

Other signals, like sharing an address, don't seem to be as reliable
as this.  For instance, having to go to a NAT hairpin might add enough
additional latency that it looks like you are on the same network, but
not necessarily the same machine.  That might be enough information
for a tracker, anyway, so that's a big caveat on any mitigation we
come up with.

I'm not sure that what is proposed (limiting to a top-level browsing
context that isn't also private browsing) is the best way to achieve
the stated policy goals in the draft.  And more fundamentally, there
are probably several policies that browsers might reasonably adopt
along those lines.

For instance, we might reasonably be similarly concerned about
different unrelated top-level browsing contexts using this to link
each other.  I know that Tor Browser would be concerned about this
sort of isolation as much as it would worry about iframes on different
pages.

The best idea I have there is to fail resolution for .local names that
the browser itself has minted for other origins[1].  That way,
connections that are cross-origin and same-host would always at least
hit a hairpin or relay.  Of course, failing resolution so quickly
might leak information, so additional caution might be necessary (I
don't think that it does, provided that a candidate is not entered
into a checklist before resolution occurs, but I'm not sure how that
would be implemented).

This suggests that you could share mDNS names for frames under the
same top-level browsing context without leaking more information,
which could be very useful.

(The data channels thing isn't relevant here, because measuring
connection setup should be enough to link two browsing contexts.  RTP
likely works as well, but it's less easy to use.)

[1] The draft uses the term "execution context" here, which is
probably the right phrase, but it's not really defined.