Re: [DNSOP] back to: Some distinctions and a request

Edward Lewis <edward.lewis@icann.org> Thu, 02 July 2015 18:33 UTC

Return-Path: <edward.lewis@icann.org>
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 5CFB31A8886 for <dnsop@ietfa.amsl.com>; Thu, 2 Jul 2015 11:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.431
X-Spam-Level:
X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_24=1, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 lbf6sQVtirXv for <dnsop@ietfa.amsl.com>; Thu, 2 Jul 2015 11:33:55 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012951A8877 for <dnsop@ietf.org>; Thu, 2 Jul 2015 11:33:55 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 2 Jul 2015 11:33:52 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Thu, 2 Jul 2015 11:33:52 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: Hugo Maxwell Connery <hmco@env.dtu.dk>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] back to: Some distinctions and a request
Thread-Index: AQHQtK33drk+QB922UaqZ1na3WF2v53IVH0A///7KO+AAAhRp4AAXDyA
Date: Thu, 02 Jul 2015 18:33:52 +0000
Message-ID: <D1BAF6A1.CA8A%edward.lewis@icann.org>
References: <6CB05D82CE245B4083BBF3B97E2ED470C27498@ait-pex01mbx01.win.dtu.dk> <D1BAA21E.CA2E%edward.lewis@icann.org> <6CB05D82CE245B4083BBF3B97E2ED470C2759F@ait-pex01mbx01.win.dtu.dk> <6CB05D82CE245B4083BBF3B97E2ED470C275B2@ait-pex01mbx01.win.dtu.dk>
In-Reply-To: <6CB05D82CE245B4083BBF3B97E2ED470C275B2@ait-pex01mbx01.win.dtu.dk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.2.150604
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3518692427_1406024"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/8RMExLeyVXMwq-Pd-QYSIcQrzHo>
Subject: Re: [DNSOP] back to: Some distinctions and a request
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 02 Jul 2015 18:33:57 -0000

On 7/2/15, 12:04, "DNSOP on behalf of Hugo Maxwell Connery"
<dnsop-bounces@ietf.org on behalf of hmco@env.dtu.dk> wrote:
>
>I believe that you are making a category error here.  The key
>point is that the softwares that are using the domain name (dot
>separated network identifier) labeling system do not wish to
>use the DNS architecture for name to address resolution, at all.

That's well understood.

>However, they may wish to use the excellent transport mechanisms
>that IETF have defined over the years, including the latest version(s)
>of TLS.  I come back to this below when considering the failure
>mode of communication to a URI.

Instead of "transport" which for me and others means things like TCP and
UDP, I think you mean applications.  If I understand correctly, Tor uses
web browsers and URLs because the existing base does what Tor needs.
Which is fine.  Code reuse, etc.

>Additionally, they wish to protect the privacy of their users by
>having the DNS reject to resolve these names.

That's not a way to protect privacy.  Just asking a DNS server "leaks"
some information.  The DNS can't prevent anyone from asking, rejecting the
query is too late.  OTOH, as someone managing DNS operations, the queries
don't leak enough of the right information (although they may leak the
wrong information, with "right/wrong" a subjective call).

>We have a mechanism which reliably translates www.example.org
>into some on-the-wire byte representation and works.  This does not need
>to change, or even be investigated.

My point about on-the-wire was a tad bit obtuse.  I was trying to explain
what I thought a domain name was and relied upon the DNS protocol's
version of what goes out the socket, through the port and out over the
electromagnetic waves.  I figure the DNS itself is unique in the
formatting.

When URLs go into the electromagnetic medium, I bet they are converted
into something ascii-compatible or unicode encoded (I haven't checked).
When X.509 certificates go out, the subjectAltName holding a domain name
would be passed through ASN.1, then maybe a DER/BER/etc., and so on.  If
that's what is meant by a domain name, it's not what I was thinking.

I wasn't trying to say all applications use the DNS format, just that when
it comes to DNS names and domain names, I think of them as the same
because I usually operate on the DNS wire format.

Still, I'd like to see a common definition of what a "domain name" is in
the context of domain name use in URLs, email addresses, X.509
subjectAltName and other places I'm not listing because I'm not thinking
of them.

>Here is what I believe the non-DNS resolution softwares want:
>
>1. A registration of the psuedo top level domain [pTLD] (e.g onion, gnu)
>within the root zone as "not a domain".  i.e if anyone asks the
>answer for anything in or under that pTLD the answer is NXDOMAIN.

To some extent this is just a registration of the string in the root TLD.
Just like registering a name that will "work" the impact is about the same
up though registration.  I thought about how to scale this and make this
work seeing that there's a high application fee for positive
registrations.  I don't have a clear answer. An alt-TLD is a good partial
solution, i.e., reserving one string the root is something I can see as
possible but not a TLD per "not a domain" domain-looking namespace.

E.g., One concern is confusability between names.  Like, is example. and
ex<cyrillic-a>mple. the same thing?  This has been an issue amongst
commercial names.  But what about .bit and .b1t?  Neglecting money, cost,
budget, there's still work to be done to avoid the ensuing operational
issues that would likely follow.

>2. Iterative resolution software to also be aware of this, such that
>they have a permanent in cache response to hand out NXDOMAIN
>without bothering the root zone's resolvers (and exposing the query).

That's a lot of code to distribute.  And existing code bases don't do this
now.  (Yes, the usual excuse for not innovating.)  The reality is you
can't stop someone from asking overnight.

I could see such software consulting the special use domain name registry
and dynamically deciding how to resolve the name.  But that's generations
(of code) off into the future.

>3. qname minimisation to be approved and implemented.  In this case,
>if 2. is not achieved the exposure of the end user system is dramatically
>limited.

I see this as a non-sequitir.  If one is not supposed to ask the DNS, then
it doesn't matter.  If one is leaking, this only means that some of the
authoritative servers don't see the intended name, the recursive does.

>All of the above is "worst case usage" from these softwares.  Normal
>operation is that the DNS architecture does not even see these name
>resolutions happening -- they use whichever mechanism they have
>designed and implemented -- the end user is satisfied (assuming their
>mechanism works) and the DNS knows nothing.
>
>Consider the URI https://asdfasdfasdfasdf.onion/my-holiday/
>
>When entered into the Tor browser, the DNS sees absolutely no traffic, at
>all,
>irrespective of whether the "domain name" exists.  E.g if
>asdfasdfasdfasdf.onion
>is not defined within the Tor network, still the DNS sees nothing.
>However, some configuration of a recently defined TLS transport is used
>(https).

If that's the case, why is this being discussed in DNSOP? ;)

>When opened with a regular browser, the use of the Tor network is
>exposed, as described above.  The communication will fail, as
>the asdfasdfasdfasdf sub-domain is not registered (and hopefully
>not registerable).  We are talking about *how* it fails, and reducing
>the leaking of information in that process.

In this case the users also have 0 availability of the desired object.

>
>All of these on-list discussions are about point 1. above; Negative
>registration
>in the root zone via RFC6761.
>
>Steps 2 and 3 are, I expect, also on the agendas for these overlay
>networks,
>because they care about the privacy of their community.
>
>If point 2 could be universally achieved, points 1 and 3 are moot.
>But, that is never doing to happen, thus the current approach.
>
>Sincerely,  Hugo Connery
>
>NB: I am not a member of the community for any of these networks, and
>I certainly dont speak on their behalf.  I do use Tor regularly.