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

From: Wendy Seltzer <[email-masked]>
Date: Fri, 07 Aug 2015 10:29:46 -0400

On 08/07/2015 09:50 AM, Edward Lewis wrote:
> (The last call is still on...)
> 
> I am trying to write another document and wanted to include descriptions
> of ".onion" names.
> 
> I'm seeking authoritative references but am having some trouble doing so.
> This isn't meant to be a replay of my previous comment that the draft
> under discussion is poorly supported by documents - which it is to some
> extent - but I really would like to find reliable references.  The last
> call document is sparse on references, and there's not much from other
> sources I see (Wikipedia.org).

You might find https://spec.torproject.org/ helpful as a listing of
various tor specs and design documents, if you prefer that to a git
repository.

While Tor has not necessarily used IETF conventions, the project has
long been committed to public documentation of its design and protocol
choices. Tor distinguishes between "proposals," not yet implemented, and
specs.[1]

--Wendy
[1] https://gitweb.torproject.org/torspec.git/tree/

> 
> I've come across: 
> "https://gitweb.torproject.org/torspec.git/tree/address-spec.txt"
> named "Special Hostnames in Tor" by "Nick Mathewson".  This document lacks
> any mention of how to contact the author with questions, nor any
> information regarding the status of the document.  It describes ".exit",
> ".onion" and ".noconnect".  The latter is said to be obsoleted.  ".Exit"
> is defined in a way that includes a "hostname" which, from the examples, I
> assume is the term defined in RFC 1123 (and thus a DNS name).  ".Onion"
> refers to "rend-spec.txt" without any qualification but I was able to
> track that document down.
> 
> The definition of a .onion name is "the digest is the first eighty bits of
> a SHA1 hash of the identity key for
>   a hidden service, encoded in base32."  I'd heard that Onion names would
> be too long for DNS domain names, but I don't see that from the definition
> given here.  My concern is that "I hear" different stories in email than I
> read in documents.
> 
> Accessing "https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt" I
> see a document called "Tor Rendezvous Specification" with no editor/author
> credited as well as no indication of where to send questions.  It does
> invoke "RFC 2119" but does not identify that as the IETF produced document
> commonly referred to as RFC 2119 "Key words for use in RFCs to Indicate
> Requirement Levels".
> 
> According to that document, onion names (or perhaps "valid onion
> addresses" are something else) "contain 16 characters in a-z2-7 plus
> '.onion'".  Again, that doesn't mesh with the story that names are too
> long.
> 
> This may be an off-shoot, but it appears that the onion names are wedded
> to RSA and SHA-1.  This is fine, but makes me wonder about future
> stability of the protocol and hence the designation of .onion as special
> purpose, if there's ever a need to change cryptographic parameters.  I am
> mentioning this as someone not well steeped in cryptography but as someone
> exercising cryptographic algorithm agility in DNSSEC operations.
> 
> I would like to avoid trolling against the effort to reserve onion.  But
> in the effort to document other elements of name spaces, I'm having
> difficulty locating definition of onion names and this difficulty worries
> me when it comes to registering a name as special use (without a "why").
> 
> If someone can point me to a definition of how Tor treats and writes names
> "ending with .onion", I would appreciate the reference.
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 

-- 
Wendy Seltzer -- [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Fri, 7 Aug 2015 13:50:46 +0000

I've come across:

---

From: Edward Lewis <[email-masked]>
Date: Fri, 7 Aug 2015 15:26:43 +0000

>various tor specs and design documents, if you prefer that to a git

That's the site I've been using.

>choices. Tor distinguishes between "proposals," not yet implemented, and

It's fine to "not use IETF conventions".  (One of my ratholes is that I
find researching IETF documents rather frustrating - just to underscore I
am not saying Tor's documentation is deficient compared to IETF standards.)

Still, the documents I have access to do not give me a deep enough sense
of, well, why the names are different from DNS domain names.  I presume
they are from the email discussion, but what I am reading in the documents
- and I stress "reading in the documents" meaning that might be the gap -
doesn't give me enough background.

As far as stability of the documents, referring to a document by URL only
(which is accepted in IETF documents at times) isn't generally accepted.
I admit this is a bit of a red herring point, because this can be changed,
but if there were other means to refer to the document in a reference
citation, it would help.

E.g., randomly typing a four digit RFC number:

http://www.rfc-editor.org/rfc/rfc7392.txt

vs.

Dutta, P., Bocci, M., and L. Martini, "Explicit Path Routing for Dynamic
Multi-Segment Pseudowires", RFC 7392, DOI 10.17487/RFC7392, December 2014,
<http://www.rfc-editor.org/info/rfc7392>.

That is, full title, RFC document identity, date and authors/editors (not
in that order).

PS - I don't mean to harp on this.  I'd hoped to have someone send me
links to other documents because I want to learn more about the names in
".onion" and other identifiers in Tor.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 7 Aug 2015 15:58:32 +0000

Thanks.  That is indeed what I'm working on.  And yes, that description is
clear and helpful and "deprecates" (in my mind) the notion that the names
were too long for the DNS.

(Just wish it was that clear in a Tor document. ;) ...said for the purposes
of the last call.)

On 8/7/15, 11:38, "Chris Baker" <[email-masked]> wrote:

>>  why the names are different from DNS domain names.
> 
> I think this is where Andrew's distinction between "the DNS" and a larger
> concept of name space is needed. Onion names are different in that they are
> names for a different resolution process which uses a distributed hash table
> operated by the Tor network nodes instead of the root DNS servers. My
> apologies if this seems over simplistic.
> 
> CBaker

---

From: Alec Muffett <[email-masked]>
Date: Sat, 8 Aug 2015 10:44:56 +0000

> On Aug 7, 2015, at 4:26 PM, Edward Lewis <[email-masked]> wrote:

> … the documents I have access to do not give me a deep enough sense

To address Edward’s implicit request for information - rather than to address his request for document pointers - I’d like to share that I sketched how onion addressing works in previous discussion at:

https://www.ietf.org/mail-archive/web/dnsop/current/msg13758.html <https://www.ietf.org/mail-archive/web/dnsop/current/msg13758.html>

…and am happy to answer questions to the best of my ability, or punt in the right direction.

Onion addresses may in future be >64 characters long, perhaps even >80, when new code rolls; the principles are likely invariant, however.

    -a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Chris Baker <[email-masked]>
Date: Fri, 7 Aug 2015 11:38:52 -0400

I think this is where Andrew's distinction between "the DNS" and a larger
concept of name space is needed. Onion names are different in that they are
names for a different resolution process which uses a distributed hash
table operated by the Tor network nodes instead of the root DNS servers. My
apologies if this seems over simplistic.

CBaker

---

From: Jacob Appelbaum <[email-masked]>
Date: Fri, 7 Aug 2015 16:20:15 +0000

> That's the site I've been using.

What do you specifically wish that it had? Doesn't the git repository
provide you with specific versioned hashes for any given document?

> doesn't give me enough background.

This is clearly documented in the specifications - including the
lookup process and how the .onion names are constructed.

I'm really confused as to how your question of "why the names are
different from DNS domain names" isn't answered by Tor's rend-spec?
Should we make an explicit reference to Zooko's triangle or something?
o_0

> but if there were other means to refer to the document in a reference

Do you mean to suggest that https://spec.torproject.org/rend-spec
isn't enough? Wouldn't
https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt?id=69f0faec555d3c7d627aa1de73dafee8f8d63f84
be specific enough?

> That is, full title, RFC document identity, date and authors/editors (not

The git repo shows authorship down to the line number as well.
Documents not specifically authored by named persons or teams are
authored by the individuals in the git commit and/or the Tor Project
inc., I believe.

> ".onion" and other identifiers in Tor.

Please see:

  https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt?id=69f0faec555d3c7d627aa1de73dafee8f8d63f84

As well as:

  https://gitweb.torproject.org/torspec.git/tree/proposals/155-four-hidden-service-improvements.txt?id=69f0faec555d3c7d627aa1de73dafee8f8d63f84
  https://gitweb.torproject.org/torspec.git/tree/path-spec.txt?id=69f0faec555d3c7d627aa1de73dafee8f8d63f84#n36
  https://gitweb.torproject.org/torspec.git/tree/address-spec.txt?id=69f0faec555d3c7d627aa1de73dafee8f8d63f84#n48

And more generally:

  https://gitweb.torproject.org/torspec.git/tree/glossary.txt?id=69f0faec555d3c7d627aa1de73dafee8f8d63f84
  https://gitweb.torproject.org/torspec.git/tree/proposals?id=69f0faec555d3c7d627aa1de73dafee8f8d63f84

Specific implementations are probably also useful. Tor's C
implementation and Orchid (Java Tor implementation) are probably easy
enough to study.

Happy to answer other questions as well...

All the best,
Jacob

---

From: Ted Hardie <[email-masked]>
Date: Mon, 10 Aug 2015 09:50:54 -0700

Hi Alec,
​
You wrote:

> ​To address Edward’s implicit request for information - rather than to
> address his request for document pointers - I’d like to share that I
> sketched how onion addressing works in previous discussion at:
>
> https://www.ietf.org/mail-archive/web/dnsop/current/msg13758.html
>
> Onion addresses may in future be >64 characters long, perhaps even >80,
> when new code rolls; the principles are likely invariant, however.
>
>
>
​
Thanks for the pointer and for the additional information on the address
name length. Reading through the highlights  two issues that have been
raised in the past with the description of the special use names registry.
The first is the continuing problem distinguishing between names in the DNS
(e.g. the .onion "TLD") and names in some larger namespace which is not
limited to the DNS.  The second is the likelihood that names that are not
in DNS may eventually cease to be parsed well by software which naively
expects them to match the DNS world.

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.

regards,

Ted

---

From: Alec Muffett <[email-masked]>
Date: Mon, 10 Aug 2015 18:04:25 +0000

On Aug 10, 2015, at 9:50 AM, Ted Hardie <[email-masked]> 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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 10 Aug 2015 11:42:33 -0700

Hi Alec,

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

> 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.   ​

> 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:
>
> 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

---

From: Alec Muffett <[email-masked]>
Date: Mon, 10 Aug 2015 19:25:23 +0000

Hi again, Ted!

> On Aug 10, 2015, at 11:42 AM, Ted Hardie <[email-masked]> wrote:
> […]
> ​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.

I would agree, in fact I feel this was strongly thrashed-out in discussion of the draft.

> 
>>> A scan of section 3.2.2 of RFC3986 “Uniform Resource Identifier (URI): Generic Syntax”
>>> […]
>>> 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.
> 

> ​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 <https://urldefense.proofpoint.com/v1/url?u=http://tools.ietf.org/html/rfc6068%23page-3&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0A&m=oCCVXQHML7Wu9tLutu8gi0yjQy%2FYshsl6QPZDObXbt0%3D%0A&s=169bbca645c89ea6cb6b8e1f492f00233288a5afea42e886b71051a7e31cdb61> 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://urldefense.proofpoint.com/v1/url?u=https://tools.ietf.org/html/rfc7595&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0A&m=oCCVXQHML7Wu9tLutu8gi0yjQy%2FYshsl6QPZDObXbt0%3D%0A&s=2902ce28be4aa8782a28349946b7aeba381329ac17f118c226111a2f7de618d1> has some additional detail in the context of registrations.

Some Googling suggests that the http:// scheme is defined in RFC 2616, which - to summarise - again does not mandate DNS.

- Section 3.2.2 defines the host-name part in abstract regards TCP connections:
>identified resource is located at the server listening for TCP connections on that port of that host
- Section 3.2.3 discusses string comparisons

- Section 15.3 discusses DNS spoofing and DNS caching, which is inapplicable

- Sections 5.2 and 14.23 discuss the Host header, the latter most specifically:
The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL.
…again without reference to DNS.  Since the use of an Onion in a Host header would reflect the origin, I think this works.

So, by this analysis I think Onions in http (and by extension https) are fine.

Not to mention, appropriate. :-)

> 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.

Exactly.  I believe that they do.

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

Where else would you suggest looking, please?

    -a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: "Joe Hildebrand" <[email-masked]>
Date: Mon, 10 Aug 2015 14:25:19 -0600

> Not to mention, appropriate. :-)

