RE: ietf.org unaccessible for Tor users

"Tony Hain" <alh-ietf@tndh.net> Wed, 16 March 2016 22:34 UTC

Return-Path: <alh-ietf@tndh.net>
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 5FBD012D568 for <ietf@ietfa.amsl.com>; Wed, 16 Mar 2016 15:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.792
X-Spam-Level:
X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1056-bit key) reason="fail (bad RSA signature)" header.d=tndh.net
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 caYZPPxgvJiC for <ietf@ietfa.amsl.com>; Wed, 16 Mar 2016 15:34:10 -0700 (PDT)
Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D7F12D591 for <ietf@ietf.org>; Wed, 16 Mar 2016 15:34:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:Cc:To:From; bh=nuQa6IQaHhAst9eySpRwn9Rzc6LFVLaloYUqiAp68WA=; b=AVpdpba8+DhpTOfST6AXnwaP24yDaEIgUtvSxr575Qui7TU1WtGYzyigvIiBqYMn+KC5S0j8UCTqHwYqfIo4odJwAX5BQ1yGWdrkcQoZS7DLlB1HoVCwfpmf3bJ3NMoP2qpSRMHsjAUA7HSnbmKOG5+aQ3YBkKXWepLwViD3oq00mUsP;
Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <alh-ietf@tndh.net>) id 1agK0V-000DiR-CH; Wed, 16 Mar 2016 15:34:07 -0700
From: Tony Hain <alh-ietf@tndh.net>
To: 'John C Klensin' <john-ietf@jck.com>
References: <20160313143521.GC26841@Hirasawa> <m2a8m0y72q.wl%randy@psg.com> <F04B3B85-6B14-43BA-9A21-FC0A31E79065@piuha.net> <56E7E09D.7040100@cisco.com> <4349AFDD-350C-4217-9BEE-3DBD2F608F95@nohats.ca> <27177.1458050662@obiwan.sandelman.ca> <m2k2l3qud5.wl%randy@psg.com> <56E90304.3050407@cisco.com> <m2bn6eq59r.wl%randy@psg.com> <56E904A7.80200@cisco.com> <m2a8lyq4ud.wl%randy@psg.com> <56E90BF9.4090306@cisco.com> <56E9AC23.8060109@nostrum.com> <56E9B436.2090203@cisco.com> <56E9B543.9080000@nostrum.com> <56E9B5FF.1080301@cisco.com> <56E9B836.9080601@nostrum.com> <56E9C0CA.7040006@comcast.net> <05f501d17fc4$4fb87020$ef295060$@tndh.net> <DD99774DAA09AA2C9FA8C856@JcK-HP8200.jck.com>
In-Reply-To: <DD99774DAA09AA2C9FA8C856@JcK-HP8200.jck.com>
Date: Wed, 16 Mar 2016 15:33:31 -0700
Message-ID: <060101d17fd3$defd6330$9cf82990$@tndh.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQCYuprwAvKyFpb6R3oKJWUW1izoNwJVk0V8AYOaxoAB6w+j0AHSifbDAiUdjGECL5ybsgGPkrRUAf+1uPIB1qoSJwFVTGNvAgcs9MoA5jzeCQGohlndAhG5OwMBziCzMwHvyz60AeHiN1AC478EzwHIs8xUoLFTb/A=
Content-Language: en-us
X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a
X-SA-Exim-Mail-From: alh-ietf@tndh.net
Subject: RE: ietf.org unaccessible for Tor users
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on express.tndh.net)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/C9XLI44JJlu2fL2kyhw4WIJSb1c>
Cc: 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: Wed, 16 Mar 2016 22:34:11 -0000

Michael StJohns wrote:
> I'm still trying to wrap my head around an "I must not be caught"
> protocol designer.

Funny, but I thought the target of the documents was "implementers". While
it is easy to look around an IETF meeting and start to believe that the
documents are "by and for protocol designers", that should not be the case.
It should also not be hard to believe in an "I must not be caught"
implementer an app that used IPsec. 


John C Klensin wrote:
...
> 
> Noting the above including the repeatedly-asked question of who needs
> this and why the IETF should assume the costs and also noting that we've
> discontinued mechanisms for accessing IETF materials when too few people
> were using them 

The flip side of that is that having a Tor router implemented as suggested
would provide the appropriate count of how much it gets used.

(the RFC printing and (postal) mailing service being only
> the most prominent
> example), let me suggest something far more simple:   It has
> been firm IETF policy for a very long time that there are no restrictions
on
> mirrors of IETF files and data and redistribution of IETF mailing lists.

True, but that in itself constitutes an attack vector. If someone wanted to
subvert anyone that was trying to use Tor to access the IETF documents, the
easiest thing to do would be to create the proposed mirror, but make subtle
and incompatible changes to the documents so that any implementation based
on them would fail. If the implementer had no way to reference the correct
documents without exposing themselves, they would never know there was a
change.

> Assuming that the sum of the number of people who want or need to access
> IETF materials via TOR and the number of people who feel strongly about
> helping the first group(s) protect themselves is non-trivial (from the
> amount of impassioned discussion on the topic, we already know that sum
> is not-zero), why don't those people simply set up an appropriate mirror,
> establish whatever access mechanisms that suit their needs and
> requirements, and go happily on their way?

I would argue that the community of implementers that believed they need Tor
access would be better served by knowing the documents came from the 'source
of truth' on the matter, and that any future questions about usage quantity
would be easy to answer. 

> That would avoid both the stresses on IETF services and staff that concern
> Mike (and me) but also any disclosure to IETF personnel about who was
> using the service and why -- disclosure that, under the proposed privacy
> policy, might become public information.

While I agree that this is likely best set up, tested, and well documented
by 'motivated volunteers', I don't believe that pushing the entire operation
out the door is the correct response. If the privacy policy would disclose
who and why this was being used, it probably needs tuning up anyway. The
only thing that should be exposed about an explicitly 'anonymous access
path' is the count of users. Disclosing where, why, or what, would only
serve to curtail usage as a means to justify shutting it down. That said,
there would likely need to be policy about who has access to the information
that the Tor node knows, to avoid accidental release of information.

Tony