Re: ietf.org unaccessible for Tor users

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 15 March 2016 11:39 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BD512D995 for <ietf@ietfa.amsl.com>; Tue, 15 Mar 2016 04:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 cegiqR-966xz for <ietf@ietfa.amsl.com>; Tue, 15 Mar 2016 04:39:37 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CE112D991 for <ietf@ietf.org>; Tue, 15 Mar 2016 04:39:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4757ABE3E; Tue, 15 Mar 2016 11:39:36 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vL65W-01cOGd; Tue, 15 Mar 2016 11:39:29 +0000 (GMT)
Received: from [10.87.49.100] (unknown [86.46.23.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C8FF3BE38; Tue, 15 Mar 2016 11:39:28 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458041969; bh=gyROWlAZvx7y9MvXiK+caqWWZqrIpeBvnyk6o4jE6eo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Ve9gzJpBZ1RwkCP5FE2BttDYW00zqT1ij/anoIaoZ6aALmg+BA6bJPl1sFLNcyIAO TitjMB0EllZhqOOtOGLrvuyMLEuLNIafuk2qrBpVxu925F412EdswDVHMG4gIypZFS xk9s3T8El/T/+vREQqykx8KQ5Ybla8yy9wd46PGM=
Subject: Re: ietf.org unaccessible for Tor users
To: cdel@firsthand.net, Eliot Lear <lear@cisco.com>
References: <20160313143521.GC26841@Hirasawa> <m2a8m0y72q.wl%randy@psg.com> <F04B3B85-6B14-43BA-9A21-FC0A31E79065@piuha.net> <56E7E09D.7040100@cisco.com> <56E7E16C.4050803@firsthand.net> <56E7E327.2090803@cisco.com> <56E7F273.4030708@firsthand.net> <56E7F352.8050506@firsthand.net>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56E7F470.1090104@cs.tcd.ie>
Date: Tue, 15 Mar 2016 11:39:28 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56E7F352.8050506@firsthand.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000909080802030807030509"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/IrquvTvkyfkOJV91eiMGi2ZPk_E>
Cc: Yui Hirasawa <yui@cock.li>, IETF Disgust List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2016 11:39:39 -0000


On 15/03/16 11:34, Christian de Larrinaga wrote:
> The question is does IETF need that policeman to do that filtering? Is
> it desirable? I don't get the sense that it is.

I believe there have been attacks in the past that had they
been at larger scale could have taken the IETF site offline.
CF are a mitigation for that. I think some such mitigation
is sadly necessary. But I also think we want that to work
better, to not track folks and to not get in the way of access,
unless taking such actions is really necessary. (I don't think
it is myself, at least not in the normal course of events, but
then I don't see the operations stuff.)

Cheers,
S.