If the smiley means "they're already deployed, so we don't get to talk 
about whether they're appropriate", then fine, but that's why a bunch of 
people are complaining about the precedent this sets.

If the smiley means "this is a good protocol design that other people 
should follow", then I'm not sure we have consensus on that.

-- 
Joe Hildebrand

---

From: Alec Muffett <[email-masked]>
Date: Mon, 10 Aug 2015 21:24:52 +0000

> On Aug 10, 2015, at 1:25 PM, Joe Hildebrand <[email-masked]> wrote:
> 
> If the smiley means "they're already deployed, so we don't get to talk about whether they're appropriate", then fine, but that's why a bunch of people are complaining about the precedent this sets. If the smiley means "this is a good protocol design that other people should follow", then I'm not sure we have consensus on that.

I apologise that my personal opinion and cheery demeanour appears to be extrapolatable into a couple of contrasting strategic positional statements.

To put my personal opinion at greater and more clear length:

In the context of URI schemes, accessing a Tor onion site (currently) over HTTP or HTTPS is precisely *that* - a fetch of HTML or other content which a HTTP or HTTPS request might typically be used to access - without the client software needing to be adapted for Tor access at "Layer 7".

Such a fetch is functionally just a vanilla HTTP/S over an “alternate" transport, the latter generally enabled by a SOCKS proxy or a content-aware VPN.

Such fetches currently work, have done so for several years, and have been used by many, many thousands of users, possibly millions.

Similarly, ssh://[email-masked] <ssh://[email-masked]> is equally an extant and functional SSH request to someonionaddress.onion

Equally git://someonionaddress.onion/user/project-name.git <git://someonionaddress.onion/user/project-name.git> would not immediately strike me as needing to be forcibly changed to “onion-git://“ <onion-git://%E2%80%9C> simply because Git is invoked over an "alternate” transport with a “alternate” name resolution. It currently works, so why break it?

