Subject: Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 25 Nov 2015 06:40:05 +0100

Hi,

I have read this draft and have a number of comments. I can not say these are the only ones, but at least some :-)

   The dominant protocol for name resolution on the Internet is the
   Domain Name System (DNS).  However, other protocols exist that are
   fundamentally different from the DNS, but which have syntactically-
   similar namespaces.

I claim that if it is syntactically similar and the names are used interchangeable in protocols (see below) we actually DO talk about use of the same namespace. This is the camel in the tent, and I think we should just admit, or say clearly whether we do talk about, which I think we do, one name space with multiple resolution mechanisms.

   When an end-user triggers resolution of a name on a system which
   supports multiple, different protocols for name resolution, it is
   desirable that the protocol to be used is unambiguous, and that
   requests intended for one protocol are not inadvertently addressed
   using another.

It is not so much different protocols as different resolution mechanisms. If you say "protocol" here, it might sounds like if with the DNS protocol you can not use multiple different resolution mechanisms (which I think one can -- one of them using the root managed by ICANN).

   Such usage, which a few commenters have referred to as "protocol
   switching," is not limited to "protocol switch" in the strict sense
   of indicating specific protocols on the wire.  It could indicate to
   switch to another name space (eg .onion), use a different protocol
   (eg tor, or mdns), or indicate to use a local DNS scope by not using
   the DNS root for name resolution (eg .home in homenet) or something
   else altogether.

It is important (which I think also Stephane indicated) that we talk about different resolution mechanisms for the name itself. We do not talk about how to access the service in question.

   At the time of writing, three top-level domain names reserved by
   inclusion in the Registry are used by name resolution protocols other
   than the DNS:

      LOCALHOST is used to refer to the host on which the name
      resolution takes place, without reference to the DNS;

      LOCAL is used by the Multicast DNS protocol specified in [RFC6762]
      which is similar in some respects to the DNS, but which uses
      different well-known port number and is limited to a particular
      multicast scope;

      ONION is used to construct names that designate anonymous hidden
      services reachable via the Tor network using onion routing.

I think a better text to describe ONION would be:

      ONION is used to construct names that designate
      services reachable via the Tor network using onion routing.

What about EXAMPLE?

   The lack of a more elegant way to specify a
   name resolution protocol in (for example) a URI amounts to an
   architectural oversight.

Well...in the architecture we have both the URI scheme and if you look further the URN definition to manage all different kind of switches. And we do not have to wake up the old discussion again whether HTTP://EXAMPLE.COM/ in reality should be URI:HTTP://EXAMPLE.COM/

I think the key issue here is that the different "strings" that look like "domain names" (i.e. are within the same name space) are used interchangeable wherever in the URI (or even URN) definition where "domain names" are to be used.

   If we accept the notion that the most significant label of a domain
   name is actually a protocol switch, it implies that we are actually
   building a catalog of all top level domains that explain which are
   are switches.

What about not-yet-allocated strings in this catalog?

I think it is important to say that as of today (at least), the default resolution mechanism is to use the DNS, although a non-existing string today imply one apply the search path algorithm to chase down names.

   In the case of [I-
   D.ietf-dnsop-onion-tld], leakage of ONION queries on the Internet
   might lead to disclosure of private information that, in some cases,
   might pose a risk to the personal safety of end-users.

More, less or similar to leakage when people use non-FQDN and their search path create surprises?

   This document aims to provide a problem statement that will inform
   future work.  Whilst security and privacy are fundamental
   considerations, this document expects that that future work will
   include such analysis, and hence no attempt is made to do so here.

See among other places SAC-057 <https://www.icann.org/en/system/files/files/sac-057-en.pdf>

   Patrik

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 25 Nov 2015 08:24:26 -0800

On 24 Nov 2015, at 21:40, Patrik Fältström wrote:

> I have read this draft and have a number of comments. I can not say 
> these are the only ones, but at least some :-)

This is only the beginning of the conversation, so: yes. :-)

> I claim that if it is syntactically similar and the names are used 
> interchangeable in protocols (see below) we actually DO talk about use 
> of the same namespace. This is the camel in the tent, and I think we 
> should just admit, or say clearly whether we do talk about, which I 
> think we do, one name space with multiple resolution mechanisms.

