Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

[Ted Hardie <[e-mail]>]

Hi Alec,

On Mon, Aug 10, 2015 at 11:04 AM, Alec Muffett <[e-mail]> wrote:

>
> 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.
>
>
​You are correct, it was not a question for the draft itself. ​

The minutiae of which bucket *that* lives in is probably not an issue?
> (Tag: Mark Nottingham, Richard Barnes)
>
>
​I think the Internet community needs to understand that a reservation in
the encompassing name space means that no gTLD with the same string will be
permitted in the DNS and understand who has the right specify the process
by which the names within .onion are minted and assigned.



> 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.
>
>
​As you allude to below, it is not that DNS software must ignore it, it is
a requirement that software that might presume it is within the DNS context
will become aware of the correct context.   ​



>
> 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.*
>
>
>
​This is a little bit more complicated than the above suggests, because a
specific URI scheme can describe in detail which elements of RFC3986 syntax
are expected within it.  See, for example, RFC 6068, Section 2
<http://tools.ietf.org/html/rfc6068#page-3> for the syntax of the mailto:
URI (which is fundamentally different from URI schemes which use path
elements in the way HTTP does). RFC 7595
<https://tools.ietf.org/html/rfc7595> has some additional detail in the
context of registrations.

In a previous attempt at tackling the deployment of Distributed Hash
Table-based names, Vidya Narayanan and I described an overlay authority
scoped to specific overlay networks rather than the DNS (see:
https://www.ietf.org/archive/id/draft-hardie-p2psip-p2p-pointers-01.txt for
details), but the presumption we worked from was that you were dealing with
new URI schemes. In this case, I believe .onion names that intend to be
carried in URI slots that would also carry non-.onion names will either
have to confirm that the URI's scheme-specific part permits it or update
the syntax to do so.


> 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.
>
>
​I believe that it would be valuable to check the proposed syntax against
the individual schemes' scheme-specific-parts as part of the deliberations.

regards,

Ted Hardie




>     -a
>
> —
> Alec Muffett
> Security Infrastructure
> Facebook Engineering
> London
>
>