From this observation, my personal opinion of “the proper scheme for an HTTP/S fetch to an Onion address" is something of a duck-test:

TEST: if a fetch looks like HTTP/S and quacks like HTTP/S, then I think that it should likely be given a HTTP/S scheme.

Conversely: it’s arguable that schemes like “daap” or “rtsp” are also “HTTP-based”, and that *they* have special schemes, so perhaps fetches from Onion-addresses should “have special schemes” too?

I can sympathise with this argument.  It makes logical sense.

I personally differentiate and resolve this argument in terms of intent, and in terms of client and server-software.

“rtsp://” for instance is used for streaming, and requires magic, RTSP-specific headers, and the frontend is something like VLC or iTunes, and the backend requires a special streaming stack.

To me, this smells of specialism.

Equally: if iTunes incorporates a webview and fetches a bunch of web-content for human consumption, it likely uses a HTTP/S scheme to do so, rather than a specialist “ituneshttps://“ scheme.

This smells of specialist software trying to be a "general-purpose browser".

So, given these conditions:

- if the intent is largely to provide HTML+CSS content to human beings,
- if the client software is most likely a well-known browser (tor browser = firefox) operating in its normal mode
- …but not necessarily or exclusively a browser…
- and if the server software is something like Apache + {Wordpress, Drupal, a bunch of static HTML}

…then under these conditions, again, I apply the duck test. I feel that such fetches are HTTP/S and should have that scheme.

Hence why I feel that the extant, vanilla HTTP/S schemes are most appropriate for fetching browser content from onion addresses.

The other matters, regarding domain name resolution and generic URI syntax, I have already covered at some length.

   - a

*aside: using VLC to RTSP to an Onion address will work just fine when SOCKS (etc) is configured… etc...

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Aug 2015 07:53:10 +0800

Kevin,

On 11 Aug 2015, at 6:54 am, Darcy Kevin (FCA) <[email-masked]> wrote:
> 
> In retrospect, the definition of the “http” and “https” schemes (i.e. RFC 7230) should have probably enumerated clearly which name registries were acceptable for those schemes, so that the following language from RFC 7320 (a BCP) could be invoked against any attempt by an app – Onion or anyone else -- to inject their own unique brand of “specialness” into the interpretation of the Authority component of their URIs:
>  
> Scheme definitions define the presence, format and semantics of an
> authority component in URIs; all other specifications MUST NOT
> constrain, or define the structure or the semantics for URI
> authorities, unless they update the scheme registration itself.
>  
> 7230 casually mentions DNS and “network host table” as name registries that can potentially be used for “http” and/or “https”, but never implies that those 2 constitute the only members of the set.
>  
> If both injecting “specialness” into the URI, and updating the “https” scheme itself, were viewed as unavailable or unappealing options, then Onion – and anyone else who follows the same path – would be left with no other choice but to define their own scheme.

I think that would be a bad outcome indeed. 

Viewing this as "injecting specialness" into the URI is counter to the clear examples that Alec just gave of non-HTTP-based (and, indeed, non-URI-based) uses of .onion. So, I can't imagine what end such restrictions would serve, except as a (fairly artificial) way to frustrate the registration of .onion.

I'd also point out that such an approach might place procedural barriers in place of getting .onion or something similar recognised, it would not significantly hinder its deployment — as evidenced by .onion itself.

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Alec Muffett <[email-masked]>
Date: Tue, 11 Aug 2015 00:21:39 +0000

Kevin,

> On Aug 10, 2015, at 3:54 PM, Darcy Kevin (FCA) <[email-masked]> wrote:
> 
> In retrospect, the definition of the “http” and “https” schemes (i.e. RFC 7230) should have probably enumerated clearly which name registries were acceptable for those schemes, so that the following language from RFC 7320 (a BCP) could be invoked against any attempt by an app – Onion or anyone else -- to inject their own unique brand of “specialness” into the interpretation of the Authority component of their URIs

To echo Mark’s rebuttal of this statement, I would like to ask what benefit would be served by doing so, please?

Thanks,

    - alec

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 11 Aug 2015 01:21:42 -0400

> Some Googling suggests that the http:// scheme is defined in RFC 2616, which - to summarise - again does not mandate DNS.

I'm by no means an expert on the scheme, but I think following the
references means that 2616 does in fact inherit certain DNS
limitations, because RFC 2616 refers normatively to RFC 2396, which
says this:

host          = hostname | IPv4address
hostname      = *( domainlabel "." ) toplabel [ "." ]
[…]
   Hostnames take the form described in Section 3 of [RFC1034] and
   Section 2.1 of [RFC1123]: a sequence of domain labels separated by
   ".", each domain label starting and ending with an alphanumeric
   character and possibly also containing "-" characters.  The rightmost
   domain label of a fully qualified domain name will never start with a
   digit, thus syntactically distinguishing domain names from IPv4
   addresses, and may be followed by a single "." if it is necessary to
   distinguish between the complete domain name and any local domain.

That gets us right back to the limitations in 1034 and 1123, alas.
RFC 3986, which obsoletes 2396, makes this only marginally better
because it seems to use the presence of dots as a hint that the DNS is
what's in use (though it does not in fact mandate that and suggests
that the rules are OS dependent).  It moreover says "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."  That's hardly encouraging.

I don't know how any implementation actually works in this respect,
but the "does not mandate DNS", while strictly true, doesn't make the
argument work quite as well as one wants.  Experience suggests that
expectations of the old-fashioned Preferred Syntax from STD13 is all
over the place.  Presumably, that's why people keep picking things
that sure look like domain names as identifiers; but we don't get to
have the advantages without all the built-in costs.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Mon, 10 Aug 2015 22:54:35 +0000

- Kevin

From: DNSOP [mailto:[email-masked]] On Behalf Of Alec Muffett
Sent: Monday, August 10, 2015 5:25 PM
To: Joe Hildebrand
Cc: Edward Lewis; Ted Hardie; [email-masked]; Richard Barnes; [email-masked]; Mark Nottingham
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

On Aug 10, 2015, at 1:25 PM, Joe Hildebrand <[email-masked]<mailto:[email-masked]>> wrote:

Similarly, ssh://[email-masked] is equally an extant and functional SSH request to someonionaddress.onion

Equally git://someonionaddress.onion/user/project-name.git would not immediately strike me as needing to be forcibly changed to “onion-git://“<onion-git://%E2%80%9C> simply because Git is invoked over an "alternate” transport with a “alternate” name resolution. It currently works, so why break it?

   - a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Aug 2015 11:45:49 -0400

>>>>> "Darcy" == Darcy Kevin (FCA) <[email-masked]> writes:

    Darcy>    In retrospect, the definition of the
    Darcy> €œhttp€� and
    Darcy> €œhttps€� schemes (i.e.  RFC 7230) should
    Darcy> have probably enumerated clearly which name registries were
    Darcy> acceptable for those schemes, so that the following language
    Darcy> from RFC 7320 (a BCP) could be invoked against any attempt by
    Darcy> an app €“ Onion or anyone else -- to inject their
    Darcy> own unique brand of €œspecialness€� into
    Darcy> the interpretation of the Authority component of their URIs:

