Delivery-Date: Thu, 31 Jul 2014 16:58:32 -0400
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.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID 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 D3A1F1E0BC7;
	Thu, 31 Jul 2014 16:58:30 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 324F330AE1;
	Thu, 31 Jul 2014 20:58:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 49F6530ADD
 for <tor-talk@lists.torproject.org>; Thu, 31 Jul 2014 20:58:22 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
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 bqHjU_P1vUaR for <tor-talk@lists.torproject.org>;
 Thu, 31 Jul 2014 20:58:22 +0000 (UTC)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204])
 (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 2C04A30AD9
 for <tor-talk@lists.torproject.org>; Thu, 31 Jul 2014 20:58:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org;
 s=mail2; 
 h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date;
 bh=r/rg7O1nypGNtYBbfGlmU5BcquOwZo0QpCClp7FDoi8=; 
 b=LcZOq/fvsrUBGYcowamJwzJsxZA1555+NFI+r8c8OtJKO4HRlcEISyu34ebPWary5VmoX6wRtHsSXUHUW0lNCtjpXncQtR9SGSX8IyweE9UprXOjmp/qpyAdDGuSohUcWUy2UiZBcSxELf9ScOj9jxbA04QkkFmp6ETABEs+9N0=;
Received: from localhost ([127.0.0.1]:37975 helo=sescenties)
 by mail2.eff.org with esmtp (Exim 4.80)
 (envelope-from <schoen@eff.org>) id 1XCxQZ-0001vd-6J
 for tor-talk@lists.torproject.org; Thu, 31 Jul 2014 13:58:19 -0700
Date: Thu, 31 Jul 2014 13:58:18 -0700
From: Seth David Schoen <schoen@eff.org>
To: tor-talk@lists.torproject.org
Message-ID: <20140731205818.GU2152@sescenties.(null)>
References: <53D980B1.9020009@bitmessage.ch> <20140731002741.GB16023@nymity.ch>
 <53DA9757.2050602@bitmessage.ch> <20140731201233.GA23456@nymity.ch>
 <20140731203519.GF8819@moria.seul.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20140731203519.GF8819@moria.seul.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Received-SPF: skipped for local relay
Received-SPF: skipped for local relay
Subject: Re: [tor-talk] Why make bad-relays a closed mailing list?
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>

Roger Dingledine writes:

> But in this particular case I'm stuck, because the arms race is so
> lopsidedly against us.
> 
> We can scan for whether exit relays handle certain websites poorly,
> but if the list that we scan for is public, then exit relays can mess
> with other websites and know they'll get away with it.

I think the remedy is ultimately HTTPS everywhere.  Then the problem
is reduced to checking whether particular exits try to tamper with the
reliability or capacity of flows to particular sites, or with the public
keys that those sites present.  (And figuring out whether HTTPS and its
implementations are cryptographically sound.)

The arms race of "we don't really have any idea what constitutes correct
behavior for these vast number of sites that we have no relationship
with, but we want to detect when an adversary tampers with anybody's
interactions with them" seems totally untenable, for exactly the reasons
that you've described.  But detecting whether intermediaries are allowing
correctly-authenticated connections to endpoints is almost tenable,
even without relationships with those endpoints.

(I do think that continuing to work on the untenable secret scanning
methods is great, because attackers should know that they may get caught.
It's a valuable area of "impossible" research.)

Yan has just added an "HTTP nowhere" option to HTTPS Everywhere, which
prevents a browser from making any HTTP connections at all.  Right now
that would probably be quite annoying and confusing to Tor Browser users,
but maybe with some progress on various fronts it could become less so.

-- 
Seth Schoen  <schoen@eff.org>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107
-- 
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

