Re: ietf.org unaccessible for Tor users

Michael StJohns <mstjohns@comcast.net> Thu, 17 March 2016 01:20 UTC

Return-Path: <mstjohns@comcast.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 6219612D7E2 for <ietf@ietfa.amsl.com>; Wed, 16 Mar 2016 18:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 tncXGXY18-0a for <ietf@ietfa.amsl.com>; Wed, 16 Mar 2016 18:20:13 -0700 (PDT)
Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF69A12D518 for <ietf@ietf.org>; Wed, 16 Mar 2016 18:20:13 -0700 (PDT)
Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-10v.sys.comcast.net with comcast id WpKP1s0055Clt1L01pLDMo; Thu, 17 Mar 2016 01:20:13 +0000
Received: from [192.168.1.113] ([69.255.115.150]) by resomta-po-17v.sys.comcast.net with comcast id WpLC1s0053Em2Kp01pLCAh; Thu, 17 Mar 2016 01:20:13 +0000
Subject: Re: ietf.org unaccessible for Tor users
To: Tony Hain <alh-ietf@tndh.net>, '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> <060101d17fd3$defd6330$9cf82990$@tndh.net>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <56EA0674.10003@comcast.net>
Date: Wed, 16 Mar 2016 21:20:52 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <060101d17fd3$defd6330$9cf82990$@tndh.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458177613; bh=rHBECwca6tFxAyQWPwm919R1EjtqCRbEqM8pxnj7SJs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=uv68nD3Y9JnDcFLZZ0EPuGnM5XDl1eept7vNeLCEZ54JClVTo1AHH30L1Uj/4W1mo oYUZi5Zhpf8gWV1Q0yXu3EaQ0YIWLbT4rgmxe+9w7NdVjw9Vw2F/CfrdToCmvwaHYQ 3ih/KkbQ/InSePlXUOJ0uvcbO8HaryRWeM2saYgRrICcC38SiO0JbdD+2brgsCu/d5 bqsSsqNexGblGF5/WNu/kbngCEeuckocXOBIAAo2bmbFPaT1WLOKTAK7AGCot3Ix7c 6opgL1eJreNMm6zu0fw148Ds+EV2qNn5NiWWaHffIzlXBbo3SlHD5tlg00qeu/r5xg 2YCEXcObb4Krw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/YE5h8ZGKKdvn2JJN7IhO2HfOFKU>
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: Thu, 17 Mar 2016 01:20:15 -0000

On 3/16/2016 6:33 PM, Tony Hain wrote:
> 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.


There are  "participators" (or protocol designers) who would be expected 
to go back time and again to the IETF website to grab new stuff 
(internet drafts etc), and possibly contribute, and there "implementers" 
who are usually coming after the fact and grabbing the final document 
for implementation.  It's generally not cost effective - unless you're 
very involved in the design process - to implement the internet draft 
flavor of the week.  I think of the IETF website primarily serving the 
first group with access to the second group kind of a happy accident.  
(I'm not quite as flip about it as that, but keep in mind the target 
audience of the ID's and all of the cruft that goes with moving them 
through the standards process vs the target audience of RFC's).

So my point was more about there being lots of sources for finished 
documents (RFCs) that aren't the IETF (google Request for comments 
mirror) where someone with a Tor browser can just grab those without the 
IETF doing anything.   There are also plenty of ways for others to make 
mirrors of IETF content that don't involve intercession by the IETF 
staff (you've mentioned setting up a TOR public hidden service - I'd 
suggest that its better to have a Tor'ite do it that the IETF) - and 
many have done so.

WRT to your example - its really "implementer that built an app that 
used IPSec for something that broke some law somewhere".  It's not 
generally the IPSec per se that's a violation (or for that matter any of 
the IETF protocols), but what they get used for.  And even then, he's 
more likely to be grabbing one of the open source packages that 
implement the IETFs protocols than implementing something himself.

I mostly get where you're coming from - but I'm finding it hard to 
believe that the size of the intersection of "Tor users", "safety via 
anonymity required users" and "IETF participants" is very large - if it 
contains any elements at all.

What I've asked for is for data on the size of the problems - and what 
I've been told is that no data is to be had.  I'm OK with that, but that 
turns statements about why things are needed from objectively 
evaluatable proposals into subjective positions where either side might 
have all or part of the truth.   Or put another way, turns good factual 
arguments which I can evaluate into simple opinions which each of us 
will take with a different grain of salt.