I think all of this discussion ignores the realities of how host
software works.  Onion is not injected at the browser.  It's handled at
a layer that deals with connecting to names, not connecting to URIs.
Actually being responsive to these practical concerns in how people
build real-world systems is supposed to be an important part of the
IETF.  I find this ongoing discussion frustrating because people are
ignoring the impact of their thoughts on the systems we actually have
before us.  There have been many nice theoretical models presented.
However we have not chosen to specify APIs in the spaces under
discussion, and the APIs that are specified do not map well onto these
models.  The approach that the TOR Project has chosen does map well onto
the real-world systems.

---

From: Peter Koch <[email-masked]>
Date: Tue, 11 Aug 2015 23:17:33 +0200

On Tue, Jul 14, 2015 at 12:24:38PM -0700, The IESG wrote:
> 
> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document:
> - 'The .onion Special-Use Domain Name'
>   <draft-ietf-dnsop-onion-tld-00.txt> as Proposed Standard

I object to the publication of the above draft as Proposed Standard.
The intended registration is incompatible with the registration policy
laid out in RFC 6761 and is likely to create a false sense of security.

RFC 6761 requires a "Standards Action" or "IESG Approval" as per RFC 5226.

RFC 5226 states (page 11)

            IESG Approval is not intended to be used often or as a
            "common case"; indeed, it has seldom been used in practice
            during the period RFC 2434 was in effect.  Rather, it is
            intended to be available in conjunction with other policies
            as a fall-back mechanism in the case where one of the other
            allowable approval mechanisms cannot be employed in a timely
            fashion or for some other compelling reason.  IESG Approval
            is not intended to circumvent the public review processes
            implied by other policies that could have been employed for
            a particular assignment.  IESG Approval would be
            appropriate, however, in cases where expediency is desired
            and there is strong consensus for making the assignment
            (e.g., WG consensus).

It is unclear what path is suggested by the IESG since the draft, other than
RFC 6762 for the "local." TLD, does not contain a protocol specification.
It does not even contain a normative reference to such protocol specification.
An "Applicability Statement" might be possible, but details ought to have been
specified in the Last Call.

It is my reading that any protocol eligible for a registration in the "Special
Names" registry has to be an IETF Standards Track protocol - the grandfathered
entries in that very registry nonwithstanding.  Any deliberations w.r.t. the
Tor protocol are missing from the above draft and the Last Call message.

The response to question 2 (of 7) says

   2.  Application Software: Applications (including proxies) that
       implement the Tor protocol MUST recognize .onion names as special
       by either accessing them directly, or using a proxy (e.g., SOCKS
       [RFC1928]) to do so.  Applications that do not implement the Tor
       protocol SHOULD generate an error upon the use of .onion, and
       SHOULD NOT perform a DNS lookup.

RFC 6762 says

      2. Application software may use these names as they would other
         similar DNS names, and is not required to recognize the names
         and treat them specially.  Due to the relative ease of spoofing
         dot-local names, end-to-end cryptographic security remains
         important when communicating across a local network, just as it
         is when communicating across the global Internet.

The "Special Names" registry does not offer any means to convey any particular
behaviour, let alone differences between various reserved names.  It is more
than brave to expect that non-supporting implementations would be able (or
willing) to follow the SHOULDs in the first quoted block.

The response to question 3 (of 7) reads

   3.  Name Resolution APIs and Libraries: Resolvers MUST either either
       respond to requests for .onion names by resolving them according
       to [tor-rendezvous] or by responding with NXDOMAIN.

The first half of the "MUST" refers to an informative reference of unknown status
without any explanation for a "downref".

Response 4 reads

   4.  Caching DNS Servers: Caching servers SHOULD NOT attempt to look
       up records for .onion names.  They MUST generate NXDOMAIN for all
       such queries.

It remains to be specified how these "generated" responses would interact
with DNSSEC validation.  Again, it is unclear how agnostic (as of today)
recursive resolvers would learn about the new name and apply specific behaviour to it.

Response 5

   5.  Authoritative DNS Servers: Authoritative servers MUST respond to
       queries for .onion with NXDOMAIN.

does not specify what zone the targetted "Authoritative DNS Servers" are
supposed to be authoritative for.  Root name servers will respond NXDOMAIN
as long as onion. will not have been delegated and other servers would
usually respond with REFUSED.  This is probably no different from normal
DNS modus operandi and thus would not need a particular description.

The draft does not explain why it asks for a "special name" at the top level.
Neither the draft nor the Last Call document or envision any coordination
with the responsible body as per the MoU RFC 2860.

I am sorry to say that while the protocol inquestion has all my sympathy,
the request put forward fails to meet the registration criteria.  However,
it identifies several points in RFC 6761 that would benefit from clarification,
first and foremost the role of the "seven responses", their (retroactive) applicability
to otherwise agnostic implementations and the communication of details towards
potentially cooperating implementations.

-Peter

---

From: Alec Muffett <[email-masked]>
Date: Tue, 11 Aug 2015 22:59:38 +0000

Hi Peter,

> laid out in RFC 6761 and is likely to create a false sense of security.

To deal with the latter, first:

The intended registration is not, and nowhere intends, to create any sense of security at all, let alone a false one.

The intended registration is meant as an enabler for the existing and ongoing population of onion space, and to enable the broad adoption of SSL certificates within that space.

It would be a broad and implausible assertion that SSL Certificates and HTTPS does not provide security for users of Web (and other) protocols, but to argue that the registration of “.onion” as a special use domain name would be equal to making the argument that the existence of “.com” as a registered TLD somehow engenders a false sense of security.

This latter point is arguable, I suppose, but the false sense of security engendered there would reside in DNS and not in the fact of registration.  :-)

> RFC 6762 for the "local." TLD, does not contain a protocol specification.

The Tor protocol is controlled by Tor, and is apt to change; there is enough description there to explain how onion addresses are mechanically generated, but to tie the registration RFC to a specific implementation/version seemed unwise.

> Tor protocol are missing from the above draft and the Last Call message.

We are not seeking to register the protocol.  We are seeking to register a namespace that the protocol uses.

The advice received from IANA last night as part of the last call, suggests this:

>> However, one reviewer added the following:
>> 
>> "My comment would be there is nothing in the IANA considerations regarding how IANA manages the root zone, although immediately prior it says:
>> 
>> "'DNS Registries/Registrars: Registrars MUST NOT register .onion names; all such requests MUST be denied.'
>> 
>> "I believe 'register' in this context is not sufficiently clear. Perhaps 'delegate' is intended? For example, normally for a reserved name IANA would keep a record in the root zone database to acknowledge this, but this could appear to prohibit keeping a record for this purpose. Further, my understanding is part of the reason for this whole I-D is to all SSL certificate vendors (which are often DNS registries/registrars) to allow registration of SSL certificates for .onion names. I would say a plain reading of this may prohibit that. I would suggest there be an explicit additional category that makes it clear it expects service providers, such as trust providers, for to support .onion domains in such applications."

