Delivery-Date: Sun, 21 Feb 2016 12:32:50 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 2FDA01E038A;
	Sun, 21 Feb 2016 12:32:48 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 6B9F73969E;
	Sun, 21 Feb 2016 17:32:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 2679739693
 for <tor-talk@lists.torproject.org>; Sun, 21 Feb 2016 17:32:39 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id bzYmOCzsexLc for <tor-talk@lists.torproject.org>;
 Sun, 21 Feb 2016 17:32:39 +0000 (UTC)
Received: from boum.org (boum.org [204.13.164.192])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "*.boum.org", Issuer "Gandi Standard SSL CA 2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 04AD03968A
 for <tor-talk@lists.torproject.org>; Sun, 21 Feb 2016 17:32:38 +0000 (UTC)
Received: from localhost (censure.boum.org [192.168.122.20])
 by boum.org (Postfix) with ESMTP id 50C9EC0B;
 Sun, 21 Feb 2016 18:32:34 +0100 (CET)
Received: from boum.org ([192.168.122.29])
 by localhost (censure.boum.org [192.168.122.20]) (amavisd-new, port 10024)
 with ESMTP id aX89QQQysufu; Sun, 21 Feb 2016 18:32:33 +0100 (CET)
Received: from boum.org (boum.org [127.0.0.1])
	with ESMTPSA id 2A496B28
Received: from boum.org (boum.org [127.0.0.1])	with ESMTP id A35D572BD42
Message-Id: <8560xias0l.fsf@boum.org>
From: intrigeri <intrigeri@boum.org>
To: The Tails public development discussion list <tails-dev@boum.org>,
 tor-talk@lists.torproject.org, desktops@secure-os.org, whonix-devel@whonix.org
References: <5685200D.4020405@pimienta.org> <568850DD.9010601@whonix.org>
 <858u2xsa81.fsf@boum.org> <56BA795E.5030602@riseup.net>
Date: Sun, 21 Feb 2016 18:32:26 +0100
In-Reply-To: <56BA795E.5030602@riseup.net> (Patrick Schleizer's message of
 "Tue, 9 Feb 2016 23:42:22 +0000")
MIME-Version: 1.0
Subject: Re: [tor-talk] [Secure Desktops] [Tails-dev] Persistent Tor start
	in Tails vs location aware Tor entry guards (LATEG)
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

Hi,

Patrick Schleizer wrote (09 Feb 2016 23:42:22 GMT) :
> intrigeri:
>> [can you please decide what mailing-list this discussion should happen
>> on, and then we can stop cross-posting over 4 mailing-list?]

This still holds.

>> I'm not sure I understand the problem you mean to raise, though.
>> Can you please elaborate what problem you see if users do exactly this
>> ("click through whatever hoops required to make the WiFi connect
>> again", which I agree is very likely)?

> day 1

> 1) Tails user regularly goes to physical place A that provide [free] WiFi.
> 2) The name of the wifi is FreeWifi832458252823523 with MAC address "A".
> The user uses the regular way to set up a WiFi connection. Network
> Manager etc.
> 3) Now, Tails would remember FreeWifi832458252823523 and assign entry
> guard A.

> day 2

> 3) Tails user goes to the same physical place A that provide [free] WiFi.
> 2) The name of the wifi has changed to FreeWifi358235892435 with mac
> address "B". The user uses the regular way to set up a WiFi connection.
> Network Manager etc.
> 3) Now, Tails would remember FreeWifi358235892435 and assign entry guard A.

I don't understand why we would pick Entry Guard A in the last step on
day 2, can you please explain?

> This is the behavior I expect from most users. And this is what I meant
> by 'users will click through whatever hoops required to make the WiFi
> connect again'.

Fully agreed!

> The entry guard selection would now be influenced by by the provider of
> the [free] WiFi. And I think such an adversary capability is something
> as we agree that is to be avoided.

Right, it's something we want to limit. anonym and I have been working
a bit more on it, and have reverted the addition of the ESSID in the
data we hash, found another attack, thought a bit about potential
defenses, and discussed it a bit more. See the "First iteration"
section on our blueprint for details:

https://tails.boum.org/blueprint/persistent_Tor_state/

In the current state of things we're undecided whether our current
design is good enough to be worth shipping, or not. We'll probably ask
someone (probably Isis) for help evaluating it and/or designing
something better.

Cheers,
-- 
intrigeri
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

