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.
- Re: [rtcweb] Security implications of host candid… westhawk
- Re: [rtcweb] Security implications of host candid… Harald Alvestrand
- Re: [rtcweb] Security implications of host candid… Justin Uberti
- Re: [rtcweb] Security implications of host candid… Justin Uberti
- Re: [rtcweb] Security implications of host candid… Martin Thomson
- Re: [rtcweb] Security implications of host candid… Justin Uberti
- Re: [rtcweb] Security implications of host candid… Justin Uberti
- Re: [rtcweb] Security implications of host candid… youenn fablet
- Re: [rtcweb] Security implications of host candid… Justin Uberti
- Re: [rtcweb] Security implications of host candid… Martin Thomson
- Re: [rtcweb] Security implications of host candid… Justin Uberti
- Re: [rtcweb] Security implications of host candid… Martin Thomson
- Re: [rtcweb] Security implications of host candid… Feross Aboukhadijeh
- [rtcweb] Security implications of host candidates Justin Uberti
- Re: [rtcweb] Security implications of host candid… Justin Uberti
- Re: [rtcweb] Security implications of host candid… youenn fablet
- Re: [rtcweb] Security implications of host candid… youenn fablet
- Re: [rtcweb] Security implications of host candid… Justin Uberti
- Re: [rtcweb] Security implications of host candid… Justin Uberti
- Re: [rtcweb] Security implications of host candid… Justin Uberti
- Re: [rtcweb] Security implications of host candid… youenn fablet
- Re: [rtcweb] Security implications of host candid… Lennart Grahl
- Re: [rtcweb] Security implications of host candid… Justin Uberti
- Re: [rtcweb] Security implications of host candid… Harald Alvestrand
- Re: [rtcweb] Security implications of host candid… youenn fablet
- Re: [rtcweb] Security implications of host candid… Justin Uberti
- Re: [rtcweb] Security implications of host candid… Manuel Kasper
- Re: [rtcweb] Security implications of host candid… Nils Ohlmeier
- Re: [rtcweb] Security implications of host candid… Justin Uberti