Re: the names that aren't DNS names problem, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt>

[Douglas Otis <[e-mail]>]

On 7/21/15 9:20 AM, Eliot Lear wrote:
> Hi,
> 
> On 7/20/15 9:22 PM, John Levine wrote:
> 
>> [John Klensin's question about taking all of this back to ICANN] is an excellent question, and I suppose it couldn't hurt to ask.
>> But I have little confidence that ICANN in anything like its current
>> form, where it is dominated by people who want to collect rent on
>> every imaginable TLD, would come up with an answer any better than let
>> them pay $185K and take their chances.
> 
> That's exactly it.  Some mechanism is needed to address pragmatics of a
> situation, something that the IETF has a pretty good (albeit not
> perfect) record on addressing.  That mechanism could sit at ICANN, the
> IETF, or even both organizations.  No matter what one's opinion of Tor
> is, the fact is that it's out there and in use.  They don't intend that
> the DNS be used, and yet there is clearly an interaction between the two
> namespaces at the CA level.  It's possible that the CA people could have
> created a new usage constraint, but history shows that the extension
> isn't well accepted, and that could actually hinder secure deployment.
> 
> And so to those who think ICANN should reserving names, one reasonable
> question would be “why haven't they done so?”  Perhaps the answer is
> that they have sufficient confidence in the approach that we are
> following that they don't feel the need to do anything else.
> 
> Someone noted that having a lengthy argument on the IETF list about this
> a bad thing.  If we had to repeat the principles argument without any
> new information or ideas, I would tend to agree.  But otherwise this
> discussion has served as a healthy self-limiting function over the
> growth of 6761 reservations; which is exactly what should happen, and
> perhaps the reason why folks at ICANN should be very confident in the
> IETF's decision process in this regard.
> 
> And it call comes down to pragmatics, which, John, you highlighted in
> your first comment about All of This.  That's why I support the draft
> going forward.

Dear Eliot,

Not all names resolve with DNS. For example, mDNS
automatically adds '.local' (RFC6761) to service names to
imply mDNS resolution. '.onion' informally implies Tor
although mentioned in RFC4303. To support home environments--
https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-00
introduces the '.home' TLD.  Great for those handy with ASCII.

'.home' however is likely derived from user input. IPv6 Home
Networking Architecture Principles (RFC7368) suggests
Ambiguous Local Qualified Domain Name (ALQDN) space and
gives an example of '.sitelocal'. This seems to imply use of
a trailing '.' is acceptable.  Lack of 'xn--' prefix with
non-ASCII UTF-8 (more than 7 bit) and the lack of  A-Label
collision could indicate a sitelocal TLD.  A-Label versions
might leak to DNS so local services should authenticate
clients in some manner (likely by a sitelocal IP address).
Special handling of 'xn--" prefixes could offer non-ASCII
users a friendly DNS escape mechanism and not require
exhaustive lists of IDNA special use equivalent versions.

Regards,
Douglas Otis