We need to be *very* careful here. Are names that are 
"syntactically-similar" actually "interchangeable". I propose that they 
are not; only names that are "syntactically-identical" are 
interchangeable. There are different name schemes that are "similar" 
that are not interchangeable. For instance, I have heard that some of 
the name schemes currently being discussed allow labels over 64 octets 
long.

We also need to be very careful to say whether a name scheme is 
syntactically-identical to RFC 1035 "domain names" or to RFC 1123 "host 
names with the preferred name syntax" (LDH). For the latter, we can 
probably say "interchangeable", but we need to think hard about the 
former.

> It is not so much different protocols as different resolution 
> mechanisms. If you say "protocol" here, it might sounds like if with 
> the DNS protocol you can not use multiple different resolution 
> mechanisms (which I think one can -- one of them using the root 
> managed by ICANN).

+1

> It is important (which I think also Stephane indicated) that we talk 
> about different resolution mechanisms for the name itself. We do not 
> talk about how to access the service in question.

+1 again.

>    services reachable via the Tor network using onion routing.

Unfortunately, I agree. <insert apologies for my federal government 
here>

> What about EXAMPLE?

Which name resolution protocol uses EXAMPLE? RFC 2606 reserves it for 
examples in documentation.

> Well...in the architecture we have both the URI scheme and if you look 
> further the URN definition to manage all different kind of switches. 
> And we do not have to wake up the old discussion again whether 
> HTTP://EXAMPLE.COM/ in reality should be URI:HTTP://EXAMPLE.COM/
>
> I think the key issue here is that the different "strings" that look 
> like "domain names" (i.e. are within the same name space) are used 
> interchangeable wherever in the URI (or even URN) definition where 
> "domain names" are to be used.

Disagree, and I agree with the text in the draft. It is an oversight on 
the part of the URI spec that it does not say "these are only for names 
in the DNS namespace; if you want a different name, use URNs".

> What about not-yet-allocated strings in this catalog?

Yes, exactly. This is a major problem in this part of the draft. It is 
begging us to predict the future, and we suck at that.

> I think it is important to say that as of today (at least), the 
> default resolution mechanism is to use the DNS, although a 
> non-existing string today imply one apply the search path algorithm to 
> chase down names.

+1

> search path create surprises?

More, because .onion was designed to provide data- and metadata-hiding, 
and the search path mechanism was not.

> See among other places SAC-057 
> <https://www.icann.org/en/system/files/files/sac-057-en.pdf>

Yes, this should be added as a useful informational reference.

--Paul Hoffman

---

From: "Joe Abley" <[email-masked]>
Date: Thu, 26 Nov 2015 12:05:07 -0500

Hi Patrik,

> I claim that if it is syntactically similar and the names are used interchangeable in protocols (see below) we actually DO talk about use of the same namespace. This is the camel in the tent, and I…

That's a possible direction. However, I don't know how far we will get with that approach, since every additional example of a name resolution protocol comes with an attendant list of exceptions, e.g.

 - LOCALHOST -- it's a single, dotless name, and there's no hierarchy
 - LOCAL -- child labels can contain spaces and UTF-8-encoded symbols, single-label depth
 - ONION -- a single, fixed-width second-level label (base32-encoded first 80 bits of a SHA-1 hash) and anything at all under that (not relevant to the name resolution protocol, but perhaps useful to applications)

I think the useful point to make is that the intersection of all these sets of possible names is non-empty -- that is, you can trivially find examples of names that are legitimate to more than one name resolution protocol, and hence a potential source of confusion to end-users and applications.

> It is not so much different protocols as different resolution mechanisms. If you say "protocol" here, it might sounds like if with the DNS protocol you can not use multiple different resolution mec…

Yes, I think it would be better to choose a distinct phrase for what we're talking about here and define it early. I've used "name resolution protocol" for this, but no doubt there are better alternatives.

> It is important (which I think also Stephane indicated) that we talk about different resolution mechanisms for the name itself. We do not talk about how to access the service in question.

