Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

joel jaeggli <joelja@bogus.com> Sat, 21 March 2015 19:56 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955F91A0193 for <dnsop@ietfa.amsl.com>; Sat, 21 Mar 2015 12:56:57 -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 KkJ_JeQrszXZ for <dnsop@ietfa.amsl.com>; Sat, 21 Mar 2015 12:56:56 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 38D8F1A001C for <dnsop@ietf.org>; Sat, 21 Mar 2015 12:56:56 -0700 (PDT)
Received: from dhcp-88c0.meeting.ietf.org (dhcp-88c0.meeting.ietf.org [31.133.136.192]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t2LJuqKH094223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 21 Mar 2015 19:56:53 GMT (envelope-from joelja@bogus.com)
To: Andrew Sullivan <ajs@anvilwalrusden.com>, dnsop@ietf.org, Richard Barnes <rlb@ipv.sx>
references: <CAFggDF0XX3v7yGsaCwFnE7cjK0yz4-frxFgoBJfnztO8k-LFBg@mail.gmail.com> <alpine.LFD.2.10.1503162052420.20709@bofh.nohats.ca> <D12DE3BF.B714%alecm@fb.com> <CAL02cgS95hx6tWH36COGva5fx8NhPUebcPKdNqXs+u4rCcr4nQ@mail.gmail.com> <20150318011115.GG4385@mx1.yitter.info>
x-enigmail-draft-status: N1110
From: joel jaeggli <joelja@bogus.com>
message-id: <550DCD03.1050905@bogus.com>
Date: Sat, 21 Mar 2015 14:56:51 -0500
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Thunderbird/37.0
mime-version: 1.0
in-reply-to: <20150318011115.GG4385@mx1.yitter.info>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="BWPxnquC3mu6GenBLI1AcvllSlgdrD1ko"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/Qk-x4fptrsASD3HOEBW_Thp53Go>
Subject: Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Mar 2015 19:56:57 -0000

On 3/17/15 8:11 PM, Andrew Sullivan wrote:
> On Tue, Mar 17, 2015 at 12:59:25PM -0400, Richard Barnes wrote:
>>>>
>>>> If an application does not implement tor, and is not tor aware, it
>>>> _will_ do a DNS lookup. You can't really go ask the world to stop
>>>> doing that. You need to deal with that fact.
>>>
>>
>> The entire point of the special use domains registry is to tell general
>> clients how to behave with regard to special-use names.  It exists
>> precisely to tell the world the DNS names for which they should not do
>> lookups, because they require different handling.
> 
> Actually, my understanding is that the point of the special use
> domains registry is to create a repository for applications so that,
> _if_ they are looking at names in domain name slots and trying to do
> something sensible, they know where to look to learn about those
> sensible things.
> 
> There is no way for a document to specify, "Don't look stuff up in the
> DNS."  If we had a reliable way to make that rule, AS112 wouldn't have
> been necessary.  I think there's nothing wrong with the document
> saying that you _shouldn't_ look them up, because they're promised not
> to give you a response anyway so it's just pollution traffic.  But do
> not delude yourself into thinking that adding stuff to the special
> names registry will do anything to prevent leaking.  It will not.

it certainly cannot prevent leakage from resolvers unaware of the new
reservation.

something like  the .alt probably might once iplemented, do so for
future spaces assuming it were used.

> A
>