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

From: The IESG <[email-masked]>
Date: Tue, 14 Jul 2015 12:24:38 -0700

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2015-08-11. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

This document uses the Special-Use Domain Names registry to register the
'.onion' Top Level Domain (TLD) for the Tor Network. This is deemed necessary  
for hosts on the ToR network to apply for and receive legitimate SSL Certificates. 

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 14 Jul 2015 13:16:41 -0700

> for hosts on the ToR network to apply for and receive legitimate SSL
​Speaking as an individual only​, I do not believe that this request is
well-formed.  In May of 2000, the IAB of the time issued RFC 2826, which
provided a technical commentary on the value of the unique DNS root.  Among
its statements is this:

   The DNS fulfills an essential role within the Internet protocol
   environment, allowing network locations to be referred to using a
   label other than a protocol address.

​I believe that .onion is, essentially, a way for structuring protocol
addresses so that they appear to be DNS names.  It does not conform to the
delegation model of the DNS, and it requires special knowledge on the part
of the handler to understand it.  The authors of the document propose to
register it in the DNS under the rubric of RFC 6761, which says:

   If it is determined that special handling of a name is required in
   order to implement some desired new functionality, then an IETF
   "Standards Action" or "IESG Approval" specification [RFC5226
<https://tools.ietf.org/html/rfc5226>] MUST be
   published describing the new functionality.

   The specification MUST state how implementations determine that the
   special handling is required for any given name.  This is typically
   done by stating that any fully qualified domain name ending in a
   certain suffix (i.e., falling within a specified parent pseudo-
   domain) will receive the special behaviour.  In effect, this carves
   off a sub-tree of the DNS namespace in which the modified name
   treatment rules apply, analogous to how IP multicast [RFC1112
<https://tools.ietf.org/html/rfc1112>] or IP
   link-local addresses [RFC3927
<https://tools.ietf.org/html/rfc3927>] [RFC4862
<https://tools.ietf.org/html/rfc4862>] carve off chunks of the IP
   address space in which their respective modified address treatment
   rules apply.

​I do not believe this document is sufficient to describe the new
functionality​; the primary description is actually in an informational
reference, [Dingledine2004].
<https://www.onion-router.net/Publications/tor-design.pdf>This does not
appear, at least to me, to meet the requirements set out in the
registration document.

Further, I believe this stretches the "special handling" requirement of RFC
6761 to the breaking point.  This does not describe special handling
_within the DNS_, but instead removes a portion of the global namespace
from the DNS at all.  To me, at least, this does not seem to me to meet the
analogy RFC 6761 provides to IP multicast ranges or local addresses.
Whether it is permitted or not by RFC 6761, it is a bad idea.

​My opinion only,

Ted Hardie​

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 14 Jul 2015 22:50:20 +0200

On Tue, Jul 14, 2015 at 01:16:41PM -0700,
 Ted Hardie <[email-masked]> wrote 
 a message of 206 lines which said:

> ​I believe that .onion is, essentially, a way for structuring
> protocol addresses so that they appear to be DNS names.  It does not
> conform to the delegation model of the DNS,

It does not have to conform since .onion is a domain name, not a DNS
name. The whole point of this "registration" is to avoid leaks in the
DNS (section 2 of the draft).

> This does not describe special handling _within the DNS_, but
> instead removes a portion of the global namespace from the DNS at
> all.

Same thing for RFC 6762 (which was the first applictaion of RFC 6761,
and nobody objected about it).

---

From: David Conrad <[email-masked]>
Date: Tue, 14 Jul 2015 19:37:01 -0700

> The whole point of this "registration" is to avoid leaks in the

The listing of a string in the special names registry will, of course, not by itself cause leaks to be avoided. It may provide a facility for leaks to be avoided in the future.

> and nobody objected about it).

To put it bluntly, from a certain perspective, 6762 and dnsop-onion are essentially about the same thing: they are formalizing squatting on namespace (by Apple in the first instance and by TOR in the second). As such, I'm not sure 6762 is a good precedent to rely on.

I try to be pragmatic. Given I do not believe that refusing to put ONION in the special names registry will stop the use of .ONION, the size of the installed base of TOR implementations, and the implications of the use of that string in certificates, I supporting moving ONION to the special names registry.  I really (really) wish there was more concrete, objective metrics (e.g., size of installed base or some such), but my gut feeling is that TOR is pretty well deployed and given the CAB Forum stuff, I see no particular reason to delay (after all, it's not like the deployed base of TOR is likely to get smaller).

Regards,
-drc

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 15 Jul 2015 08:58:38 +0200

On 14 Jul 2015, at 22:16, Ted Hardie wrote:

> Further, I believe this stretches the "special handling" requirement of RFC 6761 to the breaking point.  This does not describe special handling _within the DNS_, but instead removes a portion of the global namespace from the DNS at all.  To me, at least, this does not seem to me to meet the analogy RFC 6761 provides to IP multicast ranges or local addresses.   Whether it is permitted or not by RFC 6761, it is a bad idea.

Speaking personally I think the intention of RFC6761 was to allow any kind of splitting of the namespace used by for example the global DNS so that there would not be any confusion and/or questions on how to resolve a specific string. See other similar specifications regarding .EXAMPLE, .LOCAL and such. And I think this is exactly the kind of need that exists for .ONION. The reference (normative or informative) is something I agree can be discussed whether it should not have been normative.

If the wording in RFC6761 is such that we do not agree that this is the process, but instead that RFC6761 is only for specifications that use the DNS for resolution, then I think RFC6761 should be made more clear, and not this document.

RFC6761 should be about namespace management, which I think is what we discuss here.

Because of this, I think this RFC should be published modulo resolution of the question about the reference.

> ​My opinion only,

Likewise ;-)

   Patrik

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Jul 2015 12:42:23 +0000

>  <draft-ietf-dnsop-onion-tld-00.txt> as Proposed Standard

Having read the document plus Ted Hardie's and David Conrad's (who happens
to be my boss in real life) comments, I see the documentation as
insufficient.

As David says, .onion-names use is independent (to some extent) on whether
"onion" is registered in the Special Use Domain Names registry.  What I am
writing here isn't a statement about whether "onion" is to registered, but
about the document applying for registration.

The document defines the use of the name by referring to a couple of
references, none of which appears to be published in a way that can be
referenced except by URL.  Not to say that the documents seen are poorly
written, still there's no evidence of peer review nor stable reference
point.  (One reference is a well prepared PDF, loaded on Jan 23, 2013 with
many other documents to a website that itself has this blurb at the
bottom: "Historical page reflecting onion-router.net as of 2005, not
regularly maintained. Address questions to...")  This is not a critique of
the content of the PDF, just the ability to rely on it for a decision.

The document also shows no evidence of the deployment of the use of the
names below "onion."  In David's email, and in others, there are comments
regarding an "installed base".  I've only seen any discussion about an
installed base in email, this is not in the documents.  In (say) 50 years,
what matters is what is in the published RFC, not the mailing lists.
Presence in the documents being put forward is important.

(E.g., has anyone consulted the annual DNS-OARC DITL data to measure how
often "onion" names are seen at root servers during that collection?)

Drilling into the criteria that are presented.  Not all of them.

1. Users.  The draft states "human users are expected to recognize .onion
names as..."  How are users supposed to recognize them as (special)?  In
as much as the document says nothing about evidence of deployment and
adoption, how can an expectation be developed?  If I hadn't been reading
the thread on DNSOP, I wouldn't have thought "onion" was special - but I
live in a cave, so what I think isn't important.

4. Caching DNS Servers and
5. Authoritative DNS Servers

I really believe that for DNS elements, there should be no change.  By
intent, the onion names are not to be presented to the DNS by what's in
category 2 and 3 (Applications and Name Resolution API's respectively).  I
see placing any requirement on DNS elements - and by that I mean the
software used to implement the DNS standard - as a bad idea, under the
heading of "permanent fix to a temporary situation."  (I.e., Tor may not
be permanent, if it is, as software matures onion names will not be in DNS
queries.)

6. DNS Operators

Having had experience with that field, I don't see this being a reliable
"rule."  In general, when a customer loads a zone into a system, there's
no way to check whether they have the "right" to use the name.  This is
more an issue I have with RFC 6761 and in general how the documents are
used in operations than a comment on the "onion" application.
Nevertheless, I wouldn't rely rule on operators, given that anyone can set
up a name server (the code is free and privileged user accounts are easy
on laptops), to be an effective means to enforce name restrictions.

7. DNS Registrars/Registries

This is the place where a case should be made for the registering "onion"
as a Special Use Domain Name.  Given the story to date, that "onion" is
not to be in the DNS, then don't change the protocol (5,6 above) but then
set up barriers to putting it in the DNS (7 here).  If you do that, then
Name Resolution libraries (3 above) will return "name error" or NXDOMAIN
to all queries in the onion domain of names.  I see this as where
registry policy documents can "point" (by reference) to a list of names
that are specially reserved or restricted.

I'm agreeing with Ted in that this application is insufficient.  I'm
agreeing with David in that designating "onion" in such a way as to fix
the "CAB Forum" stuff is acceptable.  My concern is that, if this
application proceeds as documented, the precedent being set could be
regrettable.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 15 Jul 2015 16:21:44 +0200

On Tue, Jul 14, 2015 at 07:37:01PM -0700,
 David Conrad <[email-masked]> wrote 
 a message of 60 lines which said:

> I really (really) wish there was more concrete, objective metrics
> (e.g., size of installed base or some such),

Most of the current RFC6761 requests are for projects devoted to
privacy, which, by construction, make statistics difficult :-}

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 15 Jul 2015 16:32:38 +0200

On Wed, Jul 15, 2015 at 12:42:23PM +0000,
 Edward Lewis <[email-masked]> wrote 
 a message of 202 lines which said:

> references, none of which appears to be published in a way that can
> be referenced except by URL.

First, RFC 6761 is silent about the characteristics of the
documentation to include in such a draft. RFC 6761 is very specific
about "in each of the seven categories below, what special treatment,
if any, is to be applied" but never mandated a specific type of
external references.

Second, I much prefer an URL (a few seconds after, I have the document
and I can read it) to... (incoming troll) a DOI or other kind of
reference that I may or may not be able to dereference.

---

From: Bob Harold <[email-masked]>
Date: Wed, 15 Jul 2015 10:53:41 -0400

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ballot/
(Speaking for myself)

I support this document.  This seems to be one of the cases that the
special use registry should be used for.

I would note that the SSL cert is incorrect for the
https://www.onion-router.net/Publications/tor-design.pdf link, so it would
be good if either the cert or the URL could be corrected.  (Cert is for the
name torproject.org and *.torproject.org)

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Jul 2015 14:56:53 +0000

>if any, is to be applied" but never mandated a specific type of

Never said that the draft did not fulfill the requirements of RFC 6761.  I
opined that it contained little information enabling an informed opinion.

An aside to all this (not meant to derail the application of "onion"),
when a process is as loosely defined as what is in RFC 6761, decisions
made according to it will build up a set of precedents that following
applications will be judged by.  One could argue that RFC 6761 is too
loose in specification or one can accept that it lays an open process
which will be defined by cases later on.  For the latter, merely meeting
the requirements of the process-setting document is not enough.

>reference that I may or may not be able to dereference.

To give a data point, the ATMA resource record type was originally defined
by a document resting on the ATM Forum site.  That was absorbed by
SomeOther Forum and then again by YetAnother Forum.  I had been tracking
the documentation of RR types since the days of DNSSEC's development and
thus was aware of the document's movement.  Eventually I made a request to
have the document "escrowed" (if that's the right term) with IANA so we
didn't lose it altogether - even if for historical purposes.

If we are going to rely on prior cases to build RFC 6761's process, we
need to be able to find the historical record.  URL's don't ensure that.

---

From: hellekin <[email-masked]>
Date: Wed, 15 Jul 2015 12:02:00 -0300

On 07/14/2015 11:37 PM, David Conrad wrote:
> 
> To put it bluntly, from a certain perspective, 6762 and
> dnsop-onion are essentially about the same thing: they are
> formalizing squatting on namespace (by Apple in the first
> instance and by TOR in the second).
>

This is blunt in more than one aspect. That you consider squatting as a
negative is insulting for those people who actually need to rely on
squatting not to be excluded from society.

But the argument that this is about, correct my paraphrase if I'm wrong,
"taking over by force part of the namespace" is in my opinion misguided.

The Domain Name System is *one way* of managing *a* global namespace.
That it is the canonical way of naming things chosen for the Internet
does not exclude that it's only one only way. Special-Use Domain Names
exemplify this point, and particularly P2PNames such as .onion
demonstrate the viability of other techniques than the hierarchical tree
of DNS to manage global namespaces.

The objective of this registration is convergent with the idea that the
DNS is the canonical global namespace of the Internet. Indeed .onion can
do without caring about the DNS, but this is not the point. The point is
to recognize the variety of techniques within the scope of DNS so that
future implementations can rely on the DNS as a correct source for
global information about namespaces.

I regret not to have mentioned this before, and hope that it frames the
problematic beyond territorial claims, operational issues, and security
issues.

==
hk

---

From: hellekin <[email-masked]>
Date: Wed, 15 Jul 2015 12:38:55 -0300

On 07/15/2015 09:42 AM, Edward Lewis wrote:
> referenced except by URL.
>

I agree that the URL could be use more foresight, e.g.
https://torproject.org/spec/protocol,
https://torproject.org/spec/naming, etc. I already suggested this form
to the Tor people without response. That said, an URL is the right thing
to do, as long as it does not change. Once the URL makes it to an RFC,
it is the responsibility of the domain operators to keep it running.
When the Tor specifications are updated to RFC status, then the .onion
tld RFC can be updated as well to point to the new references.

> live in a cave, so what I think isn't important.

The original P2PNames draft use:

"Users can use these names as they would other domain names, entering
them anywhere that they would otherwise enter a conventional DNS domain
name.

Since there is no central authority necessary or possible for assigning
.onion names, and those names correspond to cryptographic keys, users
need to be aware that they do not belong to regular DNS, but are still
global in their scope."

> 5. Authoritative DNS Servers
*** Well, isn't it the point of this draft that "as software matures
onion names will not be in DNS queries"?  These points are to minimize
the consequences on privacy when misconfigured systems leak queries, and
to minimize the number of bogus requests hitting the DNS tree.

> 6. DNS Operators
*** Again, this is not about enforcing, but about establishing best
practice. People can rely on RFC documentation and conscientious
operators will apply what's written there.

> 
> My concern is that, if this application proceeds as documented,
> the precedent being set could be regrettable.
> 
*** Are you suggesting then that only 7. is kept?

In any case I recommend reading the original proposal for .onion in the
P2PNames draft 04 for an alternate view. Maybe some of the questions
there can be useful here.

https://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-04
#section-4.3.1

==
hk

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Wed, 15 Jul 2015 15:52:32 +0000

Or to re-quote Paul Vixie:

what the internet should be doing is defining escape mechanisms for
non-internet systems, rather than saying "we are the only thing you can
use"

RPC 6761 is that mechanism for DNS.

/Hugo
________________________________________
From: DNSOP [[email-masked]] on behalf of hellekin [[email-masked]]
Sent: Wednesday, 15 July 2015 17:02
To: [email-masked]
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

==
hk

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jul 2015 10:16:06 -0700

> about the document applying for registration.

No, it's not independent, because .onion sites won't be able to get PKI 
certs if we don't do the allocation.
> point.
We discussed this at length in the working group, in which I believe you 
participate.   It is clearly understood that TOR is effectively an SDO 
that has defined a standard using their own system of publication and 
their own standardization methodology, which is different than the 
IETF's methodology for very good reasons. Requiring another SDO to 
follow IETF process in order to get an allocation of this type doesn't 
make sense and isn't required by the governing standard.

> regarding an "installed base".
Are you claiming that there is not widespread deployment of TOR? There 
was no controversy in the working group on this question: nobody there 
claimed that TOR wasn't sufficiently widely deployed to justify allocation.
> be permanent, if it is, as software matures onion names will not be in DNS

I think this is a reasonable position to take, with one exception. I 
think it's fine for the document to make recommendations about what name 
servers and the root should do, but it's not our place to make 
requirements, nor do I think it's necessary.   However, it would be very 
beneficial for host implementations to special case .onion, as some 
hosts do for .local now.   When hosts fail to apply appropriate special 
case handling for .local, it creates operational annoyances, to no 
benefit.   In the case of .onion, it creates a privacy problem.   So I 
don't mind this text as much as you do, but I do wonder if we'll 
actually see widespread implementation of such requirements.
> I'm agreeing with Ted in that this application is insufficient.

Whoa there, cowboy!   I didn't say it was insufficient.   I proposed 
changes to the text that I think would result in it better expressing 
what I think was intended.

And also, please don't call it an application.   It is an internet 
draft, which has passed working group last call, and is in IETF last 
call.   An application would be something that would be handled by the 
IESG, through the instrumentality of the IANA.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jul 2015 10:24:10 -0700

> squatting not to be excluded from society.
To expand on this ever so slightly, the reason why things like this 
happen is because the process for approving special-use allocations is 
perceived as too heavyweight, so people don't bother to do it in 
anticipation of an experiment.   Later, when the experiment proves a 
success, it's too late, and that is characterized as squatting, when in 
fact nobody had any intention of doing anything wrong, but were just 
following the path of least resistance.

If we want to avoid future instances of squatting, it behooves us to 
avoid applying too much process friction onto documents of this type.   
Granted, it's hard to tell how much is too much, but this particular 
discussion was kicked off in November of 2013, and here it is July of 
2015, and we are still talking about it.   That's a pretty heavy process.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Jul 2015 19:47:49 +0200

On Wed, Jul 15, 2015 at 5:52 PM, Hugo Maxwell Connery <[email-masked]> wrote:
> RFC 6761 is that mechanism for DNS.

Nice summary.

I have read this document, and sent comments on earlier drafts.  I
think the current version clearly expresses the requirements on DNS
actors to make .onion labels safe to use in DNS-like slots (e.g.,
URLs).  Especially given that there are a good number of sites already
using URLs with .onion names, and the PKI requirement for the status
of these names to be clarified, I strongly support the publication of
this document.

--Richard

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQJ8BAEBCgBmBQJVpnXeXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
> ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9r5QP/i6bE5b7u5M4JrIN+98GS8HS
> SG0wcDwVX13SWZujJ92ZFGy7lHDfG9wQr8WO/AoAlWT0vMzyfixMpWJZ66gxxthA
> F0fdZtI4N4nfjwolpQUnBnY/39yW1sumYg50AsS5dmX026F+wkjqidIV2s5PiZQr
> D4GC+6XvvYMvsYmLKwv8JeK1+wqkRw9nl2YSX6Wt/U0EwaI/VpIgjYkaT0VIFjw+
> c5OBkRfdaY4pFZ/NMfjiIvcYQp7MQhFPjvpsRMFtvtwpn+ZiJKoB4e3dOPCeL1S2
> dANLyutiodFTMGYGWn9W6Zcfv9SckSOiblH5qvNpkMcAumQe09fTQGxNX14OQXWr
> g6qV8oeNc2k1DsmPHM9UsDYSJmEy4zikGKLCcjpOC3Y4h+6aqyvBsby43dJfr7Fy
> tajr8nh1IcA8VZtM/K5+rqMZabg0EPIPujkchdrJTZ8+jiT0uT8pEDR4VammAcOz
> 9sMufzxdv30yYDYuFpTeTAf27z8h1232yhKOHaBaueDsZmva/IccHyHiw4ZQg/6Y
> NEoZ87UJa1lXWqJ7+XeyOfwJp1adPwXWb2IiNDIjXndXwt94yBPinAL/3E/2gnfw
> /XSKMTaeGBtixhllwidAtBSX7EeWTGQl7kWlH8MsvoLvpcZmuTTHpuWZ9k5VEcTe
> rn6UM1/Ooyjp2i90Gz7q
> =jn7Y
> -----END PGP SIGNATURE-----
>

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Jul 2015 18:04:02 +0000

On 7/15/15, 13:16, "DNSOP on behalf of Ted Lemon" <[email-masked]

>certs if we don't do the allocation.

That's what I meant by "(to some extent)".  If not being able to get the
certs kills Tor, then failing to get some special designation would be a
show stopper.  But that isn't in the document (and you'll see I keep
coming back to the document's content).

>We discussed this at length in the working group

The discussion in the WG is not reflected in the document.

>It is clearly understood that TOR is effectively an SDO

Until I read this, I wasn't aware that Tor (TOR?) was even an organized
thing.  I don't follow what you mean by requiring another "standards
development organization" to follow the IETF process.  I thought that for
Tor to get certificates from CA/B forum members there was a need to have
"onion" be a specially designated identifier and that the IETF's Special
Use Domain Names registry seems like an apt approach.

>claimed that TOR wasn't sufficiently widely deployed to justify

To answer your question, no.  I'm not making a claim about its deployment.
 OTOH, I have never seen any first hand evidence of it (I do live in a
cave perhaps).  None of my friends, family, etc., seem to know about and
so on.  But that doesn't matter - the document, as it stands, does not
give any indication that there is a widespread deployment of it.  I.e.,
I'm challenging the document preparers to include text that gives some
estimation of the scale of deployment.  Document it.

>actually see widespread implementation of such requirements.

I didn't see the exception you had in mind.  From what little I apparently
understand about Tor/onion, applications need to behave in a way that
enhances privacy and it would be cool if DNS servers weren't configured to
return conflicting data.  The DNS protocol doesn't need to be changed,
much like .local isn't special to a general purpose DNS server despite
behaving in a certain fashion in a host.

>>Ed: I'm agreeing with Ted in that this application is insufficient.
>
>Whoa there, cowboy!   I didn't say it was insufficient.

http://www.ietf.org/mail-archive/web/ietf/current/msg93849.html

That "Ted".

>IESG, through the instrumentality of the IANA.

Ted called it a "request."  (Just sayin'.)

Keep in mind - I'm saying the document, the internet-draft, doesn't
contain all that it could or should to be a convincing use case.  Perhaps
it ticked off all the check boxes of RFC 6761, but I think it lacks what
it needs to be convincing as well as stand the test of time.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jul 2015 11:12:17 -0700

> That "Ted".
Yup, Ted pointed that out to me privately--sorry.   :)
> it needs to be convincing as well as stand the test of time.
Argh.   I won't belabor the point, but the criteria established in 6761 
are criteria for the IETF to evaluate, not criteria that need to be 
documented in the specification.   The specification says what to do, 
and the working group considered that sufficient.   I do too.   Can you 
explain why it is beneficial for the document to try to make some 
statement about how widespread use of TOR is?   It's pretty easy for the 
working group to look at the situation and say "looks like enough."   
It's a lot harder to quantify it in a way that makes sense to put in an 
RFC, and I don't think it would be appropriate to do so.   I guess we 
could say "it is the consensus of the DNSOP working group that use of 
.onion is sufficiently widespread to justify publishing this document," 
but I think we are already saying that by requesting its publication.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Jul 2015 18:17:54 +0000

On 7/15/15, 11:38, "DNSOP on behalf of hellekin" <[email-masked]

>tld RFC can be updated as well to point to the new references.

".onion tld RFC" - minor point, but all along we are trying to avoid a TLD
for ".onion".

URLs are nice for giving a reference, but there's still a need to curate
the data.  In particular, what if the torproject.org name registration
expires and is bought by someone else?

>*** Are you suggesting then that only 7. is kept?

No, 2, 3 have roles as well as 7.  Not sure about 1.  But I really see
4,5,6 as not desirable.

>there can be useful here.

This is the last call for the doc in the subject line.  If text there
helps, it should be worked into the draft in the subject line.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jul 2015 11:21:18 -0700

> expires and is bought by someone else?
This is a problem whenever we reference a non-IETF specification. 
Actually, in principle it's even a problem when we reference an IETF 
specification, although of course we all no doubt hope the IETF will 
persist into the long now.

---

From: "John Levine" <[email-masked]>
Date: 15 Jul 2015 18:42:18 -0000

>avoid applying too much process friction onto documents of this type.   

Well, there's the problem.  Personally, I entirely agree with you, and
I would prefer we err on the side of caution to prevent collsions
between special use names and the DNS.

But there is also a faction that believes that every reserved name
will prevent them from making a million bajillion dollars.  History
suggests that they are mistaken, but that doesn't seem to help.

R's,
John

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Jul 2015 18:46:49 +0000

>but I think we are already saying that by requesting its publication.

(The annoying what if... question:)

What if I copied the onion draft, changed all of the uses of onion to
carrot, and then threw in some supporting documents to describe some other
system that used carrot as it's base identifier?  On the heels of onion's
admission to the Special Use Domain Names registry, could I expect to have
carrot admitted too?

I hope the answer is no, because the WG would likely not reach a consensus
on the document.  So, what I'm am asking is for the document to record why
onion is to be accorded this treatment.  WG consensus?  Document it!

(Aside from me thinking the draft's contents about name servers and
operators, criteria 4,5,6, is not a good approach.  E.g., my ISP's
recursive server does look for NS records where 6761 says it shouldn't,
but what they do works.)

---

From: David Conrad <[email-masked]>
Date: Wed, 15 Jul 2015 11:55:09 -0700

Hellekin,

> squatting not to be excluded from society.

I'm intrigued how you derived an insult from my statement that it was squatting.

> "taking over by force part of the namespace" is in my opinion misguided.

You're wrong.

I was noting that the strings were obtained outside of formal process. In my view, RFC 6761 was a post-facto effort to formalize that squatting. In the sense that post-facto probably isn't the best way of doing things, I suggested 6762 wasn't a particularly good precedent.

> Indeed .onion can

So, I'm now confused.

I thought the point of putting ONION in the Special Names Registry was to ensure that it did NOT rely on the DNS.

Regards,
-drc

---

From: hellekin <[email-masked]>
Date: Wed, 15 Jul 2015 16:21:17 -0300

On 07/15/2015 03:46 PM, Edward Lewis wrote:
> carrot, and then threw in some supporting documents to describe some
> other system that used carrot as it's base identifier?  On the heels
> of onion's admission to the Special Use Domain Names registry, could
> I expect to have carrot admitted too?
>

Do you have running code for carrot?

==
hk

---

From: Rubens Kuhl <[email-masked]>
Date: Wed, 15 Jul 2015 16:24:49 -0300

> Em 15/07/2015, à(s) 16:21:000, hellekin <[email-masked]> escreveu:
> 

The ToR source code, with all occurrences of onion replaced by carrot. 

Rubens

---

From: "Francisco Obispo" <[email-masked]>
Date: Wed, 15 Jul 2015 12:35:12 -0700

+1.

I don’t think IETF should be chasing around widely used TLDs and 
trying to block them, it will be a never ending chase.

We are trying to mitigate against unknowns and perhaps the best solution 
is to have the TOR folks apply for .ONION on the next round of TLD 
application and get a fully qualified delegation.

Basically saying: If you need a globally unique identifier in the DNS, 
you must register it with the competent entity. If noy, you run the risk 
of having your users leak their queries and possibly connect to the 
wrong service. This should make a better proposal for standard, 
basically reinforcing the one DNS one Internet message, and not the 
“Make sure you are leaking enough queries so that the IETF can then 
reserve the name for you”.

Who are we trying to protect with this remedy? TOR users? have they 
shown any interest in being protected?

—
Francisco Obispo
Uniregistry Inc.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jul 2015 12:50:31 -0700

> suggests that they are mistaken, but that doesn't seem to help.
That "faction" is aware that there are problems, and that not all names 
can be monetized in this way.   This discussion is orthogonal to that 
discussion: this particular name is already acknowledged not to be 
monetize-able.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jul 2015 12:53:57 -0700

> admission to the Special Use Domain Names registry, could I expect to have
1. Do you seriously think DNSOP would have had consensus to advance such 
a draft?
2. If DNSOP did have consensus to advance such a draft, what would your 
objection be?

I think that DNSOP would not advance such a draft unless a lot of 
reasonable people decided that they believed that .carrot was needed.   
And if DNSOP did indeed advance such a draft, I think that it would be 
the right thing to do to go to ICANN and say "what do you guys think 
about this?"   I don't think we would be in a position to make demands, 
but we should be able to have the conversation.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jul 2015 12:59:52 -0700

On 07/15/2015 12:35 PM, Francisco Obispo wrote:
> We are trying to mitigate against unknowns and perhaps the best 
> solution is to have the TOR folks apply for .ONION on the next round 
> of TLD application and get a fully qualified delegation. 
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?

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?

---

From: "Francisco Obispo" <[email-masked]>
Date: Wed, 15 Jul 2015 13:11:58 -0700

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

If they are using the string ‘onion’ as a TLD, within the global 
DNS, then they DO want a TLD, how they use it is similar to what 
corporates are doing with .BRANDs.

I don’t like setting things in stone forever, I agree with the 
assessment on “what happens if TOR ceases to exist”, but the answer 
can’t be, lets put it in an RFC where we run the risk of being black 
listed in code potentially forever. Quoting Paul Vixie on the 100-year 
cycle, in 100 years, we’ll have to wait 100 more years for it to be 
released, that will certainly create more potential problems.

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

If we are talking about private namespaces, they should be treated as 
such and we’ll have to come up with another way of dealing with name 
collisions.

—
Francisco Obispo
Uniregistry Inc.
On 15 Jul 2015, at 12:59, Ted Lemon wrote:

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jul 2015 13:59:07 -0700

On 07/15/2015 01:11 PM, Francisco Obispo wrote:
> 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 
As I said in the previous message, they do not want a TLD allocated by 
ICANN.   They want a special use name in the IETF RFC 6761 special-use 
name registry.

> released, that will certainly create more potential problems. 
Would you make the same point about .local?

> tight coordination as well as clear and transparent guidelines to make 
RFC 6761 already specified this.   The tight coordination of which you 
speak has occurred in this case, and will continue: the IESG is keenly 
aware of the situation, based on discussions that I was privy to and 
comments I've witnessed since I stopped being privy to such discussions.

---

From: "Francisco Obispo" <[email-masked]>
Date: Wed, 15 Jul 2015 14:22:58 -0700

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

They want an entry in a reserved-list in this, case. This is similar to 
when a registry adds ‘ICANN’ or ‘WPAD’ in the reserved list so 
that no-one can register it.

Perhaps we need a registry to manage this list… IANA perhaps? with a 
process on how to manage it that runs in coordination between IETF and 
ICANN.

>> assessment on “what happens if TOR ceases to exist”, but the 
>> answer can’t be, lets put it in an RFC where we run the risk of 
>> being black listed in code potentially forever. Quoting Paul Vixie on 
>> the 100-year cycle, in 100 years, we’ll have to wait 100 more years 
>> for it to be released, that will certainly create more potential 
>> problems.

Well, even worse, what happens if <name-your-next-OS-vendor> decides to 
create a new dns-like protocol that uses .foo, does that mean that we 
should automatically block it?

What if they decide to use .local, and then there isn’t 
interoperability with mDNS. These issues are solved by namespaces, but 
in order to make them work we need to have a registry for them, where 
corporations or individuals meet a certain criteria, they apply, and if 
granted, they get an entry that gives them right of use of a name.

IETF as far as I know is not a registry.

>> tight coordination as well as clear and transparent guidelines to 
>> make it work.

Thanks

—
Francisco Obispo
Uniregistry Inc.
On 15 Jul 2015, at 13:59, Ted Lemon wrote:

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jul 2015 14:32:08 -0700

> process on how to manage it that runs in coordination between IETF and 
We already have a registry, called the special-use domain names registry:

http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

> Well, even worse, what happens if <name-your-next-OS-vendor> decides 
> to create a new dns-like protocol that uses .foo, does that mean that 
> we should automatically block it? 

No.   We can add it to the special-use domain name registry if the IETF 
has consensus to do so, but there's nothing automatic about it, as 
Christian Grothoff can testify.

---

From: "Francisco Obispo" <[email-masked]>
Date: Wed, 15 Jul 2015 14:45:44 -0700

Ok, good!.

In this case all we need is something that does not encourage the 
creation of these names by not following published, transparent 
guidelines.

It doesn’t feel right to me rewarding bad behavior.

Thanks again.

>> Perhaps we need a registry to manage this list… IANA perhaps? with 
>> a process on how to manage it that runs in coordination between IETF 
>> and ICANN.
>
> No.   We can add it to the special-use domain name registry if the 
> IETF has consensus to do so, but there's nothing automatic about it, 
> as Christian Grothoff can testify.

—
Francisco Obispo
Uniregistry Inc.
On 15 Jul 2015, at 14:32, Ted Lemon wrote:

---

From: "Joe Hildebrand" <[email-masked]>
Date: Thu, 16 Jul 2015 01:44:14 +0300

On 15 Jul 2015, at 5:37, David Conrad wrote:

> I try to be pragmatic. Given I do not believe that refusing to put 
> ONION in the special names registry will stop the use of .ONION, the 
> size of the installed base of TOR implementations, and the 
> implications of the use of that string in certificates, I supporting 
> moving ONION to the special names registry.  I really (really) wish 
> there was more concrete, objective metrics (e.g., size of installed 
> base or some such), but my gut feeling is that TOR is pretty well 
> deployed and given the CAB Forum stuff, I see no particular reason to 
> delay (after all, it's not like the deployed base of TOR is likely to 
> get smaller).

I don't see any mention of the CAB Forum stuff in the draft.  Has anyone 
done the analysis to see if CAB Forum members really will issue certs to 
.onion addresses if we do this?  Do they issue certs for .example or 
.local today?

If certificate issuance is one of the key drivers for this work, there 
needs to be information in the draft that shows that this approach will 
work.

-- 
Joe Hildebrand

---

From: hellekin <[email-masked]>
Date: Thu, 16 Jul 2015 02:31:51 -0300

> I'm intrigued how you derived an insult from my statement

I guess that's the proximity of "blunt" and "squatting" that gave me
this impression.

> You're wrong.

I stand corrected.

> 
>> Indeed .onion can
>> do without caring about the DNS, but this is not the point. The point
>> is to recognize the variety of techniques within the scope of DNS so
>> that future implementations can rely on the DNS as a correct source
>> for global information about namespaces.
> 
> So, I'm now confused.
> 
> I thought the point of putting ONION in the Special Names Registry
> was to ensure that it did NOT rely on the DNS.
>

Sorry for being unclear. I meant: to recognize, within the scope of DNS,
a variety of alternate techniques (not using DNS but potentially
conflicting with it because from a user's perspective, there's hardly a
difference between this.example.sucks and facebookcorewwwi.onion)

Regards,

==
hk

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 16 Jul 2015 08:59:13 +0000

David Conrad wants metrics for Tor.

Unsurprisingly, they have them.  Our evil spam filter is stopping me
from sending a link, but go to:

https  metrics torproject org

There you find: number of relays and bridges, advertised bandwidth, and connected users, as graphs over time, and much more.

As of now approx 10 000 relays + bridges with 200 000 connected users.

/Hugo
________________________________________
From: DNSOP [[email-masked]] on behalf of David Conrad [[email-masked]]
Sent: Wednesday, 15 July 2015 04:37
To: Stephane Bortzmeyer
Cc: dnsop; IETF
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

[snip]

Regards,
-drc

---

From: Tom Ritter <[email-masked]>
Date: Thu, 16 Jul 2015 15:57:05 +0200

On 16 July 2015 at 00:44, Joe Hildebrand <[email-masked]> wrote:
> .onion addresses if we do this?  Do they issue certs for .example or .local
> today?

Not only will they issue certificates .onion, but they will not be
required to revoke the certificates they have _already_ issued, and
are using happily. I know Facebook and Blockchain, a few certs for
each, and maybe a third I'm forgetting. That will only go up over
time.

On the topics of metrics, indeed https://metrics.torproject.org/ is
the place.  You missed a zero though. It's 2 *million* directly
connecting users/day on average, not 200K.

On the topic of carrot, I would suggest .carrot.alt =)  I would also
ask about your user base.

On the topic of TLD vs Special Use: Yes I can confirm we want a
special use name, not a TLD.

On the topic of reliable resource,
https://gitweb.torproject.org/torspec.git/tree/ is a great URL, this
is where we standardize our specifications and update them. Our
process is different from the IETF, but there is one.  rend-spec.txt
in particular deals with .onion - but you would need to work with the
rest of the specs to get that far.  Barring operator accidents or some
absurd explosion in DNS price, I expect torproject.org will live 40+
years reliably. It may not be as future-reliable as iana.org or
ietf.org, but that URL, and/or "the torspec repository" is probably as
reasonably reliable as any other offsite link.

I support this draft.

-tom

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Jul 2015 08:20:10 -0700

> It doesn’t feel right to me rewarding bad behavior. 
I don't think it's fair to characterize this as "bad behavior."   It is 
completely unsurprising behaviour, as I explained in some detail in a 
previous message: 
http://www.ietf.org/mail-archive/web/dnsop/current/msg14924.html

---

From: Richard Barnes <[email-masked]>
Date: Thu, 16 Jul 2015 18:04:03 +0200

On Thu, Jul 16, 2015 at 12:44 AM, Joe Hildebrand <[email-masked]> wrote:
>> I try to be pragmatic. Given I do not believe that refusing to put ONION
>> in the special names registry will stop the use of .ONION, the size of the
>> installed base of TOR implementations, and the implications of the use of
>> that string in certificates, I supporting moving ONION to the special names
>> registry.  I really (really) wish there was more concrete, objective metrics
>> (e.g., size of installed base or some such), but my gut feeling is that TOR
>> is pretty well deployed and given the CAB Forum stuff, I see no particular
>> reason to delay (after all, it's not like the deployed base of TOR is likely
>> to get smaller).
>
>

There are at least a few CAs issuing for .onion right now, under the
exceptions that are going to expire in a few months.  So I assume that
these CAs will be interested in issuing if policy allows.

My understanding is that the basic requirement that CABF has is that a
name either be clearly a valid DNS name or clearly *not* a valid DNS
name.  (And in either case, that the applicant be able to demonstrate
control.)  Right now, that's ambiguous.  Adding .onion to the RFC 6761
registry would remove the ambiguity, since it would officially mark
names under .onion as not DNS names.

--Ricahrd

> If certificate issuance is one of the key drivers for this work, there needs
> to be information in the draft that shows that this approach will work.
>
> --
> Joe Hildebrand
>
>

---

From: Edward Lewis <[email-masked]>
Date: Thu, 16 Jul 2015 19:50:23 +0000

On 7/16/15, 9:57, "DNSOP on behalf of Tom Ritter" <[email-masked]
on behalf of [email-masked]> wrote:

>>.local
>are using happily....
>On the topics of metrics, indeed https://metrics.torproject.org/...

I'd be happy (happier) if that information appeared in the draft.

>On the topic of carrot...

I don't have any users.

---

From: David Conrad <[email-masked]>
Date: Fri, 17 Jul 2015 07:16:22 +0200

>> Well, even worse, what happens if <name-your-next-OS-vendor> decides to create a new dns-like protocol that uses .foo, does that mean that we should automatically block it?
> 
> No.   We can add it to the special-use domain name registry if the IETF has consensus to do so, but there's nothing automatic about it, as Christian Grothoff can testify.

Interesting choice: .FOO already exists. How is the IESG going to make a decision about whether to pre-empt Charleston Road Registry's use of that TLD in favor of <name-your-next-OS-vendor>'s use of that name?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Fri, 17 Jul 2015 07:35:47 +0200

Ted,

> To expand on this ever so slightly, the reason why things like this happen is because the process for approving special-use allocations is perceived as too heavyweight, so people don't bother to do it in anticipation of an experiment.

To be honest, I doubt this. It assumes folks who are developing these non-DNS protocols know/care about what the IETF thinks.

> If we want to avoid future instances of squatting, it behooves us to avoid applying too much process friction onto documents of this type.   Granted, it's hard to tell how much is too much, but this particular discussion was kicked off in November of 2013, and here it is July of 2015, and we are still talking about it.   That's a pretty heavy process.

I agree on the need for less friction, hence my interest in trying to find objective criteria. Lack of objective criteria pretty much guarantees the same sort of discussion and 'heavy process' you're complaining about.

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Thu, 16 Jul 2015 23:39:24 -0700

> Interesting choice: .FOO already exists. How is the IESG going to make a decision about whether to pre-empt Charleston Road Registry's use of that TLD in favor of <name-your-next-OS-vendor>'s use o…

we only need one cutout, something like .external, with an
IANA-maintained registry of non-dns uses, each pointing to an RFC that
describes as much as is possible to describe about that use.

-- 
Paul Vixie

---

From: David Conrad <[email-masked]>
Date: Fri, 17 Jul 2015 09:04:49 +0200

Paul,

> describes as much as is possible to describe about that use.

You mean like http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06?

Regards,
-drc

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 17 Jul 2015 09:17:27 +0200

From my high tech gadget

> On Jul 17, 2015, at 09:04, David Conrad <[email-masked]> wrote:
> 
> Paul,
> 

That was exactly the draft I was thinking about David.  But it does not address Paul's quest for one RFC per mapping, as .alt has no registry. 

I do think the path forward is one cutout (my opinion only) 

Tim

---

From: Paul Vixie <[email-masked]>
Date: Fri, 17 Jul 2015 00:51:05 -0700

> You mean like http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06?

yes, but not with .ALT, which is a politically desirable gTLD name, and
which allows the connotation of "alternate DNS". i suggested .EXTERNAL
because nobody will ever want it as a gTLD and because its connotation
is unambiguously "not DNS".

interestingly, in other namespaces, they use the local syntax equivilent
of ".INTERNET" to refer to names which have to be resolved in DNS.

seriously, i wouldn't object to warren's draft if the string he chose
hadn't been .ALT.

-- 
Paul Vixie

---

From: joel jaeggli <[email-masked]>
Date: Thu, 16 Jul 2015 20:32:23 -0700

> http://www.ietf.org/mail-archive/web/dnsop/current/msg14924.html

If we find some of the situations we find ourselves in the present less
then desirable, we should produce incentives that make them less likely
to occur and which support experimental deployment.

We have proposals along those lines and I think we'll get better
outcomes if we continue to pursue that.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 17 Jul 2015 12:02:30 +0200

> is unambiguously "not DNS".

Do you have evidence that alt is in fact a desirable gTLD name?  I
note that we recently went through an empirical proof of desirability
of such names, and at the very least it was not worth $185k to anyone.
I guess you might be drawing a distinction between "economically
desirable" and "politcally desirable", but I'm not sure how to measure
the latter.

One problem with "external" is that it's long.  Part of the use case,
recall, is that people want things they can bang into any old domain
name slot in any existing application, and it'll fit.  Using up 3
octets isn't so bad.  Using up 8 seems wasteful.  Would "ext" do the
job for you?

Does it matter to you that "external" has no unambiguous connotation
in lots of languages?  If not, then why is the difference between
"alt" and "external" important?  If so, why don't we need to reserve
the, ahem, "equivalent" of "external" in every language, forever?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 17 Jul 2015 12:07:05 +0200

> describes as much as is possible to describe about that use.

Why is an IANA-maintained registry a good idea?  If we have an
IANA-maintained registry, why isn't that just an alternate TLD -- it
sounds just like a "sponsored TLD" to me.

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Fri, 17 Jul 2015 13:30:55 +0200

Paul,

> is unambiguously "not DNS".

Given many of the names that were applied for, I would be quite hesitant to make assertions about what people would or would not want (or what would or would not be politically desirable) for new gTLDs in future rounds.  After all, we were talking about .FOO in this thread...

> seriously, i wouldn't object to warren's draft if the string he chose

I suspect any name chosen would have proponents and opponents based on their own assumptions and biases. Looking at the technical requirements, we'd probably want a string that would be unlikely ever to be requested and which wouldn't be significant/controversial to any particular subset of the community. A quarter-baked idea: perhaps instead of a single label that (may or may not) has significance of English, we could go with up to 26 'non-DNS' labels, i.e., .A ... .Z?

Regards,
-drc

---

From: hellekin <[email-masked]>
Date: Fri, 17 Jul 2015 09:03:04 -0300

On 07/17/2015 07:07 AM, Andrew Sullivan wrote:
>> IANA-maintained registry of non-dns uses, each pointing to an RFC
>> that describes as much as is possible to describe about that use.
> 
> Why is an IANA-maintained registry a good idea?
>

The discussion is drifting away from .onion.

It's also drifting away from at least half the current applications for
Special-Use Domain Names, the half that technically CANNOT SHARE the
same registry, and that technically CANNOT BE ADMINISTERED by a third
party.

==
hk

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 17 Jul 2015 07:38:41 -0400

+1 on support

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: joel jaeggli <[email-masked]>
Date: Thu, 16 Jul 2015 21:28:52 -0700

> what I think was intended.

I can see some explanatory text getting added, I think this coming week
will likely be useful for feedback.

> IESG, through the instrumentality of the IANA.

yup, wg document, proposed standard, 4 week ietf LC and all that.

dnsop would absolutely not be undertaking any work on the tor protocol.
It was clearly the appropriate place to handle  the problem posed by
this draft however.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 16 Jul 2015 19:57:23 -0700

> names under .onion as not DNS names.

I won't presume that we can tell the CAB Forum folks what they can do.

They've stated what they intend to do and it seems likely that the will
carry through with that.

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

>> to be information in the draft that shows that this approach will work.

I think there's a certain amount of moral hazard associated with being
extremely concerned about the conisderations arising from that. it may
be the case that they have a deadline, whether it gets added to the
registry or not should come down to the merit of the request and it's
congruence with how we run that registry.

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Fri, 17 Jul 2015 14:03:52 +0000

Hi,

I am interested by the .a to .z, .alt and .external discussion.

The goal here from the non-DNS people seems to be to have DNS type labels (thus URI's)
which are known to the recursive and authoritative resolvers to be outside of DNS.

If it is known that .a to .z are such; why where they not used?  Perhaps they should be 
publicized a little more.

However, I far prefer the single declaration of a TLD for use by these non-DNS systems.

Additionally, we a challenge with the certificate issuance for .onion, and as I have
commented, it is a very large install base, and asking them to change their TLD
with little time in which to act seems churlish.  Their application (Tor), and those of
the GNUnet etc. are entirely within the remit of 6761.

So, I propose are few things:

1. accept that the submitted proposals are fine and approve them (.onion, .gnu .zkey etc).
2. approve .alt (or whatever is decided)
3. close 6761 saying that all future things must use whatever is decided in 2.

Thus, 6761 is honored for what is was, a future path is created, and dnsop dont have to do this again and again.

Hugo Connery
________________________________________
From: DNSOP [[email-masked]] on behalf of David Conrad [[email-masked]]
Sent: Friday, 17 July 2015 13:30
To: Paul Vixie
Cc: dnsop
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

Paul,

Regards,
-drc

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Jul 2015 16:13:02 +0200

On Wed, Jul 15, 2015 at 06:17:54PM +0000,
 Edward Lewis <[email-masked]> wrote 

> expires and is bought by someone else?

Nothing human is forever. What if the private organisation issuing
DOIs collapse? What will happen of all the DOIs bought on the
marketing-created assumption that it was stable?

Or we should use only identifiers issued by organisations older than
three centuries, on the assumption that they have demonstrated
stability. A good example is ARKs (draft-kunze-ark) issued by the
French National Library (prefix 12148), which was established in 1537
AD meaning it is probably here to stay.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Jul 2015 16:17:03 +0200

On Wed, Jul 15, 2015 at 02:22:58PM -0700,
 Francisco Obispo <[email-masked]> wrote 
 a message of 48 lines which said:

> to create a new dns-like protocol that uses .foo, does that mean
> that we should automatically block it?

No need to speculate about "what happens". It already happened, the
vendor was Apple and the result was the registration of .local (first
use of RFC 6761).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Jul 2015 16:15:37 +0200

On Wed, Jul 15, 2015 at 12:35:12PM -0700,
 Francisco Obispo <[email-masked]> wrote 

> of TLD application and get a fully qualified delegation.

Besides the money it costs, it would also mean having to comply with
hundreds of pages of ridiculous ICANN rules. It's a no-starter.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Jul 2015 16:20:36 +0200

I have no particular objection to the concept here, but I do have a
question about one sentence in the draft.  Section 1 states:
>    Like Top-Level Domain Names, .onion addresses can have an arbitrary
>    number of subdomain components.  This information is not meaningful
>    to the Tor protocol, but can be used in application protocols like
>    HTTP [RFC7230].
>
I honestly don't understand what is being stated here, or why a claim is
made about HTTP at all in this document.  Are we talking about the
common practice of www.example.com == example.com?  And what
significance does that last phrase have to the document?

Eliot

---

From: joel jaeggli <[email-masked]>
Date: Fri, 17 Jul 2015 07:20:59 -0700

> marketing-created assumption that it was stable?

good references are nice, but by their nature are largely outside of our
control. the best we can do in general is curate them.

if you read rfc 20, good luck trying to find a copy of USAS X3, 4-1968

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Jul 2015 16:23:32 +0200

On Fri, Jul 17, 2015 at 07:35:47AM +0200,
 David Conrad <[email-masked]> wrote 
 a message of 73 lines which said:

> It assumes folks who are developing these non-DNS protocols
> know/care about what the IETF thinks.

It is reasonable to assume that many of them do not even know that the
IETF exists. We should therefore outreach and engage with them (and
not only liaise with large bureaucracies) _but_ it would be difficult
to convince them to follow the IETF path if we cannot show them that
this path works. If it takes dozens of emails just to rediscuss
something that was already sanctioned by the WG (.onion...), it will
be difficult for the IETF missionaries to convert the natives in
non-DNS lands.

[That's why I was never of fan of .alt: I think it will never be
accepted anyway. People who "squatt" TLDs are rational.]

> I agree on the need for less friction, hence my interest in trying
> to find objective criteria. Lack of objective criteria pretty much
> guarantees the same sort of discussion and 'heavy process' you're
> complaining about.

No, friction comes from the fact that some people see the IETF as a
control center and not as a service, trying to use it to enforce their
own views such as "ICANN should have the right to decide for every
string in the root".

---

From: David Conrad <[email-masked]>
Date: Fri, 17 Jul 2015 16:31:47 +0200

Hugo,

> which are known to the recursive and authoritative resolvers to be outside of DNS.

That appears to be the goal of some folks, however the insertion of strings into the Special Names Registry will not (of course) by itself result in recursive and authoritative servers.

> publicized a little more.

They aren't -- my suggestion was to avoid bikeshed painting on the specific string to use for the "not DNS" TLD.

> Additionally, we a challenge with the certificate issuance for .onion,

For clarity, I was speaking of the string being used in Warren's ALT draft. I've already indicated support for ONION in the Special Names Registry for pragmatic reasons.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Fri, 17 Jul 2015 16:32:55 +0200

Stephane,

> vendor was Apple and the result was the registration of .local (first

No. .LOCAL was not already in the root zone. .FOO is.

Regards,
-drc

---

From: Richard Barnes <[email-masked]>
Date: Fri, 17 Jul 2015 16:38:18 +0200

> significance does that last phrase have to the document?

I made a comment on this to the authors earlier, and they decided to
leave it as-is :)

The idea is that TOR routing will only use the first label after
.onion, but if you're using the .onion name in an application, that
application might use the whole name.  For example, if you put
"http://mail.example.onion/", TOR will route on "example.onion", but
the HTTP Host header might be "mail.example.onion".

--Richard

---

From: hellekin <[email-masked]>
Date: Fri, 17 Jul 2015 11:42:29 -0300

On 07/17/2015 11:20 AM, Eliot Lear wrote:
>>    Like Top-Level Domain Names, .onion addresses can have an
>>    arbitrary number of subdomain components.  This information
>>    is not meaningful to the Tor protocol, but can be used in
>>    application protocols like HTTP [RFC7230].
>>
> I honestly don't understand what is being stated here, or why a claim 
> is made about HTTP at all in this document.  Are we talking about the

It means that when resolving .onion addresses, the Tor protocol only
checks the first label in the onion chain (e.g., facebookcorewwwi in
example.facebookcorewwwi.onion), ignoring any eventual label under that
(here: example). But Tor doesn't remove these labels: they're passed on
to the application at the endpoint.

For example, imagine Facebook runs https://static.facebookcorewwwi.onion
to serve images for their website.  To the Tor protocol, only
facebookcorewwwi is used to identify the onion service and find a route
to it, but once the connection is established between the Web browser
and the Web server across the onionspace, static.facebookcorewwwi.onion
becomes meaningful to the Web server.

==
hk

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Fri, 17 Jul 2015 14:51:33 +0000

Hi David,

Sorry, comments here, rather than in context:

Yes, the challenge is getting 6761 strings into the resolvers.  If this is not
achieved, it largely nullifies the efforts, from a privacy perspective,
though it does enable the certificate issue.  I suggest that the first,
privacy, is the main issue.

All attempts to curtail bike shedding are worthy.  :)

That choice of a singular "not-DNS" TLD is I think the important
discussion.  I support something short.  .alt would do nicely.

I suggest the importance of the establishment of a TLD
to serve the purpose for *all* future non-DNS systems outweighs
the interests of any claim of interest in whatever is chosen.
And, it should be short.  Max 3 letters.  I like the confluence
between the historic USENET .alt and the proposed 6761 .alt.

I thank those that are taking a pragmatic response to this 
annoyance; dnsop is caught between 6761 and its potential
long term implications.  I think we need to respond in 6761's spirit
and also curtail potential 18 month discussions into the future.

Regards,  Hugo
________________________________________
From: David Conrad [[email-masked]]
Sent: Friday, 17 July 2015 16:31
To: Hugo Maxwell Connery
Cc: [email-masked]
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

Hugo,

Regards,
-drc

---

From: hellekin <[email-masked]>
Date: Fri, 17 Jul 2015 11:52:12 -0300

> No. .LOCAL was not already in the root zone. .FOO is.
*** Therefore the .FOO label is not available for Special-Use anymore,
end of story. A Special-Use name cannot be an already registered name in
the root zone.

If you referring to e.g., .corp that has proposals both for Special-Use
and normal ICANN assignation, this is a distinct issue, as the label is
not yet in the root zone, and there are good reasons why it would be a
bad idea to put it there (already existing name conflicts) but not
compelling (if the .corp registrar is ready to deal with the extra load,
or if capturing all the "leaked" requests from random devices around the
world is not deemed to pose a security issue...).  This is an entirely
different matter.

Now if there's a prior request for Special-Use and an ICANN registration
appears after the fact, that would be a problem: if someone would ask to
register .onion or .gnu today, we'd run into the problem you're suggesti
ng.

==
hk

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Jul 2015 17:17:36 +0200

Hi Richard,

Thanks for the explanation.  Please see below.

On 7/17/15 4:38 PM, Richard Barnes wrote:
> -

I just leave the IESG and WG with the comment that two of us "old
timers" are trying to divine the meaning of those two sentences, and
that can't be good for others with (even) less clue.  Personally I think
the easiest approach is to remove those two sentences, but if others
really disagree, then a bit more clarity seems in order.

Eliot

---

From: David Conrad <[email-masked]>
Date: Fri, 17 Jul 2015 17:26:58 +0200

Stephane,

> own views such as "ICANN should have the right to decide for every

As far as I am aware, the IETF has defined the "domain name" namespace and, via RFC 6761, has implicitly asserted it has control over that name space. To my knowledge, the IETF has delegated policy of creating top-level strings for use in the DNS, that is, the things that go into the root servers, to ICANN. One of the issues I see is that there is no clear criteria by which a particular string can be reserved (or pre-empted) by the IETF (as is the IETF's right) and which is constrained by ICANN's policies and processes.

This, of course, has no impact on folks who squat on names (at least until they decide they want/need to interoperate with the IETF-defined namespace).

However, trying to understand your perspective, I gather you don't see the IESG approval as a control point?

Regards,
-drc

---

From: hellekin <[email-masked]>
Date: Fri, 17 Jul 2015 13:14:04 -0300

> really disagree, then a bit more clarity seems in order.
*** Removing the sentences sounds fine to me: they're not relevant to
the name registration itself.

==
hk

---

From: Paul Vixie <[email-masked]>
Date: Fri, 17 Jul 2015 10:57:34 -0700

i think that deep discussion over whether .external is the right exit
gateway from dns naming is premature, and that we should first decide
whether a single exit gateway is preferred, and whether IANA should
craft a registry of external-to-the-dns uses of the internet name space.
i am in favour of a single exit, and a registry, with a pointer to an
RFC for any second-level term under that exit label (placeholdered as
.external but requiring discussion later if we get that far.)

i'd hope to see apple's mdns work migrate to this new system, as
.zeroconf.external or even .bonjour.external, and the /etc/hosts lookup
mechanism migrate to .hosts.external, and sun's yellow pages system
migrate to .nis.external, and so on.

i would argue, by the way, that "onion" is a kind of technology, onion
routing, of which Tor is the first and best-known but not the last. so,
i'll prefer .tor.external over .onion.external.

this whole thread is in the area of "dns presentation layer" which is
quite ill-defined. users and apps currently mix in non-dns strings which
can look fully qualified (have some dots in the middle) with dns
strings, and we're counting on nature to avoid collisions for us.
ideally we'll define an exit gateway such that non-dns names can be both
expressed to a user through an application, and entered by a user into
an application, for which collisions are prevented by design and
artifice. the application should not need to know anything about these
naming policies, because the operating system and/or name lookup
libraries should just work.

an alternative to a reserved top-level domain as an exit gateway for the
dns presentation layer would be something along the lines of what IDN
does, prepend some characters and dashes to a name in order to ensure
that it cannot conflict. so, instead of .onion, something like .xq--tor.
it's my view that this is uglier and also has bad human factors
engineering (hard to read and hard to type) but it should be mentioned
in passing as a road deliberately not taken, to inform historians in the
future.

Andrew Sullivan wrote:
> Do you have evidence that alt is in fact a desirable gTLD name?

as you know, proof is impossible. i'm working backward from .xyz and
also this:

https://en.wikipedia.org/wiki/Alt.*_hierarchy

>   I

as you know, the current gTLD round will not be the last.

> desirable" and "politcally desirable", but I'm not sure how to measure

there are rock musicians, medicinal practitioners, historians, and
energy researchers working right now today all over the world who call
their brand of work "alternative". so, consider whether "artistically
desirable" is a third category, and whether there can't be a fourth.

> octets isn't so bad.  Using up 8 seems wasteful.  Would "ext" do the

compared to alt, yes. note that .external is long on purpose-- to avoid
conflict with nature. while "ext" is not the short or abbreviated form
for any popular thing i am aware of, it could conceivably be an acronym
for something which is or becomes popular. not so with .external.

> the, ahem, "equivalent" of "external" in every language, forever?

since apple has been selling internationally for decades, and their
.local has never been translated into non-english character sets, i
think it's possible that all internet users and application, for all
time, will have the ability to read and type simple english words.

-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Fri, 17 Jul 2015 11:10:06 -0700

> The discussion is drifting away from .onion.

yes, and deliberately so, since .onion is an example of a wider problem.

> same registry, and that technically CANNOT BE ADMINISTERED by a third

this is an ietf working group about dns. by charter, any discussion of
how to interoperate while providing new functionality is on-topic. as i
just wrote up-thread, the ietf currently makes no recommendation for
encoding non-dns names in an unambiguous and portable way so that
software authors of name lookup libraries can safely encode and decode
non-dns names without fear of collision.

the idea of first use being the only arbiter of reservation, and of such
reservation being the only guarantor of non-collision, makes some of us
worry that there are two long lines marching toward us: one being new
gTLD's that have not been proposed yet, and the other being new
applications that haven't been invented yet. the internet loves scale.
thus this thread.

i apologize for the lack of a pre-existing syntactic framework into
which tor's names could have been encapsulated from the outset. i
apologize even more for the fact that tor's perfectly reasonable request
for .onion is now causing this working group to consider scaling factors
which tor by itself would not have cared about.

-- 
Paul Vixie

---

From: hellekin <[email-masked]>
Date: Fri, 17 Jul 2015 15:56:01 -0300

On 07/17/2015 02:57 PM, Paul Vixie wrote:
> conflict with nature.
*** By "conflict with nature" do you mean that having to type .external
with one thumb would strain it faster, leading to an obsolescence of
hand-held devices?

More seriously, does that mean you're opposing the .onion draft, or are
you simply drifting away to the later work on RFC6761bis? I'm asking
because the authors requested .onion, not .tor, nor .tor.alt, nor
.tor.external.  I suppose that if .exit was part of this draft, it would
make more sense why .onion and .exit instead of a single .tor. That
said, .tor would save more thumbs.

==
hk

---

From: Paul Vixie <[email-masked]>
Date: Fri, 17 Jul 2015 12:07:50 -0700

> with one thumb would strain it faster, leading to an obsolescence of

snark won't advance this discussion. i'm choosing to reply. my default
is to just hit delete.

> .tor.external.

by 6761, .ONION is a valid request and your papers are in order. i don't
love it and i wish we had a more scalable framework, but by the rules of
this game, .ONION should be approved.

but we should also improve the rules to something scalable, like a
single exit gateway from the internet namespace into non-internet
namespaces.

-- 
Paul Vixie

---

From: "Francisco Obispo" <[email-masked]>
Date: Fri, 17 Jul 2015 12:20:10 -0700

+1

The issue not being with ONION per se, but with the .CARROTs and the 
.FOOs of the future, having a reserved TLD/namespace with a registry 
along with a well defined process on how to do reserve names should be 
the way to go.

We also need to close the doors to those who decide to ignore whatever 
guidelines we come up with and start using .CARROT and expect the IETF 
to reserve it for them.

Regards,

—
Francisco Obispo
Uniregistry Inc.

---

From: Rubens Kuhl <[email-masked]>
Date: Fri, 17 Jul 2015 16:40:12 -0300

> single exit gateway from the internet namespace into non-internet

Which could be done by tuning https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06 with some twists:
- Deprecating that part of RFC6761 that allowed the .ONION request, shutting this door;
- Considering whether .alt or .external would be the string for such uses (.ext, perhaps ?);
- Creating a registry for .alt names that doesn't carry an uniqueness guarantee but can guide developers so they don't use names already declared to be used ;
- Automatically create starting entries for such a registry including known names such as .onion.alt/external, .zeroconf.alt/external, .bonjour.alt/external so applications can move to those names at some point.

Rubens

---

From: hellekin <[email-masked]>
Date: Fri, 17 Jul 2015 17:06:18 -0300

> which tor by itself would not have cared about.
*** I apologize that you feel the need to apologize.

There's certainly a need to adapt RFC6761 to the realization of the
community of its transformational power. But it's unfair to put the lack
of foresight of the community that adopted RFC6761 on the people who are
using it, especially with good reasons.

I think it's important that the IETF recognizes that the free software
community of developers of peer-to-peer systems spontaneously came
together to approach the IETF and solve an operational issue of their
systems with the DNS, causing problems to the DNS and posing security
issues to the users of P2P systems.

This is a concrete example of the Internet community cooperating to make
things better. This has nothing to do with future issues of scalability:
it's a distinct problem that we have now and are trying to solve
together. We already identify that RFC6761 causes problems and that it
needs to be worked on, clarified, etc. But that should remain a separate
issue.

If there is an RFC and when people come to use it, suddenly it's not
valid anymore, because people realize in hindsight that it's flawed or
that oops, it's not what we expected, it poses a serious doubt about the
validity of the institution. The danger I see, much before a scalability
issue in DNS, is that developers who are more interested in running code
than rough consensus will simply run the code and ignore the human part
of the process, leading to a transformation of the Internet like
everywhere else in society: where cold reductionist views tramp the
human and leaves us outside of the living sphere, until we're redundant,
useless, uncared for bloodless servo-units.

I get the gravity of the situation. But I doubt that trying to fix the
issue by tying the existing applications to a non-sequitur by fear of
creating a precedent will achieve anything good at all. On the contrary
I believe that now the jack is out of the box, it's important to realize
that new applications will not be treated the same way that they were
until now, pending a new version of RFC6761 that updates or obsoletes
it; that among existing applications there are different cases, some of
which are pretty easy to solve (e.g., .onion) for they only seek to
prevent useless and potentially dangerous requests, while others are
more complicated because they involve ICANN processes, SSAC
recommendations, etc. (e.g., .corp, .mail, .home).

Treating all the Special-Use Domain Names requests as they were a
monolithic block did not work, and won't work (I'm talking from
first-hand experience given that this WG has postponed to death tackling
the single P2PNames draft), so it would be much more effective if we
would take one step at a time, and not project future conditions where
they do not exist yet and are likely to change drastically once RFC6761
is revised.

My 2 satoshi.

==
hk

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Jul 2015 13:08:43 -0700

> - Deprecating that part of RFC6761 that allowed the .ONION request, shutting this door;
This would likely result in Warren's draft never getting consensus, so 
be careful what you ask for.   If you want to make this change, it would 
be better to do it in a separate draft, so that we could have a clearly 
focused discussion about the change you want to make, and not mix it up 
with a related-but-different discussion about .ALT.

---

From: Rubens Kuhl <[email-masked]>
Date: Fri, 17 Jul 2015 17:17:32 -0300

> Em 17/07/2015, à(s) 17:08:000, Ted Lemon <[email-masked]> escreveu:
> 
> This would likely result in Warren's draft never getting consensus, so be careful what you ask for.   If you want to make this change, it would be better to do it in a separate draft, so that we could have a clearly focused discussion about the change you want to make, and not mix it up with a related-but-different discussion about .ALT.

Ted,

I personally have no position whether we shut the door before or after .ONION; there is already a number of names in this category so if .onion was the first I would strongly oppose its adoption, but since it's not, it doesn't care for the scale problem whether .onion gets the last bite of this or not. 
Considering .ONION already resolved, do you still see issues preventing consensus ? 

Rubens

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Jul 2015 16:37:57 -0400

> Considering .ONION already resolved, do you still see issues preventing consensus ?
I think the best argument in favor of forbidding the allocation of 
further special-use TLDs is that each such TLD will by default be 
handled by software that doesn't know about it by sending a query. 
Whereas if we have a single well-known exit, and the default behavior 
for names under that exit is that the local resolver says "no such 
host," and any caching resolver on the way to the root returns NXDOMAIN, 
then that's a big win.

So I think that this argument could potentially gain consensus.   I just 
think that trying to do it in the same document as the .ALT document is 
a bad idea, because .ALT can gain consensus whether people agree with 
the other argument or not.

---

From: "John Levine" <[email-masked]>
Date: 17 Jul 2015 21:37:48 -0000

>I do think the path forward is one cutout (my opinion only) 

The absence of a registry is a feature.  Or if there is an IANA
registry, it should be FCFS and specifically allow multiple
registrations for the same name.

A few zillion messages ago I likened the usual TLD process to a gold
rush in which people dashed in and squatted on whatever parcel looked
most salable to someone else.  The .alt (or whatever) non-TLD is more
like homesteading, there's plenty of land, anyone can have some, but
you can only keep it if you improve it.

Since the cutout names exist only to the extent that application
software handles them, the way you make a cutout name work is to write
the software and get people to use it.  Since there is no authority
deciding who wins if names conflict, and no way to enforce such a
decision even if someone tried to do so, it is in the interest of all
of the homesteaders to pick names that won't conflict with anyone
else, since otherwise the pain will land squarely on themselves.

R's,
John

PS: No reason IANA has to run the registry.  There can be a zillion
unoffcial registries with the same homestead property, they only
matter to the extent that people actually use them.  Perhaps I'll put
mine at alt.site, or dotalt.sucks.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Jul 2015 18:16:01 -0400

> To be honest, I doubt this. It assumes folks who are developing these non-DNS protocols know/care about what the IETF thinks.
I suspect that more do than you think.   However, what they think about 
the IETF is that we have a very heavyweight process, and it's hard to 
get anything done here in a timely fashion.
> I agree on the need for less friction, hence my interest in trying to find objective criteria. Lack of objective criteria pretty much guarantees the same sort of discussion and 'heavy process' you'…
With all due respect, this is a classic mistake that geeks make: 
thinking that there can be some objective criterion or set of criteria 
that would make decisions simple.   The reality is that to make criteria 
of this sort objective would require a solution to the halting 
problem.   At which point the cold minds that sleep in the space between 
the stars would awaken.   So really, for the sake of humanity, I think 
it would be best to avoid going down this path. Er, that is, if 
resolving this discussion depends on finding some such objective 
criteria, we are never going to resolve it.

It's pretty clear that .onion in particular does satisfy the 
non-objective criteria we currently have.

---

From: David Conrad <[email-masked]>
Date: Sat, 18 Jul 2015 01:10:45 +0200

Ted,

On Jul 18, 2015, at 12:16 AM, Ted Lemon <[email-masked]> wrote:
> With all due respect, this is a classic mistake that geeks make: thinking that there can be some objective criterion or set of criteria that would make decisions simple.  The reality is that to make criteria of this sort objective would require a solution to the halting problem.

And this is a classic mistake geeks make: that there has to be a perfect set of criteria for all scenarios. This demand for the perfect instead of the good enough has derailed so much of what the IETF does, it's sad to see it here as well.

As I've said several times, I believe there are objective criteria that would cover the majority of cases. For example, the deployed base of TOR appears sufficiently large in terms of orders of magnitude as to justify moving ONION to Special Names. Do you disagree that this would be an objective criteria?

Of course, there are _always_ corner cases that will require subjective evaluations. However, because this is true does not preclude coming up with objective criteria that allows us to deal with et majority of cases.

> It's pretty clear that .onion in particular does satisfy the non-objective criteria we currently have.

Oh, and what "non-objective" criteria would those be?

Regards,
-drc

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Jul 2015 20:34:45 -0400

> Oh, and what "non-objective" criteria would those be?
The ones in the special-names RFC, which the author and the working 
group apparently considered sufficient.  Which, I am afraid, contradicts 
the point you were making about how we can have incomplete "objective" 
criteria that will save time.

Consider this: in order for .onion to get a 6761 allocation, it has to 
be the case that there are >O(100k) users.  That is the "objective" 
measurement I would give for your question.  But there are >O(100k) 
users _now_, long after the point when .onion should have gotten a 
special-use allocation.   So this objective criterion actually would 
have refused .onion an allocation when it should have happened.   Which 
lands us back in the subjective criteria, which was my point.

---

From: "John Levine" <[email-masked]>
Date: 18 Jul 2015 01:41:35 -0000

>> With all due respect, this is a classic mistake that geeks make: thinking that there can be some objective criterion or
>set of criteria that would make decisions simple. ...

>As I've said several times, I believe there are objective criteria that would cover the majority of cases. ...

Perhaps we're confusing objective criterial with mechanical criteria.

Objective criteria might be "a large and viable user community, and
identifiable significant harm if names that leak into the DNS
resolve."  We still have to agree on definitions for large, viable,
and significant, but those are the sort of decisions that human
adjudicators make every day.

A mechanical criterion might be "observable traffic from at least
100,000 different IP addresses every day for at least 30 days."
That'd be a horrible criterion, not least because it's easy
for a modestly well funded adversary to fake.

R's,
John

---

From: hellekin <[email-masked]>
Date: Fri, 17 Jul 2015 23:31:40 -0300

> for a modestly well funded adversary to fake.
*** Also, if I may, because it would not encourage developers of new
protocols to approach IETF early on if they already know there's not a
chance they will match the criteria; instead they will run the code, and
once they have a large user base come to IETF and say: "hey, look, I
created a massive problem, do you want to fix it?".

(Completely agree on objective vs. mechanical)

==
hk

---

From: joel jaeggli <[email-masked]>
Date: Sat, 18 Jul 2015 06:49:22 +0200

On 7/18/15 12:16 AM, Ted Lemon wrote:
>> To be honest, I doubt this. It assumes folks who are developing 
>> these non-DNS protocols know/care about what the IETF thinks.
> I suspect that more do than you think.   However, what they think 
> about the IETF is that we have a very heavyweight process, and it's 
> hard to get anything done here in a timely fashion.

Innovation is not something we should have any interest in gating. Not
only is that futile, but it's also wildly presumptive of our role in
the process.

We can however work to make it eaiser, both to bring work to the IETF and
so support it to responsible stewardship.

>>> avoid applying too much process friction onto documents of this 
>>> type.   Granted, it's hard to tell how much is too much, but this
>>> particular discussion was kicked off in November of 2013, and
>>> here it is July of 2015, and we are still talking about it. 
>>> That's a pretty heavy process.
> thinking that there can be some objective criterion or set of 
> criteria that would make decisions simple.   The reality is that to 
> make criteria of this sort objective would require a solution to the 
> halting problem.   At which point the cold minds that sleep in the 
> space between the stars would awaken.   So really, for the sake of 
> humanity, I think it would be best to avoid going down this path.
> Er, that is, if resolving this discussion depends on finding some
> such objective criteria, we are never going to resolve it.
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Jul 2015 10:46:45 -0700

> registrations for the same name.

i disagree.

the ietf's stated purpose is to ensure interoperability. for many years
we all treated that as "make sure everybody agrees as to the meaning of
what's on the wire." the .ALT (or .EXTERNAL or whatever) specification
will not change what's on the wire, but its purpose is still to ensure
interoperability. simply put, we want any internet-capable device to
have the same experience when using non-internet naming. that's why i'm
describing it as a change to the dns presentation level. if something is
reachable only via some non-internet naming system, it should still be
possible to publish a link to it on the web, which like many links will
only work if you're inside some perimeter and have installed some kind
of non-internet software, but there will still be interoperability among
all those who are inside that kind of perimeter and/or have installed
that kind of software.

> ...

while noone could or would try to stop you from doing those things, it
is IANA's function to maintain registries that support interoperability.
to that end, FCFS is fine, but there should be some kind of RFC
describing the string (even if it's one page long and just denotes the
string and says "this is for UUCP" or whatever) and there should be some
way for cooperating application developers to respect eachother's
cutouts. that is IETF's proper function here.

-- 
Paul Vixie

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Sat, 18 Jul 2015 17:52:51 +0000

+1.

--

i disagree.

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Sat, 18 Jul 2015 17:56:57 +0000

Actually, +100, or some relatively very large number.

--

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2015 15:08:25 -0400

> have the same experience when using non-internet naming.

Sure, we all want that, but an IANA registry that only lets one entity 
register each name would be counterproductive, because names have semantic 
meaning.  Nobody cares whether they get rrtype number or port number 42103 
or 42104.  But if two people show up with something that uses sex.alt, and 
IANA tries to tell one of them to use sey.alt instead, fat chance.

A simple FCFS will be full of squatters, not actually doing anything with 
the names, but hoping, probably wrongly, that the name will be valuable 
some day.  (See the first couple of thousand registrations in any of 
ICANN's new TLDs for an example of this.)  Furthermore, let's say 
someone's squatting on sex.alt, someone else builds a P2P* service, looks 
around, sees that nobody's actually using sex.alt, so he calls his 
sex.alt.  Now the registry is actively wrong.

If we try to make rules about hoops one has to jump through to register a 
*.alt service, we're back exactly where we are now with .onion.  People 
will ignore them until their critical mass becomes a fait accompli, so why 
bother.  If two people show up about the same time with something called 
sex.alt, how are we supposed to decide who wins?  We get to have our own 
IETF-lite version of the .africa fiasco currently happening at ICANN. 
And, of course, if we do pick one, the other will still keep calling 
itself sex.alt and there's nothing we can do about it.

That's why I think that a FCFS non-exclusive registry could be useful so 
that people who want to avoid collisions can find infor that lets them 
assess the collision risk for their favorite names, and it doesn't matter 
whether it's at IANA or somewhere else since it's just voluntary advice. 
Since we are not the Domain Name Police, if people want to create services 
with names that collide, they will do so.  It'd be nuts to pretend 
otherwise.

R's,
John

* - Porn 2 Porn, of course

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Jul 2015 18:22:33 -0700

John R Levine wrote:
> register each name would be counterproductive, because names have
> semantic meaning.

you must have misunderstood me. i'm arguing for
<localpart>.<uniquename>.EXTERNAL, where the <uniquename> is registered
with IANA on a FCFS basis to prevent collisions, and <localpart> is not
subject to standardization or even documentation (so, the defining RFC
can be one page long and just say, "this is for Tor").

> Nobody cares whether they get rrtype number or port number 42103 or
> 42104.  But if two people show up with something that uses sex.alt,
> and IANA tries to tell one of them to use sey.alt instead, fat chance.

IETF is not a regulator and there are no network police or armed forces.
you can use whatever identifier you want, and if you can convince others
to share that use with you, that's all fine, even if it conflicts with
the use many others do make, or might wish to make, of the same code
point. IANA has no power to tell anybody anything.

what IANA can do and should do is, allow those who want to cooperate and
who want to avoid conflict, to register their unique identifiers so as
to protect their applications and users against unintentional collisions
with other applications and developers who also wish to cooperate and
who also wish to avoid conflict.

> ...
> That's why I think that a FCFS non-exclusive registry could be useful
> so that people who want to avoid collisions can find infor that lets
> them assess the collision risk for their favorite names, and it
> doesn't matter whether it's at IANA or somewhere else since it's just
> voluntary advice. Since we are not the Domain Name Police, if people
> want to create services with names that collide, they will do so. 
> It'd be nuts to pretend otherwise.

i am not pretending otherwise, though i may be "nuts" for other reasons.

since IETF seeks interoperability above all, a non-exclusive registry
would serve no purpose.

-- 
Paul Vixie

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2015 22:50:16 -0400

> since IETF seeks interoperability above all, a non-exclusive registry

To me, it's a choice between playing King Canute and documenting reality.

These are mnemonic names visible to users, which makes them different from 
nearly all existing IANA registries.  They're also unusual that each one 
is likely to be implemented by its own hack, often one that doesn't use IP 
addresses or TCP or UDP for transport, so that it's far from obvious that 
even if the names were different, multiple *.alt hacks could coexist on 
the same computer.  (This is not a proposal to invent a SOCKS plugin API.)

If two people want to use sex.alt or whatever, they're going to do it.  We 
can close our eyes and pretend that only the one who sent in the first I-D 
exists, or we can keep a real list that documents the software that people 
are using.

For the most part, I expect that people will look in the registry (or 
registries) to see what's already in use and pick names that don't 
collide, since life is easier that way.  But if they do collide, I'd 
rather know the bad news up front rather than depending on folklore to 
know which of the names in the registry work and which ones collide with 
things you have to find out about somewhere else.

In case it's not obvious, FCFS does require some minimal level of info so 
people can find out more, but the harder we make it to register, the more 
likely people are to distribute software and not tell us about it.

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

---

From: Bob Bownes -Seiri <[email-masked]>
Date: Sat, 18 Jul 2015 23:12:48 -0400

On Jul 18, 2015, at 22:50, John R Levine <[email-masked]> wrote:

> 
> For the most part, I expect that people will look in the registry (or registries) to see what's already in use and pick names that don't collide, since life is easier that way.  But if they do collide, I'd rather know the bad news up front rather than depending on folklore to know which of the names in the registry work and which ones collide with things you have to find out about somewhere else.
> 
> In case it's not obvious, FCFS does require some minimal level of info so people can find out more, but the harder we make it to register, the more likely people are to distribute software and not tell us about it.

By this logic, using a FCFS 'registry' model implies at least enough information (if not a requirement) for some of tracking the registrant to confirm continued use, transfer, release or abandonment at the very least, no?

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2015 23:27:21 -0400

> By this logic, using a FCFS 'registry' model implies at least enough 
> information (if not a requirement) for some of tracking the registrant 
> to confirm continued use, transfer, release or abandonment at the very 
> least, no?

To the extent that's practical, sure.  There are plenty of existing IANA 
entries that have little more than an e-mail address to contact for more 
information.

But once again, if we start inventing hoops for people to jump through, 
they won't. That's counterproductive since we have no control over what 
they're doing, so we'd like them to voluntarily tell us.

Regards,

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Jul 2015 21:01:58 -0700

John R Levine wrote:
> ...
>
> But once again, if we start inventing hoops for people to jump
> through, they won't. That's counterproductive since we have no control
> over what they're doing, so we'd like them to voluntarily tell us.

i am concerned about the above implicit mischaracterization of the
opposing view, since the opposing view is mine in this case. there are
no hoops here. people will register if they want to, and people will
check the registry if they want to. so, we are not in control of what
people are doing, and we're not trying to be. this discussion is going
to proceed more efficiently if we each speak for ourselves.

so: offering someone a chance to register that a conflict exists does
not serve the purpose of advancing interoperability. that is, the
information "ONION.ALT exists, see http://whatever" is useful, whereas
the information "ONION.ALT exists, see http://someplace and/or
http://someplace_else" is not useful. this, to me, is what FCFS means.

-- 
Paul Vixie

---

From: "John R Levine" <[email-masked]>
Date: 19 Jul 2015 00:55:24 -0400

> http://someplace_else" is not useful. this, to me, is what FCFS means.

Really, I get that.  But here's the two options:

A) registry says "ONION.ALT exists, see http://someplace and/or 
http://someplace_else", you say hm, two different packages, I better look 
at both of them to see which one is installed on my computer.

B) registry says "ONION.ALT exists, see http://someplace", you look at it 
and scratch your head when you realize it's not what's on your computer so 
you go do a Google search and eventually find http://someplace_else.

There is no C), since we don't control what software people write.  I 
don't understand why B) would be better for anyone.

Regards,

---

From: joel jaeggli <[email-masked]>
Date: Sun, 19 Jul 2015 08:10:02 +0200

I think this is a useful and interesting discussion. but it's anchored
in the .alt proposal which we should separate from the onion tld last
call I hope.

Thanks
joel

On 7/19/15 6:55 AM, John R Levine wrote:
> http://someplace_else", you say hm, two different packages, I better
> look at both of them to see which one is installed on my computer.
> 
> B) registry says "ONION.ALT exists, see http://someplace", you look at
> it and scratch your head when you realize it's not what's on your
> computer so you go do a Google search and eventually find
> http://someplace_else.
>

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Sun, 19 Jul 2015 07:26:07 +0000