…so this suggestion - which myself and Jacob Appelbaum (the authors) warmly wish to adopt - would lead to “.onion” being reserved and not delegated, but also clearly documented as a space in which SSL certificates are to be issued.  I think that would aid the goals we’ve sought to describe in the draft.

> recursive resolvers would learn about the new name and apply specific behaviour to it.

I think the IANA proposition would mean that DNSSEC would cease to be an issue, but perhaps you would like to suggest some alternative wording for us to consider?

> with the responsible body as per the MoU RFC 2860.

I believe that that was dealt with extensively in DNSOP.  Mark?

    -a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Ted Hardie <[email-masked]>
Date: Tue, 11 Aug 2015 17:17:27 -0700

On Tue, Aug 11, 2015 at 3:59 PM, Alec Muffett <[email-masked]> wrote:

> The Tor protocol is controlled by Tor, and is apt to change; there is
> enough description there to explain how onion addresses are mechanically
> generated, but to tie the registration RFC to a specific
> implementation/version seemed unwise.
>
>
​Actually, the point was made up-thread that if names below .onion change
in their length, it is not clear how well software which is expecting a
more usual DNS-style authority section for http URLs (or mailto URLs etc.)
will work.    So while I agree that linking the registration to a
particular version creates a problem, the ability to evaluate the
registration goes down when it is not.

> namespace that the protocol uses.
​So, RFC 6761 says this:

    Similarly, if a domain name has special properties that affect the
   way hardware and software implementations handle the name, that apply
   universally regardless of what network the implementation may be
   connected to, then that domain name may be a candidate for having the
   IETF declare it to be a Special-Use Domain Name and specify what
   special treatment implementations should give to that name.

​

​It is abundantly clear that software implementations handling .onion
addresses should behave differently from those handling standard DNS
registrations.  But it is not currently within the IETF's ability to
specify the special treatment in this case.  Note that I don't mean here
specify "how TOR itself works", but to specify how this works when these
names appear inside other contexts.

Imagine for a moment that I run a service that delivers mail via TOR. While
RFC 5321 does not contemplate .onion addresses, it does note that MX
records may be resolvable with either v4 or v6.  What would actually break
if someone put a .onion address in the MX record of a domain?  What would
break if a later version onion address ceased to follow DNS syntax for
labels below .onion itself?  The answer to question 1 and question 2 may be
very, very different.

As I said in a previous thread, I think the IETF didn't do a good job in
setting up this registry, and I think we're actually talking about two very
different things.  One is "special use DNS names" and the other is "names
in other namespaces than the DNS".  I think the first one we have our hands
around.  There's a huge potential range in that second category, but the
more a namespace outside of the DNS tries to share contexts with the DNS
(like URL contexts), the messier it is going to get.  Honestly, I worry
folks will assume from seeing a namespace in one DNS-like context that it
can go into others, and that it will break more than that namespace.

Holding up the registration of .onion does not help that, of course, but I
hope it helps you understand why we are looking for more detail than "this
external pointer to a changeable specification should be enough."

regards,

Ted Hardie
/no hats

> "My comment would be there is nothing in the IANA considerations regarding
> how IANA manages the root zone, although immediately prior it says:
>
> "I believe 'register' in this context is not sufficiently clear. Perhaps
> 'delegate' is intended? For example, normally for a reserved name IANA
> would keep a record in the root zone database to acknowledge this, but this
> could appear to prohibit keeping a record for this purpose. Further, my
> understanding is part of the reason for this whole I-D is to all SSL
> certificate vendors (which are often DNS registries/registrars) to allow
> registration of SSL certificates for .onion names. I would say a plain
> reading of this may prohibit that. I would suggest there be an explicit
> additional category that makes it clear it expects service providers, such
> as trust providers, for to support .onion domains in such applications."
>
>
>
> …so this suggestion - which myself and Jacob Appelbaum (the authors)
> warmly wish to adopt - would lead to “.onion” being reserved and not
> delegated, but also clearly documented as a space in which SSL certificates
> are to be issued.  I think that would aid the goals we’ve sought to
> describe in the draft.
>
>
> I think the IANA proposition would mean that DNSSEC would cease to be an
> issue, but perhaps you would like to suggest some alternative wording for
> us to consider?
>
>

---

From: Alec Muffett <[email-masked]>
Date: Wed, 12 Aug 2015 03:22:07 +0000

Hi Ted,

> On Aug 11, 2015, at 5:17 PM, Ted Hardie <[email-masked]> wrote:
> ​Actually, the point was made up-thread that if names below .onion change in their length, it is not clear how well software which is expecting a more usual DNS-style authority section for http URLs (or mailto URLs etc.) will work.

I can see the concern - for instance there is Mailpile, a MUA which implements an extension called “SMTorP” - shortcutting SMTP delivery using an end-to-end Onion connection between the MUAs of two people once it is established that both of them are running Mailpile.

I am not sure whether SMTorP is intended to make the Onion addresses “directly” available for mailto: URIs, but I want to note:

* Onion addresses at the moment are 16+”.onion” characters long, and derived URIs are of a legitimate DNS syntax by any measure
* There is plenty of speculation about how unspecified software may deal with them if/when they get longer
* The URI standard seems (as I wrote upstream) to be strict in capping the length of a URI at 255 chars
* ...and reads inconsistently regards the assumption of DNS as a name resolution service and whether that should be enforced.

Given the “special” - as in “special name” - nature of Tor, it seems likely that all intentional use of it will be "opt-in" by via software that is capable of dealing with its addressing scheme and any URIs associated with it.

Equally, any software not capable of dealing it, which stumbles across a “long” label or somesuch, should treat it as much as it should properly treat (ignore?) any URI which it is incapable of dealing with. e.g.: the fact that I insert a link such as the following in this e-mail, should not crash your browser:

http://a234567890123456789012345678901234567890123456789012345678901234567890.onion/hello <http://a234567890123456789012345678901234567890123456789012345678901234567890.onion/hello>.txt

If you are still reading this e-mail, your browser or mailer survived that illegally-long-yet-parsable label.

Software is pretty good at ignoring what it cannot deal with nowadays.

> ​ ​It is abundantly clear that software implementations handling .onion addresses should behave differently from those handling standard DNS registrations.  But it is not currently within the IETF's ability to specify the special treatment in this case.  Note that I don't mean here specify "how TOR itself works", but to specify how this works when these names appear inside other contexts.

So, for my clarity, your concern is one of these two contexts:

(a) the bigger non-tor-enabled universe and how it behaves when encountering a perhaps-longer-than-expected label as part of the “Host” element of a URI?

Or perhaps...

(b) How the tor-enabled universe with its non-IETF-defined features will make use of IETF URI schemes (eg: mailto:) and yet one day may start using them in non-standard ways/creating non-standard URIs?

> Imagine for a moment that I run a service that delivers mail via TOR. While RFC 5321 does not contemplate .onion addresses, it does note that MX records may be resolvable with either v4 or v6.  What would actually break if someone put a .onion address in the MX record of a domain?

Well, strictly, I feel that if one can insert an MX record for a “special use” domain which IANA will not delegate (see earlier thread regarding IANA feedback for this draft) then perhaps there is a bigger issue at hand, viz: the ability to insert long junk records of any kind into an MX record - which would not be an issue caused by this draft.

To answer your question literally, I believe the answer would be someone receiving SMTP code 553 “You are attempting to send email to a domain that is not recognized by this server”.

> What would break if a later version onion address ceased to follow DNS syntax for labels below .onion itself?

That’s a good question that seems to assume (lack of) good faith of the Tor community to want to interoperate with the internet as a whole; given the actual challenge at hand - which I can sketch as “the tor onion community are trying to use the HTTP/S schemes in URIs” - it seems pretty plausible that transparent interoperability is actually their goal, though of course I can’t speak for all Tor users everywhere.

Some of them may want to innovate, perhaps (in wild, nostalgic, hypothetical speculation) we will see a renaissance of UUCP bangpaths over some Onion-aware e-mailer; wouldn’t that be exciting and innovative?

But I wouldn’t want to pre-emptively squelch such an innovation for fear of how Outlook would cope if and when it encountered something like:

mailto:…!mcsun!ukc!aber!aem (this was one of my e-mail addresses in 1991)

…because Outlook would not be the target audience for such a feature.

I believe that one of the underlying principles of HTML is that “if you don’t understand something, ignore it”, and this behaviour (ignoring this bangpath scheme) seems okay to me. Or punting it.  Whichever.

> The answer to question 1 and question 2 may be very, very different.
> 
> As I said in a previous thread, I think the IETF didn't do a good job in setting up this registry, and I think we're actually talking about two very different things.  One is "special use DNS names" and the other is "names in other namespaces than the DNS".  I think the first one we have our hands around.  There's a huge potential range in that second category, but the more a namespace outside of the DNS tries to share contexts with the DNS (like URL contexts), the messier it is going to get.  Honestly, I worry folks will assume from seeing a namespace in one DNS-like context that it can go into others, and that it will break more than that namespace.

To me this provides all the more reason, in this popular, million-plus user special case, to put it on a proper footing as a special name, adopt IANA’s suggestion of not delegating it but annotating its special nature clearly so that CA/B-Forum will bless SSL certificates for it, and through awareness learn how to find a middle ground that is acceptable to all.

I am sympathetic. I have lived in a world of dual namespaces.  Another of my old e-mail addresses was:

[email-masked]

For those who don’t recall, the UK academic network was once X.25 not TCP/IP, and had an addressing scheme which ran right to left; and it was a good day when the UK JANET network finally dumped bigendianism and all hostnames (for good or ill) ran from left to right.

BUT: again, to reiterate:

1) Onion address spaces are currently utterly DNS “compliant”, except for having a currently unofficial rightmost label.

...and...

2) All forward-looking statements about them are speculation, but practically the most likely thing to happen to them is that they will get longer.

Regarding label length, I find it really interesting to note that the Tor draft discussion document for future onion addresses / hidden services cites examples thusly:

https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt <https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt>
>    And a new name following this specification might look like:
> 
>         a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion

…where the longest label is *53* characters long, still well within the bounds of DNS legality (63) and yet leaving 10 characters grace for padding hyphens, or something.

But for some reason we are still arguing about future speculation and what “might” happen.

Honestly, I wonder why *that* is?

> Holding up the registration of .onion does not help that, of course, but I hope it helps you understand why we are looking for more detail than "this external pointer to a changeable specification should be enough.”

Concern for standardisation is important and good; so is general adherence to standards, especially in spirit.

I hope that neither is ever constructed by IETF in order to proactively brake innovation or change, especially where good faith is evident.

    - alec (mailto:[email-masked] <mailto:[email-masked]> - in 1991)

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Ted Hardie <[email-masked]>
Date: Wed, 12 Aug 2015 07:57:43 -0700

On Tue, Aug 11, 2015 at 8:22 PM, Alec Muffett <[email-masked]> wrote:

>
> Given the “special” - as in “special name” - nature of Tor, it seems
> likely that all intentional use of it will be "opt-in" by via software that
> is capable of dealing with its addressing scheme and any URIs associated
> with it.
>
>
​This is where we have an apparently philosophical ​difference, and, where,
I think the failure of the registry document is most evident.  I believe
that the category of software that will have to deal with this special use
name is much broader than the opt-in Tor software, and I think that's
what's contemplated in the paragraph I quoted above ("that apply
universally regardless of what network the implementation may be connected
to").  If Tor operated in a vacuum, it would not need this registration; it
does not, and does.

> Equally, any software not capable of dealing it, which stumbles across a
> “long” label or somesuch, should treat it as much as it should properly
> treat (ignore?) any URI which it is incapable of dealing with. e.g.: the
> fact that I insert a link such as the following in this e-mail, should not
> crash your browser:
>
>
> http://a234567890123456789012345678901234567890123456789012345678901234567890.onion/hello
> .txt
>
It did, but truncated what it thought was a URI, so ​it represents a
failure.

> ​Where the coding effort has seen this species of failure before,
generally yes.  Novel failures require work to resolve.​

> (a) the bigger non-tor-enabled universe and how it behaves when
> encountering a perhaps-longer-than-expected label as part of the “Host”
> element of a URI?
>
> Or perhaps...
>
> (b) How the tor-enabled universe with its non-IETF-defined features will
> make use of IETF URI schemes (eg: mailto:) and yet one day may start
> using them in non-standard ways/creating non-standard URIs?
>
>
​B is closer, but "What constraints on the operation of Internet protocols
and systems arise from the need to have protocol identifiers from these two
different systems interoperate when the switch for distinguishing among
them is embedded in the identifier?".  Using a pseudo-tld to indicate
namespace operation was not contemplated for a lot of the deployed systems
and protocols. Bits of it will work and bits of it will not when presented
with them.  You may not care about the bits that will not, but
interoperability is the IETF's core concern, and that includes things
leaking from local namespaces into the global ones.  I'm sure the DNSOP
folks have made the impact of those on their part of the universe
abundantly clear, but it may extend far beyond that.

>
> Imagine for a moment that I run a service that delivers mail via TOR.
> While RFC 5321 does not contemplate .onion addresses, it does note that MX
> if someone put a .onion address in the MX record of a domain?
>
>
> Well, strictly, I feel that if one can insert an MX record for a “special
> use” domain which IANA will not delegate (see earlier thread regarding IANA
> feedback for this draft) then perhaps there is a bigger issue at hand, viz:
> the ability to insert long junk records of any kind into an MX record -
> which would not be an issue caused by this draft.
>
> ​Someone seeing a mailto: with .onion might well assume that this was a
reasonable thing to do, where there is no known incentive to insert junk
now, so I believe your response misses the point.​

> To answer your question literally, I believe the answer would be someone
> receiving SMTP code 553 “You are attempting to send email to a domain that
> is not recognized by this server”.
>
> ​The error seems more likely to me to be a resolution error/

