Delivery-Date: Thu, 31 Jul 2014 15:22:17 -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 BC1801E0BA7;
	Thu, 31 Jul 2014 15:22:15 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 917BB30A33;
	Thu, 31 Jul 2014 19:22:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 6D63730A10
 for <tor-talk@lists.torproject.org>; Thu, 31 Jul 2014 19:22:07 +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 8vzdTtS1Cv28 for <tor-talk@lists.torproject.org>;
 Thu, 31 Jul 2014 19:22:07 +0000 (UTC)
Received: from mail.bitmessage.ch (mail.bitmessage.ch [146.228.112.252])
 by eugeni.torproject.org (Postfix) with SMTP id 0599A308F3
 for <tor-talk@lists.torproject.org>; Thu, 31 Jul 2014 19:22:06 +0000 (UTC)
dkim-signature: v=1; a=rsa-sha256; d=bitmessage.ch; s=mail;
 c=relaxed/relaxed; q=dns/txt;
 h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References;
 bh=lHVSKtKGKkeGCCR8wA1/pYZEW2kIeo5RQXUaSY6V6Gk=;
 b=cTNp5UXAt5gFrWB+6toGlcah1ufB1SwNhUboXux+RUKGBMy/4x6y5g4s4KEu3UoG6Tp1VhvV9sEH0SZMX1Uq9BzlHbvhy4Y8opNlFLap8fU9Aw0JPWk1mq6rLdWG86e9ecvz2CseztihyfUGUVgZx1uFAxV2INVVG3rBS9+R+Bo=
Received: from 127.0.0.1 (BITMESSAGE [127.0.0.1]) by mail.bitmessage.ch
 ; Thu, 31 Jul 2014 21:21:13 +0200
Message-ID: <53DA9757.2050602@bitmessage.ch>
Date: Thu, 31 Jul 2014 19:21:59 +0000
From: Nusenu <BM-2D8wMEVgGVY76je1WXNPfo8SrpZt5yGHES@bitmessage.ch>
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <53D980B1.9020009@bitmessage.ch> <20140731002741.GB16023@nymity.ch>
In-Reply-To: <20140731002741.GB16023@nymity.ch>
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

>> What would be the catch with making these reports and discussion
>>> public? Would it help bad actors? They will eventually find out
>>> about the consensus changes anyway, no?
> I think we need to distinguish between the report and the
> discussion. Ultimately, a report that is acted upon *cannot* remain
> secret.  As soon as a relay gets the BadExit flag, the operator can
> figure out that they got caught.  As a result, I believe that the
> mere fact that a relay was blocked (via BadExit or reject) can be
> published.  There is an ongoing discussion if we should do that.
> 
> The discussion of observed malicious behaviour, however, can give
> the attacker a lot of knowledge which they can exploit in order to
> evade detection in the future.  Consider, for example, an HTTPS
> MitM attack which targets a small number of web sites.  If somebody
> reports only one of these targets, the attacker can spawn a new
> relay after discovery and simply reduce the set of targeted sites
> in order to remain under the radar.  This seems to be an uphill
> battle and it's difficult to have full transparency without giving
> dedicated adversaries a big advantage.

You might find the proven approach used in other areas (security bugs)
a viable option:

Keep the discussion private until a decission has been reached, make
it (the discussion) public once the report has been closed (whether
with or without a flag or reject entry).

This allows for transparency while at the same time shouldn't
interfere with ongoing investigations.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJT2pdXAAoJEDcK3SCCSvoedmcP/jHkpAl9BrMmDGyFANWZyq0P
LHE83kCDHp52aGlLW46thjX0W9XEGaPM+bEjyuadL1wQZ6xCqzjqNz+onUP0Ry8y
Zr4mHJcWNQHHuRymFOBFmPyQcgaR633ZCbOLfluVWTyj5KGRgqDv3oXm9saz/T5M
CQr3SPsBtvPToPRgUHr0iUMBpy1L10IX8vcfwQXlk6gchQFP6sNdvWo/uUQB2Q4Q
zX8OPNVZPogBBMcrJ0LFMw1J+cCKwIddgp2vdE7HIoxOTWGF9EpBIGf5kWwoiFV0
tMFT1CmAID5qSYb3FXyh0WqjIueFcQypiD+WJNgMrFTG6RGx8dyp+oYiVucvg0o1
STWJrk2mGWj6NlBnCnDCvey1tE63wT3gYvnT5I1czNotTunWgPwwvlUd778AkbFz
YccPGuReELp29jyn5VjjwL3SmRzbjsaB/kFzUi2zLXc5xZtJ6ZkbayGt/rSNnjwS
2bjsGievaaG2oMMdTQAzG5daYlO52W6FKfgp8Ee6q8hh9D9dxb04TDA3hT7fLqYA
yiklsq0e+xs1qsgIgUJMNji8JvqNy17VecK3MG3DqbeeGNZBr2BaTynFwGGu4KMI
IyvW++I5p5C4tT40QAn+56nPixKW/4cTD+W6Wprw0Ff7jC6HyFz5RyJBpiyMnxkn
epZtvx0krEpg/0zQ3knL
=lXAd
-----END PGP SIGNATURE-----

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