Hi,

My reflections on this interesting discussion:

Software using names under *.alt (or whatever it will be) do not use DNS, by definition.

Thus, there can never be a DNS name collision.  It will be up to the alternate name
resolution software, and its users, to deal with the name collision problem, until IETF
decides to take on name management for this/these non-DNS name resolution systems.

So, we dont have to solve this problem.  I dont believe that a registry is required at all.

If we do offer one, that registry should be for dual entries (name, name resolution mechanism)
as (sex.alt, tor hidden service) and (sex.alt, GNUnet) are different things using different
mechanisms, but the same label.

Regards,  Hugo

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 19 Jul 2015 09:36:09 +0200

On Sat, Jul 18, 2015 at 11:27:21PM -0400, John R Levine wrote:
> But once again, if we start inventing hoops for people to jump through, they
> won't. That's counterproductive since we have no control over what they're
> doing, so we'd like them to voluntarily tell us.

Yes.  The point of the alt space is that people can do whatever they
want there, not that they can do what they want if they sign up for
such doing.  We have no idea whether this will work, but it's worth a
try.  I am strongly opposed to adding an IANA registry for alt.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Christian Grothoff <[email-masked]>
Date: Sun, 19 Jul 2015 09:52:56 +0200

> they're doing, so we'd like them to voluntarily tell us.

And you want to be careful about what you require. Some P2P overlay
network developers try hard to not reveal their identity. Not to
mention, developers may change.  Who is in charge of BitCoin or
NameCoin? By what authority? Let me know if you find out ;-).
(Hint: you cannot, nobody is.)

E-mail addresses also don't work well: mine has changed over the years.
I2P "lost" control over its original DNS domain for many years, breaking
e-mail and domain name references to the project.  But, it was always
possible to find it for those looking...

So what's practically achievable is likely way less than what would be
desireable.

---

From: Steve Crocker <[email-masked]>
Date: Sun, 19 Jul 2015 03:42:58 -0400

Hugo, et al,

I think the experience is exactly the opposite, i.e. these names will *always* show up in the DNS.  As a consequence, I would argue that names being used for any of these purposes should not be delegated into the DNS root unless it’s for the same purpose.  Thus, if the village of Elba in the state of New York, USA, which calls itself the Onion Capital of the World applied to ICANN for .onion in some future round of gTLD applications, I would hope ICANN would turn down the application on the basis that the name is already in use.  I should note that not all of my colleagues agree with me.  When I was chair of ICANN’s Security and Stability Advisory Committee (SSAC) we noted that .belkin was one of the undelegated names that shows up quite frequently at the root.  If .belkin were delegated in the root, it would instantly change the responses those queries are currently receiving, thus raising some questions about security and/or stability for those end systems that have been generating bogus .belkin queries to root for many years.