What would break if a later version onion address ceased to follow DNS
> syntax for labels below .onion itself?
>
> That’s a good question that seems to assume (lack of) good faith of the
> Tor community to want to interoperate with the internet as a whole; given
> the actual challenge at hand - which I can sketch as “the tor onion
> community are trying to use the HTTP/S schemes in URIs” - it seems pretty
> plausible that transparent interoperability is actually their goal, though
> of course I can’t speak for all Tor users everywhere.
>
>
​Would the Tor community commit to making sure future onion identifiers
follow the DNS label length and IDN restrictions?  That would help​ a lot.

Some of them may want to innovate, perhaps (in wild, nostalgic,
> hypothetical speculation) we will see a renaissance of UUCP bangpaths over
> some Onion-aware e-mailer; wouldn’t that be exciting and innovative?
>
>
Building a DHT out of onion nodes and routing SIP across it with p2psip?
Sure, go to town.​

> But I wouldn’t want to pre-emptively squelch such an innovation for fear
> of how Outlook would cope if and when it encountered something like:
>
> I believe that one of the underlying principles of HTML is that “if you
> don’t understand something, ignore it”, and this behaviour (ignoring this
> bangpath scheme) seems okay to me. Or punting it.  Whichever.
>
>
> To me this provides all the more reason, in this popular, million-plus
> user special case, to put it on a proper footing as a special name, adopt
> IANA’s suggestion of not delegating it but annotating its special nature
> clearly so that CA/B-Forum will bless SSL certificates for it, and through
> awareness learn how to find a middle ground that is acceptable to all.
>
> For those who don’t recall, the UK academic network was once X.25 not
> TCP/IP, and had an addressing scheme which ran right to left; and it was a
> good day when the UK JANET network finally dumped bigendianism and all
> hostnames (for good or ill) ran from left to right.
>
> 1) Onion address spaces are currently utterly DNS “compliant”, except for
> having a currently unofficial rightmost label.
>
> ​I think you mean they follow the DNS label constraints, right?​

> ...and...
>
> 2) All forward-looking statements about them are speculation, but
> practically the most likely thing to happen to them is that they will get
> longer.
>
>
> Regarding label length, I find it really interesting to note that the Tor
> draft discussion document for future onion addresses / hidden services
> cites examples thusly:
>
>
>
> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt
>
> …where the longest label is *53* characters long, still well within the
> bounds of DNS legality (63) and yet leaving 10 characters grace for padding
> hyphens, or something.
>
> ​Because the registry assumed that the IETF had change control for special
use names that involved non-DNS​ resolutions.   Clearly it does not for
.onion, so we are working out what to do in real time, rather than simply
following a well trodden path.

> external pointer to a changeable specification should be enough.”
>
>
> I hope that neither is ever constructed by IETF in order to proactively
> brake innovation or change, especially where good faith is evident.
>
>
​Good faith don't grow Christmas trees, in the words of my grandfather.  My
frank assessment is that if the Tor community can commit in good faith to
follow the DNS constraints for its identifiers (don't step on IDN rules,
follow the length guidelines, etc.), the ​IETF should register .onion and
then immediately close the registry for repairs and refactoring.

But that's just my own opinion,

regards,

Ted

>     - alec (mailto:[email-masked] - in 1991)
>
> —
> Alec Muffett
> Security Infrastructure
> Facebook Engineering
> London
>
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 12 Aug 2015 10:04:40 -0700

> In retrospect, the definition of the “http” and “https” schemes (i.e. RFC 7230) should have probably enumerated clearly which name registries were acceptable for those schemes,

I generally try to avoid enumerating things that are known to be false. All URI schemes that use authority
intentionally refer to the local mechanism of name lookup, even if that name lookup only uses DNS as the last
in a long line of alternative registries.  The client is responsible for choosing a mechanism which produces
a correct mapping for any given authority, regardless of whether that is defined for them by /etc/host, WINS,
DNS, third-party https-based DNS lookup, etc. The folks referring to resources using those schemes are
responsible for making those references unambiguous, usually by naming convention rather than any
specific set of syntax rules.

....Roy

---

From: Alec Muffett <[email-masked]>
Date: Wed, 12 Aug 2015 17:09:04 +0000

Hi again, Ted!

> ​This is where we have an apparently philosophical ​difference, and, where, I think the failure of the registry document is most evident.  I believe that the category of software that will have to deal with this special use name is much broader than the opt-in Tor software, and I think that's what's contemplated in the paragraph I quoted above ("that apply universally regardless of what network the implementation may be connected to").  If Tor operated in a vacuum, it would not need this registration; it does not, and does.

Tor Onion Addressing does not operate in a vacuum - you are quite correct - it seeks to use properly TCP-like circuits, HTML, CMS, HTTP, and now HTTPS; the latter is perhaps the first technology where the technology has become (to some extent) hard-coded to the presumptions of Internet communication, in that SSL certificates are required, the authorities for those certificates have been issuing them against DNS names; but now, through CA/B-Forum’s Ballot 144:

https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/

…CA/B-Forum are permitting CAs to issue certificates against “.onion” addresses.  For this to continue requires a step-up to IETF that “.onion” be reserved as a global namespace, upon which DNS need not tread. This is an achievable situation.

In the spirit of “good fences make good neighbours”, one of the most important aspects of interoperability is one of boundaries, and registration of “.onion” in the way proposed will clearly define the boundaries between DNS and an extant network of users which is not dependent upon DNS and which will not go away, but might be worked with-and-around.

> It did, but truncated what it thought was a URI, so ​it represents a failure.

…and I will bet that if you had clicked on it, and if it hadn’t been “truncated”, you would next have an issue that you would not have received any data because you are not using Tor.  That would be because you were not using Tor software.

Under such circumstances that would be an acceptable failure, I think.

See the annotation cited in this blogpost for a similar example:

https://www.facebook.com/notes/protect-the-graph/making-connections-to-facebook-more-secure/1526085754298237

[…phiilosophical deletia…]

>> …where the longest label is *53* characters long, still well within the bounds of DNS legality (63) and yet leaving 10 characters grace for padding hyphens, or something. But for some reason we are still arguing about future speculation and what “might” happen.  Honestly, I wonder why *that* is?
>> 
> 
> ​Because the registry assumed that the IETF had change control for special use names that involved non-DNS​ resolutions.   Clearly it does not for .onion, so we are working out what to do in real time, rather than simply following a well trodden path.
[...]

> ​Good faith don't grow Christmas trees, in the words of my grandfather.  My frank assessment is that if the Tor community can commit in good faith to follow the DNS constraints for its identifiers (don't step on IDN rules, follow the length guidelines, etc.), the ​IETF should register .onion and then immediately close the registry for repairs and refactoring.
> 

Your grandfather spoke wise words.  Nick Mathewson is the engineer who leads Tor development on Onion services.  He writes thusly on this matter:

https://lists.torproject.org/pipermail/tor-dev/2015-August/009275.html

How will that fly with you?

    -a

---

From: Ted Hardie <[email-masked]>
Date: Wed, 12 Aug 2015 13:16:32 -0700

