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

[manning <[e-mail]>]

Hum…   “domain-looking-string” …  Per RFC 1945, we read:
"3.2.2 http URL


   The "http" scheme is used to locate network resources via the HTTP
   protocol. This section defines the scheme-specific syntax and
   semantics for http URLs.

       http_URL       = "http:" "//" host [ ":" port ] [ abs_path ]

       host           = <A legal Internet host domain name
                         or IP address (in dotted-decimal form),
                         as defined by 
Section 2.1 of RFC 1123
>

       port           = *DIGIT”

So then the question on the table is,  What is a “legal host domain name”?   RFC 1123, using SMTP as the example, says:

"5.3.5  Domain Name Support

         SMTP implementations MUST use the mechanism defined in 
         Section 6.1 for mapping between domain names and IP addresses.  This
         means that every Internet SMTP MUST include support for the
         Internet DNS.”

This STRONGLY suggests that “domain-looking-string” is , in fact,  a host that is identified using the Internet DNS.



manning
[e-mail]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102



On 2July2015Thursday, at 9:59, Hugo Maxwell Connery <[e-mail]> wrote:

> manning,
> 
> The "defense" is the defense of the privacy of their community
> due to the commonality of the URI format.
> 
> (protocol)://(domain-looking-string)/(path).
> 
> Open that with the "right" software and all is good, no privacy is
> lost, and the DNS is not involved.  Open it with
> DNS based software and you leak information / lose privacy.
> 
> It is that simple.
> 
> The negative registration is to minimize info leakage and loss of 
> privacy, which apparently we care about.
> 
> Hugo Connery
> --
> 'If privacy is outlawed, only outlaws will have privacy.' P Zimmerman.
> ________________________________________
> From: DNSOP [[e-mail]] on behalf of manning [[e-mail]]
> Sent: Thursday, 2 July 2015 18:40
> To: Hugo Maxwell Connery
> Cc: [e-mail]
> Subject: Re: [DNSOP] back to: Some distinctions and a request
> 
> If that is the case,   that these folks don’t want to use the DNS name-address resolution at all, then
> there should be no objection to use of those labels in the DNS by folks who DO wish to use DNS
> for its intended purpose.   If House Finch Feathers OY  applies to ICANN for the .ONION TLD, there
> should be zero objection, since other use is outside the scope of the DNS.
> 
> the use of a “reserved label” registry simply for “defensive” purposes is properly outside
> the scope of the IETF goal of defining and developing Internet Protocols.
> 
> As to Andrews excellent attempt to disambiguate name space for domains and the DNS, I appreciate
> effort, but the facts are that overlaps occur in real life (see also:  acronym overload)  and the name space
> in question is the DNS view of the name space, not domain name space en-toto.    (whee - hows that for
> a run-on sentence!)
> 
> manning
> [e-mail]
> PO Box 12317
> Marina del Rey, CA 90295
> 310.322.8102
> 
> 
> 
> On 2July2015Thursday, at 9:04, Hugo Maxwell Connery <[e-mail]> wrote:
> 
>> 
>> Hi Mr Lewis, and list,
>> 
>> 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.
>> 
>> 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.
>> 
>> Additionally, they wish to protect the privacy of their users by
>> having the DNS reject to resolve these names.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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).
>> 
>> 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.
>> 
>> 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).
>> 
>> 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.
>> 
>> 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.
>> ________________________________________
>> From: Edward Lewis [[e-mail]]
>> Sent: Thursday, 2 July 2015 14:51
>> To: Hugo Maxwell Connery; Andrew Sullivan; [e-mail]
>> Subject: Re: [DNSOP] back to: Some distinctions and a request
>> 
>> On 7/2/15, 6:02, "DNSOP on behalf of Hugo Maxwell Connery"
>> <[e-mail] on behalf of [e-mail]> wrote:
>> 
>>> Hi,
>>> 
>>> I think that Andrew's effort to distinguish between a domain name and
>>> a DNS name is useful.  It gives us some clear terminology to use to
>>> discuss domain names that wish to use a non-DNS name resolution
>>> method.
>> 
>> Until this message, I wasn't clear on Andrew's distinction - we have been
>> talking off-list for the past few days too.
>> 
>> To me a domain name is: a sequence of bits that, when rendered in hex
>> notation, can look like this:
>> 
>> 0x03 0x61 0x62 0x63 0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x00
>> 
>> That is what is sent over the wire, through ports and is deposited in
>> memory of name servers.  Note the lack of dots.  And this is why I can't
>> see a difference between domain names and DNS names.  To me, they are one
>> in the same.
>> 
>> This dates back to a discussion had while the labs I was in was developing
>> DNSSEC code.  Our boss (Russ Mundy) made the statement that there are two
>> versions of a domain name, on-the-wire and in-the-file and it was the
>> on-the-wire format that mattered.  Later in my career I worked with a firm
>> that developed it's own DNS code based on some legacy stuff from it's
>> start-up days.  The start-up operated on the in-the-file format,
>> converting to and from on-the-wire format constantly.  This was not a good
>> approach.
>> 
>> So when I hear "domain name" I think of the format that includes an octet
>> with flags and a number and then that number of octets of data,
>> terminating with a null octet.  What is seen in files is just a
>> transliteration of that, "abc.example." is just a conventional way to
>> represent the domain name above.
>> 
>> Now, if times have changed and a broader audience thinks "abc.example." is
>> a domain name, there's a need to document that.  In an old RFC there are
>> rules for representing a domain name in a file, rules that are
>> inconsistently understood and applied.  Maybe it's not times, it's
>> perspectives.  I'm coming up through the DNS, I didn't come across the DNS
>> from application space.
>> 
>> What I mean by rules inconsistently applied is a case of apparently
>> mis-aligned RFCs on ENUM.  In one RFC, domain names were presented as
>> conversions to ASCII and the other following the rules of the old RFC for
>> escaping characters.  Specifically, a back-slash was the issue, in one RFC
>> it was bare, in the the other escaped, and this difference caused
>> implementers of ENUM code headaches.
>> 
>> (I should look this up.  I lost the notes on that incident, but probably
>> can try to dig up the references.)
>> 
>> I'll ask this, are these (thought to be) domain names:
>> 
>> \097\098\099.example.  { 97 is the decimal equivalent of 'a' in RFC 20's
>> ascii table }
>> 
>> \a\b\c.example.
>> 
>> example.中国. {latter two characters are Chinese, meaning the country of
>> China}
>> 
>> 现在我跟老婆住华盛顿可是以后我飞到IETF.练习 { a sequence of Chinese
>> charaters, IDNA2008 code
>> says label too long }
>> 
>> The latter is a placeholder for names that would be "too long" for the DNS
>> but otherwise look like, in a file, a domain name.  This is said to be
>> true in Tor's use.
>> 
>> I am not asking to be facetious.  I have had to deal with these questions
>> over the years.  The latter I have code to test because I'd been asked to
>> look at official names of geographic regions and whether what would
>> 'appear' to be a domain name from that could possibly be carried across
>> port 53.
>> 
>> If there is a distinction to be made between domain names and DNS names,
>> the former needs to be defined first. What are the rules in an http:// or
>> ftp:// URL?  Colloquially I think the first name is a 'domain name' but I
>> have never been able to trace that down.  I doubt that the 'domain name'
>> there is ever processed in on-the-wire format (as I started with) until
>> the DNS stub resolver accepts the request and spits out something to a
>> recursive server at port 53 somewhere.
>> 
>> (This omits the other under-worldly distinction of what names are eligible
>> for registration, etc., which is a distinction I've had to deal with.  In
>> a world where one can write in any script with any kind of pen or pencil,
>> you have to know where do, um, draw, the line.  IDNA2008?  Punycode?
>> Different rules for different systems?  And, is the "domain" of the
>> problem all code, all protocols, or what's in common use on the global
>> public Interent?)
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop