Hi Alec,
On Mon, Aug 10, 2015 at 11:04 AM, Alec Muffett <alecm(_at_)fb(_dot_)com> 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