On Wed, Aug 12, 2015 at 10:09 AM, Alec Muffett <[email-masked]> wrote:

> Hi again, Ted!
>
> > ​Because the registry assumed that the IETF had change control for
> special use names that involved non-DNS​ resolutions.   Clearly it does not
> for .onion, so we are working out what to do in real time, rather than
> simply following a well trodden path.
> [...]
>
> > ​Good faith don't grow Christmas trees, in the words of my grandfather.
> My frank assessment is that if the Tor community can commit in good faith
> to follow the DNS constraints for its identifiers (don't step on IDN rules,
> Your grandfather spoke wise words.  Nick Mathewson is the engineer who
> leads Tor development on Onion services.  He writes thusly on this matter:
>

​If you're willing to put a statement like it in the draft, that works for
me; it would need to include a slightly broader commitment (not to step on
other syntax bits, like the IDNA prefix etc), but I think the broader
statement would go to exactly the same goal.

I'm sorry to read in the above link that you feel beaten up by this; I've
tried to be quite careful in noting that I think the fault here is in the
registry itself, not this registration.  There were some unanticipated
consequences to this that this registration brings to light; we now ​need
to deal with those.   That's all that's going on.

regards,

Ted

---

From: Alec Muffett <[email-masked]>
Date: Wed, 12 Aug 2015 20:49:03 +0000

> On Aug 12, 2015, at 1:16 PM, Ted Hardie <[email-masked]> wrote:

> ​If you're willing to put a statement like it in the draft, that works for me; it would need to include a slightly broader commitment (not to step on other syntax bits, like the IDNA prefix etc), but I think the broader statement would go to exactly the same goal.

Given that this is about Onion Registration rather than about Tor Project, some wording like

“Onion addresses are [blah description blah] and which are consistent with DNS syntax limitations of 63 character labels..."

…which I think would impose a constraint whilst being aimed at the supposedly correct target.

I’ll copy Nick on this to be doubly certain.

> I'm sorry to read in the above link that you feel beaten up by this; I've tried to be quite careful in noting that I think the fault here is in the registry itself, not this registration.  There were some unanticipated consequences to this that this registration brings to light; we now ​need to deal with those.   That's all that's going on.

Obliged.  From this end there is a clear and present deadline as described at:

https://www.ietf.org/mail-archive/web/dnsop/current/msg14065.html <https://www.ietf.org/mail-archive/web/dnsop/current/msg14065.html>

…and I hope that amendments sympathetic with resolving this issue can be made without requiring a complete "go-around" cycle.

Thanks!

    - alec

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Wed, 12 Aug 2015 19:00:44 +0000

True, different name-resolution methods could be defined at the Operating System level (I still remember writing code to work against NetInfo, for instance – how many people remember that?). RFC 3986 recognizes as much.

Perhaps it would have been sufficient for RFC 7230 to limit the acceptable name registries to those for which access is defined/enabled at the Operating System level. That’s a fairly limited, defined set. It’s when we allow *applications* to define their own name registries, that it becomes open-ended and “Authority” for any given URI then becomes *non-definitive*, which pretty much defeats its whole purpose.

(Yes, I realize that on some platforms, the distinction between application and OS can be somewhat blurry).

                                                                                                                                                                - Kevin

From: Roy T. Fielding [mailto:[email-masked]]
Sent: Wednesday, August 12, 2015 1:05 PM
To: Darcy Kevin (FCA)
Cc: Alec Muffett; Joe Hildebrand; Edward Lewis; Ted Hardie; [email-masked]; Richard Barnes; [email-masked]; Mark Nottingham
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

On Aug 10, 2015, at 3:54 PM, Darcy Kevin (FCA) <[email-masked]<mailto:[email-masked]>> wrote:

....Roy

---

From: Nick Mathewson <[email-masked]>
Date: Thu, 13 Aug 2015 10:17:04 -0400

On Wed, Aug 12, 2015 at 4:49 PM, Alec Muffett <[email-masked]> wrote:
> If you're willing to put a statement like it in the draft, that works for
> “Onion addresses are [blah description blah] and which are consistent with
> DNS syntax limitations of 63 character labels..."
>

I think that's (broadly) a good solution.

The important thing here AFAIU is not to nail down the exact semantics
of current .onion addresses or post-revision .onion addresses or
25-years-from-now .onion addresses... but rather to carve out enough
space for this and future revisions.

So it's IMO fine to say ".onion addresses are case-insensitive and
will comply with existing DNS limitations for label lengths (63) and
maximum fqdn lengths (253ish)".

But it it would be problematic to say something like ".onion addresses
are are exactly N characters long" or ".onion addresses have the
following structure" or ".onion addresses have exactly two labels" or
anything like that.  So let's avoid those.

cordially,
-- 
Nick

---

From: George Michaelson <[email-masked]>
Date: Thu, 13 Aug 2015 12:55:38 -0300

There is a corollary: If a future revision of .onion labels exceeds 63/256
boundary conditions, then it will change behaviour when presented in the
DNS. In the current situation, it will earn an NXDOMAIN and 'dtrt' in as
much as the return says 'this label is not in the DNS'

in future, if it exceeds the (1980s, we were all younger and wiser then)
proscribed field semantics for DNS, it will return FORMERR and other
replies which may tickle other behaviour than you (we?) expect.

I know I keep harping on about the DNS, and your main goal is to NOT BE in
the DNS. But we also realize the reality that these labels will be
presented to dns gethostbyname() and other packages (getDNS api?) -So the
s/w behaviours of systems have to be considered. A couple of postings in
the thread(s) of this discussion make it clear we all understand, the
labels are going to be seen in the DNS system/ecology, irrespective of if
we wish it or not.

I don't actually think any language has to change. You might just want to
document in TOR paperwork, that changes to the syntax of xxx.onion has to
be assessed against its behaviours in other name-lookup systems.

-G

PS

$ dig @8.8.8.8
123456789012345678901234567890123456789012345678901234567890123.x.dashnxdomain.net.
in a

; <<>> DiG 9.10.2-P3 <<>> @8.8.8.8
123456789012345678901234567890123456789012345678901234567890123.x.dashnxdomain.net.
in a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50749
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;
123456789012345678901234567890123456789012345678901234567890123.x.dashnxdomain.net.
IN A

;; AUTHORITY SECTION:
dashnxdomain.net. 0 IN SOA ns1.dashnxdomain.net. research.apnic.net.
2015072201 900 300 1 1

;; Query time: 496 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Aug 13 12:54:03 UYT 2015
;; MSG SIZE  rcvd: 166

$ dig @8.8.8.8
1234567890123456789012345678901234567890123456789012345678901234.x.dashnxdomain.net.
in a
dig: '
1234567890123456789012345678901234567890123456789012345678901234.x.dashnxdomain.net.'
is not a legal name (label too long)
$

On Thu, Aug 13, 2015 at 11:17 AM, Nick Mathewson <[email-masked]> wrote:

> > Given that this is about Onion Registration rather than about Tor
> Project,
> > some wording like
> >