I agree.

>    services reachable via the Tor network using onion routing.

I think (but have no citations handy to support my thinking) that EXAMPLE is a reserved top-level label in the DNS, not an example of what Alain called a protocol switch.

> Well...in the architecture we have both the URI scheme and if you look further the URN definition to manage all different kind of switches. And we do not have to wake up the old discussion again wh…

I think we were imagining that if we could go back in time and insist that URIs such as

  http://blah-blah-base32-blah-blah!onion/index.html

unambiguously referred to the onion name resolution protocol, then there would be little chance that these names would leak into other name resolution protocols' infrastructure (like the DNS) and that might provide the basis of some kind of solution to the problem of random (e.g.) e-mailed URLs causing leakage when encountered by end-users and robots that don't know about (say) onion names.

Unfortunately, all attempts to confirm that time travel will be available to me in the future have failed, to date. So either returning to the past to change the URI specification would cause a world-ending rift in space-time, or time travel is fictional. Just quietly, I suspect it's the former.

So, given that it's too dangerous to cross the time streams to fix the URI format, let's go with the ugly but de-facto identifier we have, which is the top label. We don't have to like it, we just have to acknowledge begrudgingly that it exists. That's the intended message in the text.

> What about not-yet-allocated strings in this catalog?

The problem space includes the problem of how a future name resolution protocol architect should register a selector ("switch") for her protocol, how that registration should be handled (and by whom), and what the operational implications to everybody else will be, I think.

> I think it is important to say that as of today (at least), the default resolution mechanism is to use the DNS, although a non-existing string today imply one apply the search path algorithm to cha…

That seems sensible to me too, although I think we need to acknowledge that doing so probably risks some leakage of other namespaces into the DNS.

> More, less or similar to leakage when people use non-FQDN and their search path create surprises?

Right. There is no privacy. There is only Zuul.

I think identifying possible information leakage is responsible and sensible. I would hope we could do that without inferring that such leakage is a reason for PANIC! ALL! CAPS! hysteria, but in a practical sense I think it's important that sensible expectations are shared.

> See among other places SAC-057 <https://www.icann.org/en/system/files/files/sac-057-en.pdf>

Thanks!

Joe

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 26 Nov 2015 19:21:05 +0100

> I think the useful point to make is that the intersection of all these sets of possible names is non-empty -- that is, you can trivially find examples of names that are legitimate to more than one…

Hmm...I think I understand what you mean here. What I was after was that the strings are replaceable in the various protocol definitions where "domain name" is supposed to be. Then of course certain combination of octet values are not possible depending on various rules. By the protocol where the string is in use, and (as you point out) because of the different resolution mechanisms.

When thinking of what comes below, what do you say about EXAMPLE? What are the rules for that? ;-)

> Yes, I think it would be better to choose a distinct phrase for what we're talking about here and define it early. I've used "name resolution protocol" for this, but no doubt there are better alter…

Hmm...if I knew a good name, I would suggest it. I just stumbled myself over the word "protocol".

> I think (but have no citations handy to support my thinking) that EXAMPLE is a reserved top-level label in the DNS, not an example of what Alain called a protocol switch.

;-)

To some degree it is a protocol switch, right? It should never ever be used. /dev/null comes to mind... :-)

> Unfortunately, all attempts to confirm that time travel will be available to me in the future have failed, to date. So either returning to the past to change the URI specification would cause a wor…

...or of course ask whether all HTTP scheme URIs use DNS, which imply one should place the switch regarding resolution in the URI scheme...

> So, given that it's too dangerous to cross the time streams to fix the URI format, let's go with the ugly but de-facto identifier we have, which is the top label. We don't have to like it, we just…

Yes.

> The problem space includes the problem of how a future name resolution protocol architect should register a selector ("switch") for her protocol, how that registration should be handled (and by who…

Agree.

> That seems sensible to me too, although I think we need to acknowledge that doing so probably risks some leakage of other namespaces into the DNS.

Which to some degree we already have. Right?

>> See among other places SAC-057 <https://www.icann.org/en/system/files/files/sac-057-en.pdf>

N.p.

   paf