Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion S

On Aug 10, 2015, at 9:50 AM, Ted Hardie <ted(_dot_)ietf(_at_)gmail(_dot_)com> 
wrote:
> I believe that the registry we have currently defined doesn't do a great job 
> of capturing the actual needs here.  It doesn't define what the larger 
> namespace encompassing the DNS is or could be well, and it doesn't provide a 
> way to note the continuing evolution of the non-DNS resolution processes.  It 
> does a fine job with .example since that's fundamentally just a reservation, 
> but .onion is showing its warts.
>
> I understand the urgency of the .onion case, but I suspect that we're going 
> to have to split it back out of the current registry once we have fixed the 
> problems with the registry itself.  I am wondering if there is a way forward 
> here where we permit the registration in the existing registry, but with a 
> note that it will likely move into either a different registry or an expanded 
> registry in the future.


Hi Ted, thanks for the feedback.

I don’t see any question in the above which impinges upon the draft so much as 
being related to internal operations of IETF and/or DNSOP, but I’d like to 
reinforce that CA/B-Forum are apparently happy so long as “.onion” is part of 
the recognised global namespace.

The minutiae of which bucket that lives in is probably not an issue? (Tag: Mark 
Nottingham, Richard Barnes)

It strikes me that if labels “beneath” the .onion special domain name may in 
future exceed the bounds expected of DNS - but the root is acknowledged to have 
global legitimacy - then it’s all to the better that DNS software is aware of 
“.onion” and basically ignores it, which it the other intent of the draft.


In an e-mail elsewhere I recently noted:

> > A scan of section 3.2.2 of RFC3986 “Uniform Resource Identifier (URI): 
> > Generic Syntax” - I won’t claim to have read the whole thing - seems quite 
> > open to the existence of [namespaces other than DNS being used in URIs]:
> >
> > A host identified by a registered name is a sequence of characters usually 
> > intended for lookup within a locally defined host or service name registry, 
> > though the URI's scheme-specific semantics may require that a specific 
> > registry (or fixed name table) be used instead. The most common name 
> > registry mechanism is the Domain Name System (DNS).
> >
> > [...dns format description elided...]
> >
> > This specification does not mandate a particular registered name lookup 
> > technology and therefore does not restrict the syntax of reg-name beyond 
> > what is necessary for interoperability. Instead, it delegates the issue of 
> > registered name syntax conformance to the operating system of each 
> > application performing URI resolution, and that operating system decides 
> > what it will allow for the purpose of host identification. A URI resolution 
> > implementation might use DNS, host tables, yellow pages, NetInfo, WINS, or 
> > any other system for lookup of registered names. However, a globally scoped 
> > naming system, such as DNS fully qualified domain names, is necessary for 
> > URIs intended to have global scope. URI producers should use names that 
> > conform to the DNS syntax, even when use of DNS is not immediately apparent, 
> > and should limit these names to no more than 255 characters in length.
Nothing appears in there about DNS’s (semantic) 63-character label lengths, 
instead the constraint defined is DNS “syntax” - arguably "strings of 
alnumhyphen separated by dots" - and an overall 255-character length limit.

Next-generation Onion Address Syntax has not yet been agreed, but the current 
plans exist within this syntax-and-255-limit definition, eg:
> a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion # first label 
> exceeds 63 characters, hypothetical illustration only
Existing Onion-Address Syntax (facebookcorewwwi.onion) is completely within 
existing DNS’s apparent semantics as well as syntax.

Of course, this is orthogonal to the matter of registries within registries 
which you raise above, but I feel it worth raising.

    -a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

signature.asc
Description: Message signed with OpenPGP using GPGMail