I haven’t looked to see how often .onion and .alt show up at the root.  Others on this list can or already have done so.

Steve

---

From: Steve Crocker <[email-masked]>
Date: Sun, 19 Jul 2015 04:02:28 -0400

Hugo, et al,

Steve Crocker

(Founding chair of ICANN’s SSAC; currently chair of the ICANN board, speaking as an individual not officially on behalf of the ICANN board)

---

From: Paul Vixie <[email-masked]>
Date: Sun, 19 Jul 2015 01:09:48 -0700

John R Levine wrote:
> But here's the two options:
>
> There is no C), since we don't control what software people write.

i believe we have some influence. if someone chooses to use the .ALT (or
.EXTERNAL or whatever) notation for their application even though they
can't get the unique 2LD they want, then i'll predict that their users
will hate them, and that this won't be our problem.

> I don't understand why B) would be better for anyone.

B is better for the first came first served; better for their users; and
better for the IETF.

-- 
Paul Vixie

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 19 Jul 2015 11:15:50 +0200

On 19 Jul 2015, at 10:02, Steve Crocker wrote:

> When I was chair of ICANN’s Security and Stability Advisory Committee (SSAC) we noted that .belkin was one of the undelegated names that shows up quite frequently at the root.  If .belkin were delegated in the root, it would instantly change the responses those queries are currently receiving, thus raising some questions about security and/or stability for those end systems that have been generating bogus .belkin queries to root for many years.

