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

Ted Lemon <ted.lemon@nominum.com> Wed, 15 July 2015 17:16 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 A35381A700C; Wed, 15 Jul 2015 10:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oi1bXGyEABog; Wed, 15 Jul 2015 10:16: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 7EEA21A6F27; Wed, 15 Jul 2015 10:16:06 -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 75FABDA0077; Wed, 15 Jul 2015 17:16:06 +0000 (UTC)
Received: from [64.89.225.79] (64.89.225.79) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 15 Jul 2015 10:16:06 -0700
Message-ID: <55A69556.9020207@nominum.com>
Date: Wed, 15 Jul 2015 10:16:06 -0700
From: Ted Lemon <ted.lemon@nominum.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Edward Lewis <edward.lewis@icann.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard
References: <20150714192438.1138.96059.idtracker@ietfa.amsl.com> <D1CBC489.D039%edward.lewis@icann.org>
In-Reply-To: <D1CBC489.D039%edward.lewis@icann.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [64.89.225.79]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/DONDMLIfh1AmDwpXdPp7X25nyOM>
Cc: "dnsop@ietf.org" <dnsop@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: Wed, 15 Jul 2015 17:16:08 -0000

On 07/15/2015 05:42 AM, Edward Lewis wrote:
> As David says, .onion-names use is independent (to some extent) on whether
> "onion" is registered in the Special Use Domain Names registry.  What I am
> writing here isn't a statement about whether "onion" is to registered, but
> about the document applying for registration.

No, it's not independent, because .onion sites won't be able to get PKI 
certs if we don't do the allocation.
> The document defines the use of the name by referring to a couple of
> references, none of which appears to be published in a way that can be
> referenced except by URL.  Not to say that the documents seen are poorly
> written, still there's no evidence of peer review nor stable reference
> point.
We discussed this at length in the working group, in which I believe you 
participate.   It is clearly understood that TOR is effectively an SDO 
that has defined a standard using their own system of publication and 
their own standardization methodology, which is different than the 
IETF's methodology for very good reasons. Requiring another SDO to 
follow IETF process in order to get an allocation of this type doesn't 
make sense and isn't required by the governing standard.

> The document also shows no evidence of the deployment of the use of the
> names below "onion."  In David's email, and in others, there are comments
> regarding an "installed base".
Are you claiming that there is not widespread deployment of TOR? There 
was no controversy in the working group on this question: nobody there 
claimed that TOR wasn't sufficiently widely deployed to justify allocation.
> I really believe that for DNS elements, there should be no change.  By
> intent, the onion names are not to be presented to the DNS by what's in
> category 2 and 3 (Applications and Name Resolution API's respectively).  I
> see placing any requirement on DNS elements - and by that I mean the
> software used to implement the DNS standard - as a bad idea, under the
> heading of "permanent fix to a temporary situation."  (I.e., Tor may not
> be permanent, if it is, as software matures onion names will not be in DNS
> queries.)

I think this is a reasonable position to take, with one exception. I 
think it's fine for the document to make recommendations about what name 
servers and the root should do, but it's not our place to make 
requirements, nor do I think it's necessary.   However, it would be very 
beneficial for host implementations to special case .onion, as some 
hosts do for .local now.   When hosts fail to apply appropriate special 
case handling for .local, it creates operational annoyances, to no 
benefit.   In the case of .onion, it creates a privacy problem.   So I 
don't mind this text as much as you do, but I do wonder if we'll 
actually see widespread implementation of such requirements.
> I'm agreeing with Ted in that this application is insufficient.

Whoa there, cowboy!   I didn't say it was insufficient.   I proposed 
changes to the text that I think would result in it better expressing 
what I think was intended.

And also, please don't call it an application.   It is an internet 
draft, which has passed working group last call, and is in IETF last 
call.   An application would be something that would be handled by the 
IESG, through the instrumentality of the IANA.