Delivery-Date: Mon, 22 Feb 2016 06:53:42 -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 65EA61E03B6;
	Mon, 22 Feb 2016 06:53:40 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 613BE38E42;
	Mon, 22 Feb 2016 11:53:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 39C8D38E3A
 for <tor-talk@lists.torproject.org>; Mon, 22 Feb 2016 11:53:32 +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 cpB8pd2Yn-If for <tor-talk@lists.torproject.org>;
 Mon, 22 Feb 2016 11:53:32 +0000 (UTC)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 063A838DC0
 for <tor-talk@lists.torproject.org>; Mon, 22 Feb 2016 11:53:31 +0000 (UTC)
Received: from cotinga.riseup.net (unknown [10.0.1.164])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
 by mx1.riseup.net (Postfix) with ESMTPS id E04731A1484;
 Mon, 22 Feb 2016 11:53:02 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
 (Authenticated sender: adrelanos) with ESMTPSA id D8A17400AF
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>
 <8560xias0l.fsf@boum.org>
From: Patrick Schleizer <patrick-mailinglists@whonix.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <56CAF695.5040604@riseup.net>
Date: Mon, 22 Feb 2016 11:52:53 +0000
MIME-Version: 1.0
In-Reply-To: <8560xias0l.fsf@boum.org>
X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net
X-Virus-Status: Clean
Subject: Re: [tor-talk] [Tails-dev] [Secure Desktops] 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>

I mistyped. Here is the correct version.

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 B.

intrigeri:
> 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?

I mistyped. Entry guard B.

>> 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/

You quoted me! Glad that I was heard! :)

> 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.

Or perhaps consider asking the tor-talk (-dev) mailing list in order to
get more input.

Cheers,
Patrick

-- 
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