Later SSAC has continued to look at various namespace collision issues and have repeated the comments that various leakages is a. something that will happen (as Steve said), and b. because of the leakage it is important names are only used within the context they are intended to be used (so that the number of false positives is minimized).

If more information is sought for, let me or any SSAC member know, or have a look yourself at https://www.icann.org/groups/ssac/documents.

   Patrik Fältström
   Current SSAC Chair ;-)

---

From: David Conrad <[email-masked]>
Date: Sun, 19 Jul 2015 11:56:46 +0200

Paul,

On Jul 19, 2015, at 6:01 AM, Paul Vixie <[email-masked]> wrote:
> there are no hoops here.
> people will register if they want to, and people will
> check the registry if they want to.

For the people who want to register, an exclusive registry explicitly creates a discussion for everyone but the first registrant, i.e.:

With a non-exclusive registry:

Them: "Hey IANA, we're using .PAUL and here's the docs describing who we are and how."
IANA: "OK. We'll add your information to the others already registered for that label."

With an exclusive registry:

Them: "Hey IANA, we're using .PAUL and here's the docs describing who we are and how."
IANA: "Um, sorry. Someone else is already using that label."
Them: "But we really like .PAUL and we have deployed a zillion instances that make use of .PAUL"
IANA: "That's fine, but you're potentially creating an interoperability problem."
Them: "So tell the other guys to stop, since we've been using .PAUL since the early 1700s."
etc.

