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

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

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

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.

---

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

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

> _______________________________________________
> 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 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: Chris Baker <[email-masked]>
Date: Fri, 7 Aug 2015 11:38:52 -0400

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

> 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

---

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: Mark Andrews <[email-masked]>
Date: Sat, 08 Aug 2015 06:32:56 +1000

In message <[email-masked]>, David Cake
 writes:
>
> > On 16 Jul 2015, at 4:11 am, Francisco Obispo <[email-masked]>
> wrote:
> >
> >
> >> This was proposed in the working group.   It obviously doesn't work,
> >> first because TOR can't come up with that kind of money, but second
> >> because TOR doesn't want a TLD (hellekin's erroneous statements
> >> notwithstanding).   What they want is a special-use name.   A domain name
> >> does not accomplish the intended purpose, because it has to be resolved
> >> by sending a query to a DNS server.   A third objection was one Ed raised
> >> earlier for an unrelated reason: we can't assume that the TOR project
> >> will continue to exist as an entity that can own a delegation.   What
> >> happens when that stops?   Does the Church of Anatman get to buy the
> >> domain and start snooping on TOR connections?
> >>
> >
> > Well do they want a TLD but they don’t have the money? or don’t want a
> > TLD? perhaps the problem is in how the TLD program treats them, in which
> > case the answer should be on the ICANN side.
>
> 	The ICANN process is designed towards the goal of delegation, and
> has a great deal of steps in the process of application that make no
> sense at all if delegation is not the goal. Tor do not want delegation,
> and delegation is not appropriate for this intended use (the mitigation
> of privacy leakage that the Tor Project would be able to provide as
> delegated register is considerably less than that proposed in the draft).
> I do not think there is anything useful in demanding that ICANN create a
> slew of separate processes to roughly replicate Special Use Names that
> will never deliver what is wanted, when the Special Use names process
> already exists, and will.

Actually it needs a *insecure* delegation to a empty zone.  This allows
local recursive servers to generate NXDOMAIN responses *locally* rather
than having to recurse and leak the query name in the process further
still and to allow those responses to validate.

The alternative to that is to stop growing the root zone so that every
recursive server on the planet can successfully load it. 

> >> A fourth objection which I don't think was raised is that this doesn't
> >> work for .local or any of the other special-use names, and if it doesn't
> >> work for them, it doesn't make sense to try to make it work specifically
> >> for .onion.   Why is .onion special?   Should Apple or Microsoft be asked
> >> to pay $200k to reserve the .local TLD?
> >
> > Having this mechanism for reserving special use names, creates two
> > different authorities managing the same namespace, this will require
> > tight coordination as well as clear and transparent guidelines to make it
> > work.
>
> 	In this case, there seems to be no reason why we can’t manage the
> necessary coordination by having people participating in both spaces, and
> there have been several involved, in that several people involved in
> DNSOP discussion are also active in ICANN processes. After this case, it
> may be worth considering how the process can be improved - we still have
> several other potential special use names to consider.
>
> 	David

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

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: 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: hellekin <[email-masked]>
Date: Mon, 10 Aug 2015 15:21:27 -0300

On 08/10/2015 01:50 PM, Ted Hardie wrote:
> ​
> It does a fine job with .example since that's fundamentally

Hi Ted,

I fully agree with Alec, and do not understand how .onion would differ
from .example in that case, especially since as we're speaking, onion
names are fully compatible with DNS domain names, syntactically
speaking. Can you elaborate on the difference you see, and why should we
need to think forward to a non-existing set of future registries where
onion names could end up at some point if at all?

Regards,

==
hk

---

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: "John Levine" <[email-masked]>
Date: 10 Aug 2015 19:10:30 -0000

>> I believe that the registry we have currently defined doesn't do a great job of capturing the actual needs here. 

Agreed.  It seems to me that there are two somewhat separate things going on here.

One is the .ONION issue.  It's a domain name string that has a
coordinated use that is implemented outside the RFC 1034/1035 DNS.

The other is the .BELKIN and .CORP issue.  They're domain name strings
that have no coordinated use, but there's enough uncoordinated use
that there'd be a stability risk if a live TLD started answering
queries.

In both cases, one question is when we reserve the name, and the other equally
important question is when we un-reserve the name.

For all three, I think there's adequate evidence to reserve them now.
The un-reserve criteria is different, and I expect would be different
for any other name we reserved.  For .onion, it's not out of the
question that five or ten years from now we check in with the ToR
project and they say oh, the whole reserved name thing was such a hassle
that we switched to onion:// names and we don't use domain names at all.

For .BELKIN, the problem was a lot of home routers shipped a decade
ago.  Eventually most of them will die and the problem will go away.
Or if the Belkin company wanted a vanity domain, they presumably know
what the routers did and could come up with a TLD that avoided sending
unfortunate responses to the old queries.

For .CORP, I gather the main usage was for intranet TLS certificates,
but the public CAs have stopped signing them so they will probably
mostly go away, too.

The point of these examples is not that we need to solve any of those
issues now, but that a useful reserved name registry needs to deal with
the reality that most reservations need not be forever.

R's,
John

---

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: Steve Crocker <[email-masked]>
Date: Mon, 10 Aug 2015 15:26:29 -0400

Five years is not enough.  Think in terms of 20 to 50 years.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Aug 2015 05:27:09 +1000

> unfortunate responses to the old queries.

If .BELKIN is reserved then it is not available to *anyone* including
Belkin.  The simplist fix for .BELKIN is for the vendor to request
registration of the name through ICANN.  It becomes a expensive
mea-culpa.  The IETF should leave this to ICANN processes.

---

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: "John R Levine" <[email-masked]>
Date: 10 Aug 2015 17:21:55 -0400

> Five years is not enough.  Think in terms of 20 to 50 years.

Oh, of course.  I was thinking of five years as the review cycle for 
names that people might want to reconsider.

> mea-culpa.  The IETF should leave this to ICANN processes.

It occurs to me that a lot of this would be less painful if the ICANN new 
TLD process were clearer about dealing with collisions with informal use. 
AGB section 2.2.1.3 is about the DNS stability review, but it says "There 
is a very low probability that extended analysis will be necessary for a 
string that fully complies with the string requirements in subsection 
2.2.1.3.2 of this module." where those requirements basically say it has 
to be a valid ASCII or IDN DNS label.

For .BELKIN, the answer would depend on the details of the application, 
which is unlike any other new TLD string review I can think of.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

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

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.

                                                                                                                                                                - 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: Mark Nottingham <[email-masked]>
Date: Tue, 11 Aug 2015 07:53:10 +0800

Kevin,

> 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 – wou…

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

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: "Roy T. Fielding" <[email-masked]>
Date: Wed, 12 Aug 2015 10:04:40 -0700

....Roy