Re: Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

Ted Lemon <ted.lemon@nominum.com> Tue, 21 July 2015 12:26 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46171A026C for <ietf@ietfa.amsl.com>; Tue, 21 Jul 2015 05:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 OSixrPAX7LTg for <ietf@ietfa.amsl.com>; Tue, 21 Jul 2015 05:26:07 -0700 (PDT)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592821A0178 for <ietf@ietf.org>; Tue, 21 Jul 2015 05:26:07 -0700 (PDT)
Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 3E4BBDA0089; Tue, 21 Jul 2015 12:26:07 +0000 (UTC)
Received: from [10.0.20.218] (71.233.41.235) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 21 Jul 2015 05:26:00 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_AEDA84DB-9578-4455-A5E2-A37348479B33"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Subject: Re: Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <tsly4i9zq89.fsf@mit.edu>
Date: Tue, 21 Jul 2015 08:25:58 -0400
Message-ID: <63FECA0D-0AAD-46A9-BD42-5CB36C42DBB6@nominum.com>
References: <CD5AD7A8CCF5852BB1CE0AC1@JcK-HP5.jck.com> <DCB0DEDD-9B0F-4103-BA28-4265F20F9BAA@nominum.com> <DFB8A13C069E919B80105032@JcK-HP5.jck.com> <BF3E292D-7A3C-48D5-9B87-63B9675D098F@nominum.com> <CAKr6gn0r8VShe==CMSA=AkOH02SgXUpFARd8eiE=eP_tRS5kOA@mail.gmail.com> <E28EA91B-0F4A-4090-9C9A-0BA1325ECC34@nominum.com> <tsly4i9zq89.fsf@mit.edu>
To: Sam Hartman <hartmans-ietf@mit.edu>
X-Mailer: Apple Mail (2.2102)
X-Originating-IP: [71.233.41.235]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/aHLIlNyaJ6__jG9An5Fr-8D5kN4>
Cc: John C Klensin <john-ietf@jck.com>, IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Jul 2015 12:26:09 -0000

On Jul 21, 2015, at 7:48 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote:
> However, efficiency of implementation is a concern it's reasonable for
> the IETF to value and we typically value it highly.
> Being able to implement things like TOR on top of sox shims, and being
> able to implement hidden services on top of SOX shims is very valuable.
> It allows us to add support for hidden services without modifying the
> end applications.

Absolutely.   However, it is perhaps worth noting that there is a long-standing solution to the problem that doesn’t require socks: nsswitch.conf.   It’s not the right architectural solution either, for a couple of reasons: not an appropriate UI for non-hackers, and a bit too dependent on the list of things switched being small.   But the point is that this is actually a pretty well-understood problem, and if, as a policy, we continue to add special-use names as required, the solution to the problem of how to handle these special-use names in the host stack is already well understood.