This smells like a hoop to me.

> not serve the purpose of advancing interoperability.

It doesn't address the interoperability of non-interoperable domain name overlays. It does advance interoperability in the sense of improving the state of knowledge that the non-interoperable domain name overlays exist, how they operate, who runs them, etc.

It seems to me that by making the registry exclusive, you're trying to put the IESG/IETF/IANA in the role of gatekeeper of the non-interoperable domain name overlays.

Regards,
-drc

---

From: Florian Weimer <[email-masked]>
Date: Sun, 19 Jul 2015 12:26:14 +0200

> vendor was Apple and the result was the registration of .local (first

Wasn't this part of RFC 6761 specifically created to allow the
reservation of .LOCAL, resolving the ICANN/IETF deadlock that had
prevented this before?  (In other words, the causal relationship is
different, so it's not really an example of what could happen.)

---

From: Paul Vixie <[email-masked]>
Date: Sun, 19 Jul 2015 10:10:03 -0700

> This smells like a hoop to me.

it would be .PAUL.EXTERNAL, which noone in their right mind would
"really like" or deploy a zillion instances of. granted, being in one's
right mind has never been a requirement for developers of distributed
systems technology, but still, the fact that it's a registry of 2LD
rather than TLD changes how we should interpret the impact of a
collision. someone could, as you say, deploy a zillion instances of an
app that pirates .PAUL (or .DAVID) within the context of a local
application or end system. this will not happen with .PAUL.ALT (or
.DAVID.EXTERNAL).

> It doesn't address the interoperability of non-interoperable domain name overlays. It does advance interoperability in the sense of improving the state of knowledge that the non-interoperable domai…

since the IETF gives guidance to implementers, i think it's wise to
guide non-DNS naming implementers toward non-colliding names, and to
guide end-system library and application implementers toward a
dictionary of non-DNS exit gateways within the DNS "namespace" that mean
the same thing for all of their users.

> It seems to me that by making the registry exclusive, you're trying to put the IESG/IETF/IANA in the role of gatekeeper of the non-interoperable domain name overlays.
since we're now talking about what i'm trying to do, i'll tell you, because it isn't what you said. i'm trying to create a new IANA registry of 2LD's beneath an exit-gateway reserved TLD. and like all other IANA registries i know of, i'd like IANA to only register the use of a given code point for one use, and i'd like that use to be defined by some public document.

-- 
Paul Vixie

---

From: David Cake <[email-masked]>
Date: Mon, 20 Jul 2015 10:28:05 +0800

> On 15 Jul 2015, at 8:42 pm, Edward Lewis <[email-masked]> wrote:

	I do think the privacy leakage issues from .onion names being treated as normal DNS queries are a significant issue, and likely to be one that will increase, not decrease, with broader Tor adoption and understanding.

	I agree that as software matures .onion names will not be in DNS queries - and i believe that specifying that behaviour in the RFC is an entirely appropriate way to accelerate that. Software adoption does not arrive at a mature state spontaneously, the first step to adoption is specifying what the correct behaviour should be. Unless a specific strong argument can be made that appropriate dealing with .onion names should only be in client libraries but not in DNS resolution libraries, changing resolution for .onion appears to be a useful way to mitigate a known problem.

	David

---

From: David Cake <[email-masked]>
Date: Mon, 20 Jul 2015 10:55:27 +0800

> On 16 Jul 2015, at 3:35 am, Francisco Obispo <[email-masked]> wrote:
> 
> +1.
> 
> I don’t think IETF should be chasing around widely used TLDs and trying to block them, it will be a never ending chase.
> 
> We are trying to mitigate against unknowns and perhaps the best solution is to have the TOR folks apply for .ONION on the next round of TLD application and get a fully qualified delegation.
> 
> Basically saying: If you need a globally unique identifier in the DNS, you must register it with the competent entity. If noy, you run the risk of having your users leak their queries and possibly connect to the wrong service.
> 
	There are legitimate reasons why Tor users might not want privacy leakage even to the Tor Project itself.
> This should make a better proposal for standard, basically reinforcing the one DNS one Internet message, and not the “Make sure you are leaking enough queries so that the IETF can then reserve the name for you”.
> 
> Who are we trying to protect with this remedy? TOR users? have they shown any interest in being protected?
> 
	Given that Tor is designed for privacy protection, I think it is not unreasonable to assume that its users are interested in having their privacy protected. They may not be aware of this specific issue, but we can presume that they put some trust in the Tor project developers, who clearly want this draft to go through (given co-authorship).

	David

> 
> Francisco Obispo
> CTO - Registry Operations
> ____________________________
> 
>  <http://www.uniregistry.com/>
> 2161 San Joaquin Hills Road
> Newport Beach, CA 92660
> 
> Office +1 949 706 2300 x4202
> [email-masked]
> 
> 
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>_______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: David Cake <[email-masked]>
Date: Mon, 20 Jul 2015 11:02:41 +0800

There are plausible, if unlikely, circumstances in which a fork, not just of the Tor project software itself, but of the entire project including the specific URL, might happen. While this argument is an attempt at a reductio ab absurdum, I do not think it is - the circumstance described is unlikely, but not absurd. In other words, I agree with Ted.
And as a much more active contributor to ICANN processes than IETF ones, I think Ted is right in characterisation of the appropriate interaction here.

	David

> On 16 Jul 2015, at 3:53 am, Ted Lemon <[email-masked]> wrote:
> 
> 1. Do you seriously think DNSOP would have had consensus to advance such a draft?
> 2. If DNSOP did have consensus to advance such a draft, what would your objection be?
> 
> I think that DNSOP would not advance such a draft unless a lot of reasonable people decided that they believed that .carrot was needed.   And if DNSOP did indeed advance such a draft, I think that it would be the right thing to do to go to ICANN and say "what do you guys think about this?"   I don't think we would be in a position to make demands, but we should be able to have the conversation.
>

---

From: David Cake <[email-masked]>
Date: Mon, 20 Jul 2015 11:53:48 +0800

> On 17 Jul 2015, at 10:52 pm, hellekin <[email-masked]> wrote:
> 

	Of course, ICANN has already determined that .corp does pose a security issue of sufficient  significance that .corp will not be delegated.

> register .onion or .gnu today, we'd run into the problem you're suggesti

	And objections to delegation would almost certainly be raised inside ICANN  processes and dealt with there if that happened.

	While it is worth considering whether ICANN gTLD delegation and IETF Special-Use consideration processes could end up on a collision course in theory, in practice, it is fairly unlikely. There is significant overlap between the two organisations from board level on down such that the two are unlikely to be considered in isolation. The ICANN board obviously considered the issue (as it was mentioned in correspondence from the board to the community, which I am unable to locate currently due to ICANNs execrable web site search/document management), and chose for the moment to, rather than adding formal mechanisms, to encourage members of the ICANN community to monitor discussions in DNSOP (which was the catalyst for my joining DNSOP). I personally think that informal mechanisms will be enough for the moment, and I’m sure if it proves to be inadequate that other more formal coordination mechanisms can be considered.

	David

---

From: David Cake <[email-masked]>
Date: Mon, 20 Jul 2015 12:06:54 +0800

As someone with moderate experience in both DNS and web server configuration, FWIW I found the meaning relatively obvious. The notion that HTTP Host headers might be used to change web server response independent of name resolution (e.g. that two names that return identical responses to every possible DNS query, but produce different web server responses) has been fairly intrinsic to how web servers operate for a couple of decades now, and this seems a simple but useful clarification regarding how this operates for .onion names to me.

David

> On 17 Jul 2015, at 11:17 pm, Eliot Lear <[email-masked]> wrote:
> 
> Hi Richard,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: David Cake <[email-masked]>
Date: Mon, 20 Jul 2015 12:28:04 +0800

It seems to me to be a situation similar to that with MIME types - there is value in having a well understood part of the namespace for unregistered experimentation on an FCFS basis.

David

> On 19 Jul 2015, at 3:08 am, John R Levine <[email-masked]> wrote:
> 
> Sure, we all want that, but an IANA registry that only lets one entity register each name would be counterproductive, because names have semantic meaning.  Nobody cares whether they get rrtype number or port number 42103 or 42104.  But if two people show up with something that uses sex.alt, and IANA tries to tell one of them to use sey.alt instead, fat chance.
> 
> A simple FCFS will be full of squatters, not actually doing anything with the names, but hoping, probably wrongly, that the name will be valuable some day.  (See the first couple of thousand registrations in any of ICANN's new TLDs for an example of this.)  Furthermore, let's say someone's squatting on sex.alt, someone else builds a P2P* service, looks around, sees that nobody's actually using sex.alt, so he calls his sex.alt.  Now the registry is actively wrong.
> 
> If we try to make rules about hoops one has to jump through to register a *.alt service, we're back exactly where we are now with .onion.  People will ignore them until their critical mass becomes a fait accompli, so why bother.  If two people show up about the same time with something called sex.alt, how are we supposed to decide who wins?  We get to have our own IETF-lite version of the .africa fiasco currently happening at ICANN. And, of course, if we do pick one, the other will still keep calling itself sex.alt and there's nothing we can do about it.
> 
> That's why I think that a FCFS non-exclusive registry could be useful so that people who want to avoid collisions can find infor that lets them assess the collision risk for their favorite names, and it doesn't matter whether it's at IANA or somewhere else since it's just voluntary advice. Since we are not the Domain Name Police, if people want to create services with names that collide, they will do so.  It'd be nuts to pretend otherwise.
> 
> R's,
> John
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Jul 2015 09:20:03 +0200

Hi David,

On 7/20/15 6:06 AM, David Cake wrote:
> As someone with moderate experience in both DNS and web server
> configuration, FWIW I found the meaning relatively obvious. The notion
> that HTTP Host headers might be used to change web server response
> independent of name resolution (e.g. that two names that return
> identical responses to every possible DNS query, but produce different
> web server responses) has been fairly intrinsic to how web servers
> operate for a couple of decades now, and this seems a simple but
> useful clarification regarding how this operates for .onion names to me.

Yes, there is an HTTP Host header.  Yes, responses vary by the *value*
but not by the *structure*.  As far as Apache is concerned, for
instance, I would imagine it's doing a string compare without counting
or considering dots.  By discussing an arbitrary number of components,
that paragraph implies that HTTP cares about the *structure* of the
name, when it does not (although some implementations might kludge this
with www.domain = domain). 

And I'll just hasten to add that now between you and Richard there are
two interpretations of what the text in the document means.  All I am
suggesting is a bit of clarity, please.

Eliot

---

From: David Conrad <[email-masked]>
Date: Mon, 20 Jul 2015 10:22:59 +0200

David,

> Of course, ICANN has already determined that .corp does pose a security issue of sufficient  significance that .corp will not be delegated.

For clarity, I believe ICANN has placed the delegation of .CORP on hold indefinitely. I do not believe ICANN has stated that .CORP "will not be delegated." Part of the reason for this discussion is due to this fact.

Regards,
-drc

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 20 Jul 2015 12:53:37 +0200

> For clarity, I believe ICANN has placed the delegation of .CORP on hold indefinitely. I do not believe ICANN has stated that .CORP "will not be delegated." Part of the reason for this discussion is…

.MAIL is is on hold indefinitely, while .HOME and .CORP (classified as "high risk") is "on hold" until they can be reclassfied as "low risk".

See for example https://features.icann.org/name-collision-occurrence-management-framework

   Patrik

---

From: Alec Muffett <[email-masked]>
Date: Mon, 20 Jul 2015 10:58:52 +0000

> 
> Yes, there is an HTTP Host header.  Yes, responses vary by the *value* but not by the *structure*.  As far as Apache is concerned, for instance, I would imagine it's doing a string compare without counting or considering dots.  By discussing an arbitrary number of components, that paragraph implies that HTTP cares about the *structure* of the name, when it does not (although some implementations might kludge this with www.domain <https://urldefense.proofpoint.com/v1/url?u=http://www.domain&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0A&m=A9kJsJTtp7y9FT7avJ3dH%2Biv4nQfZ6morew9jupKe6c%3D%0A&s=6e63e914f40b2ad82dba84208b2004762b55c9e266dc4e941a3b09a015a55c02> = domain).
> 
> And I'll just hasten to add that now between you and Richard there are two interpretations of what the text in the document means.  All I am suggesting is a bit of clarity, please.

Hi Eliot,

I am one of the authors of this draft, and I would like to spell out the concern which was raised to us, and which we sought, with this paragraph to try and address.

Onion addresses are much closed to (say) dotted quads (or other layer-3 addresses) than to domain names, albeit that to denote them there is the label ".onion" affixed in the place where one would expect to find a TLD.

Where the analogy between onion addresses and IP addresses breaks down is that the following is illegal (or, at least, has never been functionally viable):

http://www.192.168.0.1/ <http://www.192.168.0.1/>  (versus http://eliot.blogs.192.168.0.1/ <http://eliot.blogs.192.168.0.1/>)

...whereas the following *is* viable:

https://www.facebookcorewwwi.onion/ <https://www.facebookcorewwwi.onion/>

In some hypothetical alternate universe where we were all using IP addresses rather than DNS to connect to endpoints, it might be cute to support <subdomain>.<ipaddress> and let the "Host" header (and/or the HTTPS SNI) disambiguate the intent, though doubtless this would also lead to some kind of disaster.

In the Onion world, the canonical representation of an onion address is:

sixteencharlabel.onion (compare representations: 192.168.1.1, [::1], etc)

...and in the outline we sketched of how Onions work, we sought to describe them properly in their role as layer-3 analogues, mechanically generated hashes of a randomly generated certificate, beyond human choice except for brute-force mining.

However, the Tor software has a party trick, that (as Richard has explained) given an "onion" label for surety, it's happy to parse-out the "sixteencharlabel" label and use that for connection establishment, ignoring any other labels leftwards of that, if any.

Of course using (say) "ssh" to connect to www.sixteencharlabel.onion <http://www.sixteencharlabel.onion/> will not be beneficial, because SSH supports neither "Host" header nor SNI; but a web browser using HTTP/S will pass a Host header, and thus we may effect virtual hosting over a single ".onion" address.

In pursuit of "clarity", having had this explained, I would welcome a better and more succinct phrasing, if you can offer one and yet not bury the reader in unnecessary detail, or in technical detail which might become inaccurate as implementations improve whilst the outline remains largely unchanged.

    -a

--
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Jul 2015 15:34:00 +0200

So... Alec and I did a bit of wordsmithing and what I propose is a
slight clarification on the existing text, based on this exchange, and
here it is:

   Like Top-Level Domain Names, .onion addresses can have an arbitrary
   number of subdomain components.  Only the first first label to the
   left of ".onion" is significant to the layer 3 Tor protocol, while
   application layers above have access to the full name.  For example...

And then an HTTP example would be inserted (or otherwise "For
example..." taken out).

Eliot

On 7/20/15 12:58 PM, Alec Muffett wrote:
>>
>> Yes, there is an HTTP Host header.  Yes, responses vary by the
>> *value* but not by the *structure*.  As far as Apache is concerned,
>> for instance, I would imagine it's doing a string compare without
>> counting or considering dots.  By discussing an arbitrary number of
>> components, that paragraph implies that HTTP cares about the
>> *structure* of the name, when it does not (although some
>> implementations might kludge this with www.domain = domain). 
>>
>> And I'll just hasten to add that now between you and Richard there
>> are two interpretations of what the text in the document means.  All
>> I am suggesting is a bit of clarity, please.
>
> Hi Eliot,
>
> I am one of the authors of this draft, and I would like to spell out
> the concern which was raised to us, and which we sought, with this
> paragraph to try and address.
>
> Onion addresses are much closed to (say) dotted quads (or other
> layer-3 addresses) than to domain names, albeit that to denote them
> there is the label ".onion" affixed in the place where one would
> expect to find a TLD.
>
> Where the analogy between onion addresses and IP addresses breaks down
> is that the following is illegal (or, at least, has never been
> functionally viable):
>
> http://www.192.168.0.1/  (versus http://eliot.blogs.192.168.0.1/)
>
> https://www.facebookcorewwwi.onion/
>
> In some hypothetical alternate universe where we were all using IP
> addresses rather than DNS to connect to endpoints, it might be cute to
> support <subdomain>.<ipaddress> and let the "Host" header (and/or the
> HTTPS SNI) disambiguate the intent, though doubtless this would also
> lead to some kind of disaster.
>
> ...and in the outline we sketched of how Onions work, we sought to
> describe them properly in their role as layer-3 analogues,
> mechanically generated hashes of a randomly generated certificate,
> beyond human choice except for brute-force mining.
>
> However, the Tor software has a party trick, that (as Richard has
> explained) given an "onion" label for surety, it's happy to parse-out
> the "sixteencharlabel" label and use that for connection
> establishment, ignoring any other labels leftwards of that, if any.
>
> Of course using (say) "ssh" to connect to www.sixteencharlabel.onion
> <http://www.sixteencharlabel.onion> will not be beneficial, because
> SSH supports neither "Host" header nor SNI; but a web browser using
> HTTP/S will pass a Host header, and thus we may effect virtual hosting
> over a single ".onion" address.
>
> In pursuit of "clarity", having had this explained, I would welcome a
> better and more succinct phrasing, if you can offer one and yet not
> bury the reader in unnecessary detail, or in technical detail which
> might become inaccurate as implementations improve whilst the outline
> remains largely unchanged.
>
>
>     -a
>
> --
> Alec Muffett
> Security Infrastructure
> Facebook Engineering
> London
>

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2015 14:20:44 -0000

>For clarity, I believe ICANN has placed the delegation of .CORP on hold indefinitely.
>I do not believe ICANN has stated that .CORP "will not be delegated." Part of the
>reason for this discussion is due to this fact.

Since the new gTLD program still has five active applications for
.CORP, each of which has paid $185,000, I think it is reasonable to
assume that ICANN hasn't made a final decision either way.

R's,
John

---

From: hellekin <[email-masked]>
Date: Mon, 20 Jul 2015 11:38:55 -0300

>    application layers above have access to the full name.  For example...
*** Like TLDs, .onion addresses can have an arbitrary number of labels,
but only the first one is significant to the Tor protocol. The full
address is still passed along to the services running on top of Tor: for
example, an HTTP server may distinguish www.anexampleservice.onion from
static.anexampleservice.onion, although Tor will only use
"anexampleservice" to route to this server.

Rationale:

- not sure "subdomain components" is any clearer (unless it was defined
in the recent DNS vocabulary draft)
- Tor is not a "layer 3" protocol, moreover you can encapsulate layer 5
sessions, so it's not about "application layers above" either.
Introducing OSI layers in this draft would only bring confusion.

==
hk

---

From: Bob Harold <[email-masked]>
Date: Mon, 20 Jul 2015 13:50:52 -0400

On Mon, Jul 20, 2015 at 9:34 AM, Eliot Lear <[email-masked]> wrote:

>  So... Alec and I did a bit of wordsmithing and what I propose is a slight
> clarification on the existing text, based on this exchange, and here it is:
>
>
> And then an HTTP example would be inserted (or otherwise "For example..."
> taken out).
>
> Eliot
>

This thread has taught me more about the .onion names - thanks for that.
But I would have to agree with those that think this bit of explanation is
unnecessary to the RFC and should be excluded, rather than attempting to
clarify it.  The RFC only needs to deal with ".onion".  No need to explain
the other parts of the name.

-- 
Bob Harold

---

From: Ian Maddison <[email-masked]>
Date: Wed, 22 Jul 2015 14:04:39 +0200

Hi,

While I guess most of you are in Prague having discussions about these things, I hope you won’t mind someone who is unable to attend but who follows your work on the mailing lists from expressing an opinion...

> On 17 Jul 2015, at 08:39, Paul Vixie <[email-masked]> wrote:
> 

Obviously, there’s a balance to be struck between short and long TLDs. The advantages of short ones include eating less of the finite name length limit and less typing for users, while their disadvantages include being less descriptive and having less possibilities. I find external (7) to be too long, that a length of 4 strikes a good balance.

I agree with Paul’s comment higher up this thread regarding other uses of the word alternative and don’t feel that EXT is descriptive enough. 

Maybe it’s a British thing but when I want to contact someone or something elsewhere the word ring comes to mind, I ring them up or give them a ring.

Remote Interoperability Namespace Gateway

.ring

Which of course would fit nicely with onion.ring :)
According to ICANN’s website there doesn’t appear to be any existing application for it.

Thanks, 
Ian Maddison

---

From: John C Klensin <[email-masked]>
Date: Thu, 23 Jul 2015 07:29:51 -0400

--On Monday, July 20, 2015 13:50 -0400 Bob Harold
<[email-masked]> wrote:

> This thread has taught me more about the .onion names - thanks
> for that. But I would have to agree with those that think this
> bit of explanation is unnecessary to the RFC and should be
> excluded, rather than attempting to clarify it.  The RFC only
> needs to deal with ".onion".  No need to explain the other
> parts of the name.

FWIW, I tend to agree.  If the purpose of the document is to try
to lock down the name, it should explain what ONION. is and how
it is deployed to the extent needed to justify that and
incorporate explanations of how the hierarchical structure is
used and accessed, as well as the nature of the protocol itself,
by reference if at all.    If the intent is to incorporate
and/or explain the latter, how TOR works, etc., that is a rather
different sort of document.  The latter might still try to
reserve the top-level name as an "IANA Considerations" effect,
but is one over which the IETF would typically want change
control as a condition for IETF Stream publication.

    john

---

From: David Cake <[email-masked]>
Date: Tue, 28 Jul 2015 00:53:02 +0930

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

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