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

From: George Michaelson <[email-masked]>
Date: Tue, 14 Jul 2015 21:47:43 +0200

I have no substantive technical reason to oppose, and I think the request
is probably well-formed against the RFC which documents how and when to
request this class of delegation.

But we do not exist in a vacuum and I think the combination of 'because we
coded it that way'  and 'we want it' are really very poor reasons to enact
the special-use domain name request.

I think this is a politically naive request, and enacts a poor architecture
of name to locator models, and misunderstands both the nature of domain
names in general, the DNS specifically, and the role of the omnibox and URL
bar in a modern browser, which inexorably relates to calls to
gethostbyname() on the contents of a URL.

I think it would be a mistake to proceed with .Onion, and I think the IESG
would be well advised to re-consider the special use names documents,
because they are a poor fit for the modern world.

I do not expect to post again on this. Since my reasoning is essentially
non-technical many would chose to ignore it, and since the rest of it is
political and weakly argued, many would chose to ignore it on those grounds
too.

But its what I think.

I think .Onion is a huge mistake.

-G

On Tue, Jul 14, 2015 at 9:24 PM, The IESG <[email-masked]> wrote:

>
> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document:
> - 'The .onion Special-Use Domain Name'
>   <draft-ietf-dnsop-onion-tld-00.txt> as Proposed Standard
>
> 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 Lemon <[email-masked]>
Date: Tue, 14 Jul 2015 13:08:57 -0700

This is clearly needed.   There are serious technical, privacy and 
personal safety costs to saying no to this, which supersede any supposed 
layer 9 considerations.   Given that the working group already discussed 
the layer 9 issues and had consensus to publish this document, I think 
it would be unfortunate and inappropriate to re-try all of the same 
issues again on the IETF mailing list.   If working group participants 
feel that the consensus call was made in error, they should appeal the 
consensus call using the IETF appeals process, rather than re-arguing 
the same points on the IETF mailing list.

I say this with utmost respect and appreciation for the DNSOP working 
group participant who has attempted to begin such an argument already.   :)

---

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: George Michaelson <[email-masked]>
Date: Tue, 14 Jul 2015 22:20:15 +0200

No, I won't appeal. No implied appeal pending from me.

I don't believe I have grounds to appeal, and I don't believe an appeal
would be allowed on what are essentially political motivations. What others
will chose to do I cannot say because I am not part of any other discussion
on this: its my personal view, and my personal view alone.

I believe the IETF can decide to do this 'eyes wide open' -I just don't
believe it SHOULD, but it obviously CAN.

I believe the inherent risks to TOR users should be solved by the TOR
coders. dependencies on the DNS will remain even after this registration,
because the beams have inexorably been crossed. There is no going back from
what the omnibox does. So I believe the risks to the TOR users will
perpetuate even after this documented action.

My personal view only.

-G

On Tue, Jul 14, 2015 at 10:08 PM, Ted Lemon <[email-masked]> wrote:

> the layer 9 issues and had consensus to publish this document, I think it
> would be unfortunate and inappropriate to re-try all of the same issues
> again on the IETF mailing list.   If working group participants feel that
> the consensus call was made in error, they should appeal the consensus call
> using the IETF appeals process, rather than re-arguing the same points on
> the IETF mailing list.
>

---

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

On Tue, Jul 14, 2015 at 1:08 PM, Ted Lemon <[email-masked]> wrote:

>  Given that the working group already discussed the layer 9 issues and had
> consensus to publish this document, I think it would be unfortunate and
> inappropriate to re-try all of the same issues again on the IETF mailing
> list.

​Given that the point of IETF Last Call is to determine if there is IETF
consensus on the working group's analysis and proposal, I find
"inappropriate" an odd choice of words here.  The IETF as a whole may have
a different sense of the trade-offs here.​

 If working group participants feel that the consensus call was made in
> error, they should appeal the consensus call using the IETF appeals
> process, rather than re-arguing the same points on the IETF mailing list.
>
​I have a great deal of respect for the folks in DNSOP, and a similar
amount for those who created and TOR.  But I believe that this approach to
segmenting the namespace for protocol resolution does not scale well.  I
would far prefer a notation that onion addresses can appear in the
authority section of URIs without them being DNS names, something that RFC
3986 allows with the registered name syntax.

Your mileage may vary,

regards,

Ted

---

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

On Tue, Jul 14, 2015 at 09:47:43PM +0200,
 George Michaelson <[email-masked]> wrote 
 a message of 136 lines which said:

> I think this is a politically naive request, and enacts a poor
> architecture of name to locator models, and misunderstands both the
> nature of domain names in general, the DNS specifically, and the
> role of the omnibox and URL bar in a modern browser, which
> inexorably relates to calls to gethostbyname() on the contents of a
> URL.

I would love to see a more detailed analysis of the nature of DNS but,
in the mean time:

> I think it would be a mistake to proceed with .Onion, and I think
> the IESG would be well advised to re-consider the special use names
> documents, because they are a poor fit for the modern world.

The "special use names document", RFC 6761, has already been used (for
.local) and nobody objected at this time. 

> since the rest of it is political and weakly argued, many would
> chose to ignore it

No, there are practical reasons to "register" .onion:

* the forum of X.509 CAs decided to stop issuing certs for names
"unregistered" so if onion sites want to use HTTPS, they need some
form of recognition,

* the special handling by software (section 2 of the I-D) will help to
prevent leaks in the DNS (which are bad for privacy).

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Jul 2015 13:53:03 -0700

On 07/14/2015 01:28 PM, Ted Hardie wrote:
> ​Given that the point of IETF Last Call is to determine if there is 
> IETF consensus on the working group's analysis and proposal, I find 
> "inappropriate" an odd choice of words here.  The IETF as a whole may 
> have a different sense of the trade-offs here.​
It's certainly appropriate for people who aren't DNSOP participants to 
weigh in here, and for DNSOP participants to raise new issues that the 
working group missed.   But it seems bogus to me for DNSOP participants 
to raise the same issue here that they raised in DNSOP and that didn't 
get consensus.   I  believe you are a DNSOP participant, but perhaps I 
am mistaken.   I think you and at least one other person read my comment 
as saying that once the working group has consensus, that's the end of 
it, but that wasn't my point.   My point is simply that it would be 
useless and harmful to the IETF for DNSOP participants to waste the 
collective attention of the IETF re-arguing points that already got 
consensus in DNSOP. This is a perennial problem in the IETF.   Of 
course, now we will have a long argument about the appropriateness of my 
interjection here instead, but I'm not convinced that that's worse.

> amount for those who created and TOR.  But I believe that this 
> approach to segmenting the namespace for protocol resolution does not 
> scale well.  I would far prefer a notation that onion addresses can 
> appear in the authority section of URIs without them being DNS names, 
> something that RFC 3986 allows with the registered name syntax.
I don't see how that helps: if they can appear in URIs, then we still 
need to mark that special-use TLD as in use.

---

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: Ted Hardie <[email-masked]>
Date: Tue, 14 Jul 2015 14:24:45 -0700

On Tue, Jul 14, 2015 at 1:53 PM, Ted Lemon <[email-masked]> wrote:

> working group missed.   But it seems bogus to me for DNSOP participants to
> raise the same issue here that they raised in DNSOP and that didn't get
> consensus.   I  believe you are a DNSOP participant,

​Not generally, no.  I have commented on specific issues in the past, but I
certainly did not on this issue.​

> but perhaps I am mistaken.   I think you and at least one other person
> read my comment as saying that once the working group has consensus, that's
> the end of it, but that wasn't my point.   My point is simply that it would
> be useless and harmful to the IETF for DNSOP participants to waste the
> consensus in DNSOP.

​I think George's post, assuming he is a DNSOP participant, was along the
lines "In the working group, I am in the rough, and I am not appealing
that.  Here, however, is my reasoning so that the broader IETF understands
it".

If we didn't allow that, we would never allow positions that were discussed
in the working group to be aired on the IETF list, which requires
non-participants to discover them independently.  While that would be a
great signal when it happened, I think saying only the consensus position
should be represented to the IETF is wrong.  It just should not claim to be
either un-addressed by the working group if has been or to be the consensus
when it is not.​

> This is a perennial problem in the IETF.   Of course, now we will have a
> long argument about the appropriateness of my interjection here instead,
> but I'm not convinced that that's worse.
>
> I don't see how that helps: if they can appear in URIs, then we still need
> to mark that special-use TLD as in use.
>
>
​Not necessarily; if you minted a URI scheme for them, you could use
something like the overlay-node-id​
<https://www.ietf.org/archive/id/draft-hardie-p2psip-p2p-pointers-01.txt>
 proposal​ (forgive me for posting an expired draft that I authored, but
it's the quickest example for me to find).   I'm not arguing for that,
though; I'm saying that using the TLD slot for protocol processing
instructions scales badly and we should not do it.

Stephane argues that we did once, with .local, and the die is thus cast,
but I don't think that was the Rubicon, and I know we are not Caesar.

Ted

---

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

>of the handler to understand it. ...

Right, that's why it's a special use name.  As others have noted, one
reason to regisiter it as special use is to deter hijacking if the
names leak into the real DNS.  The other is for bureaucratic reasons
related to SSL CAs.  Those seem reasonably compelling to me.

We had a long discussion about the perverse incentives that this might
create for other people to invent other names.  Yes, they might, but
this is engineering rather than art, and we need to deal with things
as they are, not as we might prefer they should have been.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Jul 2015 15:48:55 -0700

So having just said that we should avoid re-visiting the long layer 9 
discussion that occurred on dnsop, I do actually have a technical 
concern about the document that was just pointed out to me by a 
co-worker, and that was not actually discussed by the working group 
(although David Conrad did make a related suggestion).   There is text 
in the document that says this:

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

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

    6.  DNS Server Operators: Operators MUST NOT configure an
        authoritative DNS server to answer queries for .onion.  If they
        do so, client software is likely to ignore any results (see
        above).

    7.  DNS Registries/Registrars: Registrars MUST NOT register .onion
        names; all such requests MUST be denied.

The problem with this text is that it doesn't quite do what I think we 
want. What we want is for a device that (incorrectly!) does a query on a 
.onion name to get an NXDOMAIN.   If it does a DNSSEC query, we want it 
to be able to validate the NXDOMAIN.   I think that this is what we 
intended, but this text doesn't actually accomplish that.   What this 
text _does_ accomplish, which is also really important, is that it 
prevents queries from being sent, complete, all the way up to the root.

I think that we want to ask for the following:

1. The root is set up to return NXDOMAIN with authenticated denial of 
existence.
2. Authoritative DNS servers should refuse to respond to these queries 
if they aren't authoritative.  I don't think this needs to be said; if 
the server is authoritative for the root, it will respond with NXDOMAIN 
because the domain doesn't exist; if it's not authoritative for root, on 
what basis could it answer?
3. DNS caching servers should pre-load their cache with the NSEC records 
required to securely deny existence of .onion.
4. Operators should make sure their caching servers are set up this way.

I think all the SHOULDs and MUSTs are inappropriate.   We don't have the 
authority to tell the root operator what to put in the root zone, so 
this should say what we want, not say what the operator should do.   And 
these are things that DNS servers ought to do, but I don't think there 
is a protocol issue here, and I don't think we can do more than 
encourage people to do the right thing here.   In practice, what most 
protects end users is correct implementation on the host; once the query 
leaves the host the user's privacy has been violated; all that is left 
is to try to mitigate the thoroughness with which it has been violated.

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Jul 2015 17:21:24 -0700

> the special-use domain name request.

i support the request, but not for the social and process reasons being
raised.

the onion. dns space is outside of the normal dns space we all use.  if
someone were to be allowed to register foo.onion. as a child of the iana
root, it could be used as an attack on the person clicking the link,
taking them to a malicious site as opposed to the tor site.  not good.

while the document may be more process and political than security, to
me it is all about security, the safety of the user clicking an
onion. fqdn when not using a tor browser.

i return you to all the process issues.  do we already miss the dui
discussion? :)

randy

---

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: "Patrik Fältström" <[email-masked]>
Date: Wed, 15 Jul 2015 09:00:48 +0200

On 14 Jul 2015, at 21:47, George Michaelson wrote:

> But we do not exist in a vacuum and I think the combination of 'because we coded it that way'  and 'we want it' are really very poor reasons to enact the special-use domain name request.

Unfortunately that train left the station with .LOCAL.

What IETF might need is a stopping function for approval of usage of the domain name namespace outside of the DNS.

   Patrik

---

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:

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

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: John C Klensin <[email-masked]>
Date: Wed, 15 Jul 2015 11:33:39 -0400

--On Wednesday, July 15, 2015 09:00 +0200 Patrik Fältström
<[email-masked]> wrote:

>> But we do not exist in a vacuum and I think the combination
>> of 'because we coded it that way'  and 'we want it' are
>> really very poor reasons to enact the special-use domain name
>> request.
> 

Patrik, I don't think so.  While I would have preferred to see
even the formalization of LOCAL. handled in a different way,
ideally including recommendations to ICANN from SSAC about names
restricted up-front in the gTLD allocation/delegation process, I
believe LOCAL. has been widely deployed and used for a _very_
long time, almost certainly pre-ICANN.  The special name
"localhost." has probably been in use even longer.  I am less
sure about, e.g., "invalid." and "test." but, while one might
question why the IETF has fallen victim to the "try to put
things in the root" syndrome rather than using hierarchy, they
are clearly in the spirit of "example."   At least for local.
and localhost., putting the strings into the Special Names
registry may act as a helpful warning to the naive that
expecting to use the names on the public Internet as ordinary
TLDs would be really stupid, but I don't think that registration
changes a thing for any reasonably savvy DNS operation.

In that sense, "this name should be reserved or allocated at the
top level because some application needs it" really is now, the
associated train is still in the station, and we now face a
decision about whether to let it out and, if we do, where the
new boundaries are.

> What IETF might need is a stopping function for approval of
> usage of the domain name namespace outside of the DNS.

I think the intent was that the specifications and
considerations in RFC 6761 established precisely such a stopping
rule.  If this "onion." proposal (and/or the other special-use
names proposals I've seen floating around) demonstrate to the
community that 6761 is not adequate, then perhaps we should put
those proposals for new special-use names on hold and go back
and review 6761 to see if the evaluation criteria need
improvement.

Personal opinion (and maybe a hint about something that may need
examination about the way 6761 is being interpreted): If someone
came to the IETF with a new piece of protocol that needed a
reserved domain name and asked for a root-level name, I assume
they would get a lot of pushback suggesting that they use a
ARPA. subtree or some commercially-available subdomain instead.
I'd hope the IETF would listen carefully to arguments about why
a TLD was really needed, but, assuming we still believe in the
distributed hierarchy model that underlies the DNS, I'd assume
that the default would be "no" and a persuasive case for a
root-level name would be very hard to make.  The difference
between that scenario and some of the special names proposals
that now seem to be floating around is that, rather than
engaging with the IETF when the protocols were being designed,
the community involved decided to pick a TLD-style name, squat
on it, deploy, and then come to the IETF looking for help in
obtaining formal rights to the previously-squatted name.  It
does not seem to be to be in the best interests of either IETF
or the Internet for us to encourage that type of sequence of
events.  

best,
    john

---

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

On 15 Jul 2015, at 17:33, John C Klensin wrote:

> Patrik, I don't think so.  While I would have preferred to see even the formalization of LOCAL. handled in a different way, ideally including recommendations to ICANN from SSAC about names restricted up-front in the gTLD allocation/delegation process, I believe LOCAL. has been widely deployed and used for a _very_
> "localhost." has probably been in use even longer.

There are many shades of gray ;-)

But, I understand your view...

> I am less sure about, e.g., "invalid." and "test." but, while one might question why the IETF has fallen victim to the "try to put
> things in the root" syndrome rather than using hierarchy, they are clearly in the spirit of "example."   At least for local.
> expecting to use the names on the public Internet as ordinary TLDs would be really stupid, but I don't think that registration changes a thing for any reasonably savvy DNS operation.

Well, I hope that adding names to the special names registry will result in the names be on the "forbidden" list of potential new round of TLDs ICANN might launch. All up to the result of the PDP run by ICANN of course.

> In that sense, "this name should be reserved or allocated at the top level because some application needs it" really is now, the associated train is still in the station, and we now face a
> decision about whether to let it out and, if we do, where the new boundaries are.

To me we talk about whether the string (and by that, that branch of the namespace) is to be used in the root of the domain name system or not.

And then the specification is to be sound, and pass the consensus process IETF decides what it should be.

Yes, you are absolutely right that IETF must make up its mind on what the actual process is, but for me that is a smaller issue than the fact special names CAN be added, and by adding them they will NOT be resolvable globally using the DNS and the root ICANN manages.

I know some people say that opens the door for someone to request strings in IETF and create a denial of service attack against the "approval process" ICANN runs, but, I trust IETF to do the right thing.

Ok, now the question is whether .ONION has passed the bar regarding for example deployment etc, and I think it has. Yes, more limited deployment than .LOCAL but definitely deployment, and, if I understand things correctly, multiple independent implementations and deployments.

> considerations in RFC 6761 established precisely such a stopping rule.  If this "onion." proposal (and/or the other special-use names proposals I've seen floating around) demonstrate to the community that 6761 is not adequate, then perhaps we should put those proposals for new special-use names on hold and go back and review 6761 to see if the evaluation criteria need
> improvement.

Agree.

> Personal opinion (and maybe a hint about something that may need examination about the way 6761 is being interpreted): If someone came to the IETF with a new piece of protocol that needed a
> reserved domain name and asked for a root-level name, I assume they would get a lot of pushback suggesting that they use a

Note what I wrote above, that IETF special name registry is NOT for things that goes as a TLD in the root zone. The contrary. So IETF can not this way allocate a TLD in the root zone, which I interpret your text above implying.

If you here talk about allocation of a branch of the namespace, the question is whether bullet 1 in section 2 is strong enough:

  1.  Users: human users are expected to recognize .onion names as
      having different security properties, and also being only
      available through software that is aware of onion addresses.

I guess this goes back to discussions similar to whether one should have URI:HTTP:// or just HTTP:// and we all remember those discussions...

> I'd hope the IETF would listen carefully to arguments about why a TLD was really needed, but, assuming we still believe in the distributed hierarchy model that underlies the DNS, I'd assume that the default would be "no" and a persuasive case for a
> root-level name would be very hard to make.

Fair.

> The difference
> between that scenario and some of the special names proposals that now seem to be floating around is that, rather than
> engaging with the IETF when the protocols were being designed, the community involved decided to pick a TLD-style name, squat on it, deploy, and then come to the IETF looking for help in obtaining formal rights to the previously-squatted name.  It does not seem to be to be in the best interests of either IETF or the Internet for us to encourage that type of sequence of events.

True, but if we look at the chat protocols, IETF could not agree on which one of three different protocols should move forward. Then XMPP came and, well, was developed elsewhere and basically "won".

We now have HTTP/2 which some people do believe could have been done multiple years ago based on BEEP, which is a very good protocol at least academically/theoretically...but how is it going with it?

Anyway...

I am just saying that having ideas actually be cooked inside IETF is not easy...and have not been easy for many years. So just the fact an idea is brought to the IETF when being deployed can not by itself be a reasoning for saying no.

That said, I completely understand what you write (I hope!), and you are right that in there are questions.

Will we be able to find just objective rules for saying yes or no? I don't think so...unfortunately.

   Patrik

---

From: Ted Hardie <[email-masked]>
Date: Wed, 15 Jul 2015 09:56:27 -0700

Howdy,

On Wed, Jul 15, 2015 at 9:18 AM, Patrik Fältström <[email-masked]> wrote:

> ​This point seems to have consensus :-).​

>
> Well, I hope that adding names to the special names registry will result
> in the names be on the "forbidden" list of potential new round of TLDs
> ICANN might launch. All up to the result of the PDP run by ICANN of course.
>
>
​From this point of view the special names registry is actually a registry
of "labels forbidden to the DNS​ in a specific slot".  But my view of the
reasoning is that for test, invalid, and example "special processing" means
"no processing, this isn't real".  RFC 6762 wasn't "no processing" but
instead "no processing in global DNS, process locally using mDNS instead."
That confirmed that the IETF would be willing to register labels forbidden
to the DNS in a specific slot because it was otherwise resolved, rather
than simply unresolvable.  And now we have the next such request, which
once again relies on an installed based to claim necessity.

>From an architectural perspective (but still wearing my hat as an
individual), this method for partitioning the namespace has a very poor
long-term characteristics.  If we permitted it generally, we would be
sanctioning a system in which there is a single root + some local knowledge
required for name resolution.  That local knowledge will be at some unknown
state for the vast majority of devices and implementations for a long time
(predict for me, if you like,  the date the last query for .onion will hit
the root, and I'll buy you a donut if it occurs within a year of your
guess) and if the local knowledge required expands over time, essentially
forever.  That's bad, and pretty much needless, as there are lots of other
ways to partition the namespace.  pseudo-TLDs are not required; they look
convenient because they hide the costs.

> I know some people say that opens the door for someone to request strings
> in IETF and create a denial of service attack against the "approval
> process" ICANN runs, but, I trust IETF to do the right thing.
>
>
​I think this is the wrong ​analysis of the risk.  If someone seeing the
acceptance for .local and .onion decides they want some other resolution
mechanism and creates .npr for their novel process for resolution, it will
work for those clients updated with local knowledge.  When the journalistic
outfit "NPR" comes calling at ICANN and gets a name in the root, that
community may not even know its going on.  But afterwards,
we will have local knowledge conflict with the root with ordering of
resolution steps deciding what happens.  That's fragile for everyone, not
least the people now running the gTLD .npr

We saw this with squatting in the url scheme space (surely you remember the
fun with mms?).  Either the process of registering local partitions of the
global namespace has to be so easy that they get registered very early, or
we have to avoid this style and establish other methods of signalling
alternate resolution in application slots.

The latter at least *might* scale.  This does not.

regards,

Ted

>
> Ok, now the question is whether .ONION has passed the bar regarding for
> example deployment etc, and I think it has. Yes, more limited deployment
> than .LOCAL but definitely deployment, and, if I understand things
> correctly, multiple independent implementations and deployments.
>
> > considerations in RFC 6761 established precisely such a stopping rule.
> If this "onion." proposal (and/or the other special-use names proposals
> I've seen floating around) demonstrate to the community that 6761 is not
> adequate, then perhaps we should put those proposals for new special-use
> names on hold and go back and review 6761 to see if the evaluation criteria
> need
> > improvement.
>
> Agree.
>
> examination about the way 6761 is being interpreted): If someone came to
> the IETF with a new piece of protocol that needed a
> > reserved domain name and asked for a root-level name, I assume they
> would get a lot of pushback suggesting that they use a
> Note what I wrote above, that IETF special name registry is NOT for things
> that goes as a TLD in the root zone. The contrary. So IETF can not this way
> allocate a TLD in the root zone, which I interpret your text above implying.
>
> If you here talk about allocation of a branch of the namespace, the
> question is whether bullet 1 in section 2 is strong enough:
>
> I guess this goes back to discussions similar to whether one should have
> URI:HTTP:// or just HTTP:// and we all remember those discussions...
>
> > I'd hope the IETF would listen carefully to arguments about why a TLD
> was really needed, but, assuming we still believe in the distributed
> hierarchy model that underlies the DNS, I'd assume that the default would
> be "no" and a persuasive case for a
> > between that scenario and some of the special names proposals that now
> seem to be floating around is that, rather than
> > engaging with the IETF when the protocols were being designed, the
> community involved decided to pick a TLD-style name, squat on it, deploy,
> and then come to the IETF looking for help in obtaining formal rights to
> the previously-squatted name.  It does not seem to be to be in the best
> interests of either IETF or the Internet for us to encourage that type of
> sequence of events.
>
> True, but if we look at the chat protocols, IETF could not agree on which
> one of three different protocols should move forward. Then XMPP came and,
> well, was developed elsewhere and basically "won".
>
> We now have HTTP/2 which some people do believe could have been done
> multiple years ago based on BEEP, which is a very good protocol at least
> academically/theoretically...but how is it going with it?
>
> Anyway...
>
> I am just saying that having ideas actually be cooked inside IETF is not
> easy...and have not been easy for many years. So just the fact an idea is
> brought to the IETF when being deployed can not by itself be a reasoning
> for saying no.
>

---

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

On 15 Jul 2015, at 18:56, Ted Hardie wrote:

> ​I think this is the wrong ​analysis of the risk.  If someone seeing the acceptance for .local and .onion decides they want some other resolution mechanism and creates .npr for their novel process for resolution, it will work for those clients updated with local knowledge.  When the journalistic outfit "NPR" comes calling at ICANN and gets a name in the root, that community may not even know its going on.  But afterwards, 
> we will have local knowledge conflict with the root with ordering of resolution steps deciding what happens.  That's fragile for everyone, not least the people now running the gTLD .npr

To some degree we will always have "first come first serve".

This is why IETF for the .npr that is not DNS related should be registered by IETF so that ICANN do know that adding that as a TLD would be a bad idea.

> We saw this with squatting in the url scheme space (surely you remember the fun with mms?).  Either the process of registering local partitions of the global namespace has to be so easy that they get registered very early, or we have to avoid this style and establish other methods of signalling alternate resolution in application slots.

Correct.

And this is why I think a lower barrier of entry in the special names registry (and because of that blocking those names in the global DNS) is better than a higher barrier of entry.

But I absolutely understand others have a different view.

   Patrik

---

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

On 07/15/2015 05:42 AM, Edward Lewis wrote:
> 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.

No, it's not independent, because .onion sites won't be able to get PKI 
certs if we don't do the allocation.
> 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.
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.

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

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 Hardie <[email-masked]>
Date: Wed, 15 Jul 2015 10:17:16 -0700

On Tue, Jul 14, 2015 at 3:48 PM, Ted Lemon <[email-masked]> wrote:

> 2. Authoritative DNS servers should refuse to respond to these queries if
> they aren't authoritative.  I don't think this needs to be said; if the
> server is authoritative for the root, it will respond with NXDOMAIN because
> the domain doesn't exist; if it's not authoritative for root, on what basis
> could it answer?
> authority to tell the root operator what to put in the root zone, so this
> should say what we want, not say what the operator should do.
>

​I think this is valid way of making sure that an application doesn't have
to rely on local knowledge to know whether something is or is not in the
Global DNS root, but I note that another way of looking at it is as a gTLD
applicant asking for a slot,  specifying only NSEC records for the NXDOMAIN
related to the proposed slot.  Could, for example, the Catholic church ask
for .pope and follow exactly the same procedure, so that strings with .pope
could never be used in the root?  (Yes, I am aware there are other possible
ways of making that point, but this one is pretty effective).

​But I think the possibility of other reasons for this highlights the point
Ted Lemon was making:  to make this work correctly is actually more in the
bailiwick of the root operators than ours.  I think that means we should
tread more carefully than the trend lines appear to be.​

​regards,

Ted Hardie​

> And these are things that DNS servers ought to do, but I don't think there
> is a protocol issue here, and I don't think we can do more than encourage
> people to do the right thing here.   In practice, what most protects end
> users is correct implementation on the host; once the query leaves the host
> the user's privacy has been violated; all that is left is to try to
> mitigate the thoroughness with which it has been violated.
>
>

---

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

On 07/15/2015 10:17 AM, Ted Hardie wrote:
> ​But I think the possibility of other reasons for this highlights the 
> point Ted Lemon was making:  to make this work correctly is actually 
> more in the bailiwick of the root operators than ours.  I think that 
> means we should tread more carefully than the trend lines appear to be.​
I think "tread carefully" is the wrong way to think about it.   We 
understand who has change control for the root zone, and it is not us.   
We also have RFC 6761, which establishes a process for things that look 
like they belong in the root zone, but are to be reserved for special 
uses.   I have not heard any pushback from ICANN about 6761, and we did 
ask them about it.   They are in fact aware of the use of .onion, and as 
I understand it have no intention of allocating it.   So there is no 
conflict here, and hence no need to tread carefully.

So what I would say instead of "tread carefully" is "understand what 
role we have."   The role we have is to communicate with ICANN about 
this, and come to an agreement about what should happen.   This document 
is us saying what we think should happen.   In a sense it is only part 
of the conversation, although in practice I think the rest of the 
conversation will be fairly simple, because I am fairly certain that 
there is no disagreement between IETF and ICANN about what to do.

---

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

On 07/15/2015 11:04 AM, Edward Lewis wrote:
> That "Ted".
Yup, Ted pointed that out to me privately--sorry.   :)
> 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.
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: John C Klensin <[email-masked]>
Date: Wed, 15 Jul 2015 15:13:35 -0400

--On Wednesday, July 15, 2015 09:56 -0700 Ted Hardie
<[email-masked]> wrote:

>...
> ​From this point of view the special names registry is
> actually a registry of "labels forbidden to the DNS​ in a
> specific slot".  But my view of the reasoning is that for
> test, invalid, and example "special processing" means "no
> processing, this isn't real".  RFC 6762 wasn't "no processing"
> but instead "no processing in global DNS, process locally
> using mDNS instead." That confirmed that the IETF would be
> willing to register labels forbidden to the DNS in a specific
> slot because it was otherwise resolved, rather than simply
> unresolvable.  And now we have the next such request, which
> individual), this method for partitioning the namespace has a
> very poor long-term characteristics.  If we permitted it
> generally, we would be sanctioning a system in which there is
> a single root + some local knowledge required for name
> resolution.  That local knowledge will be at some unknown
> state for the vast majority of devices and implementations for
> a long time (predict for me, if you like,  the date the last
> query for .onion will hit the root, and I'll buy you a donut
> if it occurs within a year of your guess) and if the local
> knowledge required expands over time, essentially forever.
> That's bad, and pretty much needless, as there are lots of
> other ways to partition the namespace.  pseudo-TLDs are not
> required; they look convenient because they hide the costs.
>...

I think this is the right analysis.  I also note that, while
"npr." might not be the best example, it that scenario unfolded,
NPR might have grounds to complain that the IETF's actions
interfered with their use of the ICANN-assigned public root TLD
and hence with their exercise of trademarks, etc. 

Your note motivated a thought experiment.  I don't expect most
people to take this seriously as a suggestion, but thinking
about it a bit might prove helpful.   If the goal is to identify
labels that can be used with the DNS or DNS-like mechanisms but
are not expected or allowed to be allocated in the public root,
we've got a rather good technical mechanism that has _exactly_
that property and that will create names that ICANN will never
consider allocating, at least under its current charter.
Ignoring both special names that that have been in very long
term and popular use (all of which I hope are now in the
registry) and strings associated with squatting as a strategy
for the moment, suppose we decided that all new special names
associated with protocols and intended for special resolution
mechanisms be allocated (and placeholders delegated if needed)
in a separate DNS CLASS, say "SN" for "Special Name".  Zero
impact on the ICANN/IANA root from queries gone bad, no conflict
with names ICANN allocates even if the labels are the same
(remember that QCLASS=ANY has never worked), etc.  It would be
about the clearest signal of the need to do local resolution
possible and it would be name-independent.    If the local folks
use non-DNS resolution mechanisms, it doesn't make any
difference what CLASS the name is in.   If they (deliberately or
accidentally) try to resolve them using the public DNS, they
either need to point to some root structure (other than that for
CLASS=IN) or they get a massive fail.

I can think of several reasons why that might not be practical,
but I believe that thinking through those issues might help to
illuminate the present set of issues.

best,
    john

---

From: Ted Hardie <[email-masked]>
Date: Wed, 15 Jul 2015 12:40:08 -0700

Howdy,

> CLASS=IN) or they get a massive fail.
​I went through the same experiment, and I even considered how to adapt a
long-ago dropped proposal for cross-class pointers​
<https://www.ietf.org/archive/id/draft-hardie-out-rr-00.txt>​to adapt Ted
Lemon's NSEC method (essentially, using DNSSEC to secure the cross-class
pointer record instead of the NXDOMAIN).  I think it could work, but as you
say, there are a lot of potential issues with making this deployable.
There are a *lot* of things (and organizations) that presume IN is the only
class, and it's not clear that they would go along.  If CABrowser Forum did
not, for example, much of the reason the .onion folks want a DNS special
name would not work.

regards,

Ted

---

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

On 07/15/2015 11:46 AM, Edward Lewis wrote:
> 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?
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: John C Klensin <[email-masked]>
Date: Wed, 15 Jul 2015 16:49:36 -0400

--On Wednesday, July 15, 2015 12:40 -0700 Ted Hardie
<[email-masked]> wrote:

>> suppose we decided that all new special names
>> impact on the ICANN/IANA root from queries gone bad, no
>> conflict with names ICANN allocates even if the labels are
>...

> ​I went through the same experiment, and I even considered
> how to adapt a long-ago dropped proposal for cross-class
> pointers​
> <https://www.ietf.org/archive/id/draft-hardie-out-rr-00.txt>‍
> 
> to adapt Ted Lemon's NSEC method (essentially, using DNSSEC
> to secure the cross-class pointer record instead of the
> NXDOMAIN).  I think it could work, but as you say, there are a
> lot of potential issues with making this deployable. There are
> a *lot* of things (and organizations) that presume IN is the
> only class, and it's not clear that they would go along.  If
> CABrowser Forum did not, for example, much of the reason the
> .onion folks want a DNS special name would not work.

Yep.  Glad you are ahead of me and that our exploration went
down approximately the same path.  

Keeping in mind that I've far more concerned about where we go
next and what the boundaries and criteria are than about any one
name, part of my thought was to be able to say to the next
applicant who comes along 

"We can give you, the applicant, four options, two easy and two
harder:

 (i) CLASS=IN, but a subdomain below something (I'll
	leave whether the current 'ALT.' proposal is the right
	'something', or whether even something analogous to it
	should be 'ALT.ARPA.', for a separate discussion).
	
 (ii) CLASS=SP, top-level domain.
	
 (iii) CLASS=IN and a TLD, but with _really_ high
	threshold for justifying that choice.

 (iv) Go do whatever ICANN specifies for a TLD that you
	don't intend to resolve in the normal/public DNS.  To
	the best of my knowledge, there is no such procedure
	today.  ICANN could create one, in which case how it
	works is not an IETF problem.  Or they could decline to
	do so, in which case this option is a no-op.  That isn't
	an IETF problem either."

For options (i) or (ii) the IETF probably wouldn't want quite
FCFS, but an Expert Review/ Sanity Check would probably be
sufficient.  Either one requires that people either come to us
when the protocol is designed so an appropriate DNS setup can be
chosen or negotiated.  If things are already deployed, the
question would become whether it is easier to upgrade relevant
applications or to be pushed over into one of the other
options... but that is not an IETF problem.

For (iii), I don't know that we always say "no", but, if only
because such reservations either interact with ICANN gTLD
application procedures or create the kinds of operational and/or
security risks that several people have identified, we would
presumably need to understand why some other option wasn't
appropriate, what was proposed to mitigate the risks, some
review or policy model that was hostile to squatting strategies,
and lots of deployment (although presumably not up to the level
of "localhost."

Again, I don't know whether that model should be applied to
"onion." or not.  Part of the answer obviously depends on
whether there is a "good and virtuous cause" exemption because
concerns about squatting, etc., obviously arise even though any
reasonable minimum deployment criteria are almost certainly met.
I think part of the answer to those questions require that the
IETF explore how far it is willing to go in support of
sociopolitical and/or privacy concerns and where the stopping
points are in that direction.  However, if the model did apply
to "onion.", presumably part of the answer would be to tell the
applicants/registrants that the job of convincing the CABrowser
Forum or other implementers to do whatever is needed is their
problem, not ours.

best,
    john

---

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.

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

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: 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: 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'.)

---

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

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: 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: "Joe Hildebrand" <[email-masked]>
Date: Thu, 16 Jul 2015 01:40:36 +0300

On 15 Jul 2015, at 19:18, Patrik Fältström wrote:

> True, but if we look at the chat protocols, IETF could not agree on 
> which one of three different protocols should move forward. Then XMPP 
> came and, well, was developed elsewhere and basically "won".

I do want to point out that we ceded change control over XMPP to the 
IETF, and the XMPP working group made some fundamental changes to the 
protocol, including start-TLS, stringprep, SASL, a new error name 
scheme, version numbering, etc.

A similar approach was used for SPDY morphing into HTTP/2.

I don't see any way that these protocol development efforts can be used 
as precedent for this draft.  If the TOR folks wanted to go through the 
process to standardize their protocols, we could think about the 
architecture we wanted for their identifiers and think about ways to 
avoid a special-use name.

In the meantime, I have a specific technical objection to this draft, 
section 2:

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

I'm skeptical that this SHOULD NOT will have any effect on any 
application other than some small number of popular web browsers. There 
are a LOT of non-web-browser applications in the world that do DNS 
lookups, and almost none of them will ever find out that they are 
leaking information because of this SHOULD NOT.

As such, I suggest that this doc does not provide an adequate technical 
or market-based mechanism that will achieve its stated goal.

-- 
Joe Hildebrand

---

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: "John Levine" <[email-masked]>
Date: 15 Jul 2015 22:59:44 -0000

>and hence with their exercise of trademarks, etc. 

Now we're deep into anyone can sue anyone for anything territory.  A
quick look at the USPTO database finds registrations for "NPR" from
both National Public Radio and Nippon Piston Rings (really.) The
public radio trademark for the three letters, as opposed to the logo,
was only filed last October and is still in the challenge period,
while the piston ring acronym was filed in 2006, so the latter
trademark is considerably senior.  Who knows who'd win a fight about
.NPR?  It's lucky we're not going to find out.

But as I keep saying, we're engineers. and part of engineering is
dealing with the real rather than the ideal.

I entirely agree that we should discourage people from inventing new
naming schemes that borrow top level names in the DNS.  Life would be
easier all around if they put them under .ARPA or .ALT or made them
not look like domain names.  But since we are not the Network Police,
people will do whatever they do, and we as engineers need to make it
work as best we can.

So if some maniac invented a new application that used .COCA-COLA
outside the DNS, and we found that millions of other maniacs around
the world were using it, our job as engineers is to make things work,
which would likely involve saying that .COCA-COLA can't be in the DNS.
It's not hard to imagine some people who'd be dismayed at that, but I
don't see that as our problem.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Thu, 16 Jul 2015 09:23:06 +1000

Also what I haven't seen explored but is actually a logical extension
of using socks to make ordinary browsers talk to .onion sites is
extending the local recursive server to do the TOR lookup rather
than a traditional DNS lookup and return the results in a DNS
message.  With dprive this should end up being secure.

If there will ever be a requirement to support this then doing a
insecure delegation to a set of public .onion servers would be the
way to go.  The logical set of servers is the root-servers to avoid
additional leakage.

There are a number of places where a .onion name can be intercepted
and the alternative lookup method introduced: application, getaddrinfo,
recursive server, special purpose authoritative server.

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

---

From: "John R Levine" <[email-masked]>
Date: 15 Jul 2015 19:42:34 -0400

> message.  With dprive this should end up being secure.

Doesn't work because the underlying protocol isn't TCP.  It can work in 
SOCKS because that's an application layer gateway which can recognize 
.onion as special and set up a TOR session rather than a TCP session.

I suppose the recursive server could return an address in 169.254.0.0/16 
and run a proxy between a link-local TCP session and TOR, but ugh.

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

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 16 Jul 2015 06:39:44 +0200

On 16 Jul 2015, at 0:40, Joe Hildebrand wrote:

> I do want to point out that we ceded change control over XMPP to the IETF, and the XMPP working group made some fundamental changes to the protocol, including start-TLS, stringprep, SASL, a new error name scheme, version numbering, etc.

Exactly. Sorry for not being clear.

> I don't see any way that these protocol development efforts can be used as precedent for this draft.  If the TOR folks wanted to go through the process to standardize their protocols, we could think about the architecture we wanted for their identifiers and think about ways to avoid a special-use name.

Maybe, maybe not. Exactly how that would happen, and how, is of course unknown.

My point was that we do have many things that have first been "invented" outside of IETF and then brought to IETF intention and incorporated as the more successful IETF deliverables and responsibilities.

And for THAT I think XMPP is a good example.

> In the meantime, I have a specific technical objection to this draft, section 2:
>
> I'm skeptical that this SHOULD NOT will have any effect on any application other than some small number of popular web browsers. There are a LOT of non-web-browser applications in the world that do DNS lookups, and almost none of them will ever find out that they are leaking information because of this SHOULD NOT.
>
> As such, I suggest that this doc does not provide an adequate technical or market-based mechanism that will achieve its stated goal.

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Thu, 16 Jul 2015 05:56:37 -0400

--On Wednesday, July 15, 2015 22:59 +0000 John Levine
<[email-masked]> wrote:

>...
> I entirely agree that we should discourage people from
> inventing new naming schemes that borrow top level names in
> the DNS.  Life would be easier all around if they put them
> under .ARPA or .ALT or made them not look like domain names.
> But since we are not the Network Police, people will do
> whatever they do, and we as engineers need to make it work as
> best we can.
>...

John,

One thing that makes this particular range of cases interesting
is that, while there are no Network (or Protocol) Police for
dealing with violations of, e.g., HTTP or DNS specs, there is an
organization whose very explicit mission is to oversee and
manage the top-level domain name space and allocations and
reservations in it.  We can, and have, placed limits on what
they can do based on protocol requirements or constraints
(consider, for example, the requirement that labels in the root
be either ASCII "LD" strings or non-ASCII strings in ACE form
and fully compliant with IDNA2008).  By deciding that we are
going to make these decisions, we deprive ourselves of one of
the major sets of tools that is available to the overall
community.   That may be a good choice for other reasons, but
"not the Network Police" isn't, IMO, one of them.

Similarly, "people will do whatever they do" does not translate
into an obligation on us to aid and abet.  I note, for example,
that, while  spammers and spreaders of malware will do whatever
they do, we've never published documents or designed facilities
to make their work more efficient.   Indeed, the IETF and the
broader community have put a lot of effort into ways to make
their lives more difficult and their efforts less efficient and
effective.

> So if some maniac invented a new application that used
> .COCA-COLA outside the DNS, and we found that millions of
> other maniacs around the world were using it, our job as
> engineers is to make things work, which would likely involve
> saying that .COCA-COLA can't be in the DNS. It's not hard to
> imagine some people who'd be dismayed at that, but I don't see
> that as our problem.

Where we may disagree is that I don't think "our job as
engineers" is to start banning names.  It might be the best
possible solution for the community in the present environment
but that doesn't make it our problem.  It _is_ "our job as
engineers" to make it easier to detect bogus-apparent root zone
entries.  That is part of what DNNSEC is ultimately about and we
did that job.  However, I note that, from an engineering
standpoint, the original and later vintage RFC 1591 rules and
design -- rules and design that involved a small number of names
at root level, very low volatility of those names and
definitions (allowing easy checking against lists), and a notion
that one could distinguish "special names" by simply making the
labels longer than four characters -- were far more satisfactory
than the current environment in which it is necessary to deal
with each name on a case-by-case basis and then hope for the
best and that everyone concerned gets the message.  The present
situation may be entirely justified by other considerations and
we may have to engineer to adapt to it, but that doesn't make
any of this good engineering.

    john

---

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: 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
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

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: 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: 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: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Jul 2015 16:43:08 +0200

On Wed, Jul 15, 2015 at 11:33:39AM -0400,
 John C Klensin <[email-masked]> wrote 
 a message of 75 lines which said:

> If someone came to the IETF with a new piece of protocol that needed
> a reserved domain name and asked for a root-level name, I assume
> they would get a lot of pushback suggesting that they use a ARPA.

If you cannot show (by acts, not by words) to these people that it
works (they will get a .ARPA, and without spending years in
discussions), we may convince them. If, as I suspect, it is as
difficult to get a .ARPA (or a .ALT) that it is to have a TLD, then we
won't convince them.

> subtree or some commercially-available subdomain instead.

Then depending on the good will of several more actors (the registry,
the registrar if the TLD uses the RRR system, etc). You won't convince
anybody with that.

> rather than engaging with the IETF when the protocols were being
> designed, the community involved decided to pick a TLD-style name,
> squat on it, deploy,

Come on, be realistic. Imagine a naive but eager Joe Developer coming
to the IETF with a proposal to use .carrot for a new naming system. He
would be immediately smashed with dozens of very long process-oriented
emails telling him that he is stupid, that he did not read all the
relevant RFCs, that we know better and that he should first read about
the DNS (which, let me remind you, is documented in many different RFC
with conflicting terminology), not mentioning the persons who would
ask Joe (real email, sent this week on dnsop) to go to ICANN with a
cheque of 185 k$.

Joe would immediately go back to his favorite editor and continue
coding without thinking more about the IETF and he would be right.

---

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

On Wed, Jul 15, 2015 at 09:56:27AM -0700,
 Ted Hardie <[email-masked]> wrote 
 a message of 331 lines which said:

> there are lots of other ways to partition the namespace.
> pseudo-TLDs are not required; they look convenient because they hide
> the costs.

I'm sure there are but, scratching my head, I don't immediately
remember one. It would be great to have an Internet-Draft describing
the ways to have identifiers for Joe Developer's new naming scheme,
with their pros and cons.

---

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

On Wed, Jul 15, 2015 at 03:13:35PM -0400,
 John C Klensin <[email-masked]> wrote 
 a message of 74 lines which said:

> a separate DNS CLASS, say "SN" for "Special Name".  Zero impact on
> the ICANN/IANA root from queries gone bad, no conflict with names
> ICANN allocates even if the labels are the same (remember that
> QCLASS=ANY has never worked), etc.

Classes in DNS are an old idea (see
<http://web.archive.org/web/20091227142955/http://net4d.org/index1.html>
for a defunct project) see the recent thread starting on
<http://mailarchive.ietf.org/arch/msg/dnsop/2JzQL2TeNc63qOoD7zl84Yu8p1I>
on dnsop, to see why it's a bad idea.

---

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: 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: Ted Hardie <[email-masked]>
Date: Fri, 17 Jul 2015 09:04:47 -0700

On Fri, Jul 17, 2015 at 7:46 AM, Stephane Bortzmeyer <[email-masked]>
wrote:

> ​Lisa Dusseault actually wrote up a good description of the choices one
point during her tenure as AD; I'll send her mail and see if she can
refresh it/put it into some place obvious.

Ted
​

---

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 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 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: 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: 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/)
>
> ...whereas the following *is* viable:
>
> 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: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Jul 2015 16:14:19 +0200

Hi,

On Wed, Jul 15, 2015 at 09:56:27AM -0700, Ted Hardie wrote:

> long-term characteristics.
[…]

On Wed, Jul 15, 2015 at 03:13:35PM -0400, John C Klensin wrote:

> possible and it would be name-independent.

I agree with both of these analyses, and I think there's a problem.
But it might be a problem with decisions we've already made.

We have some features in the DNS that are also duplicated as
work-arounds that are widely deployed.  The obvious example is
RRTYPEs.  In lots of cases, rather than using a nice special-purpose
type designed to carry the kind of data a conforming application
wants, people have created one or more "underscore labels" and put
structured RDATA in a TXT record.  This is a kind of in-band
signalling that is ugly, but which worked around the deplpoyability
issues with new RRTYPEs.

It seems to me that local and onion are another example of this, only
either for classes, or else for resolution protocol switching (I
suspect these two boil down to the same thing).  Basically, local was
a way of communicating, "Don't query me in the IANA DNS root name
space."  Since classes mostly didn't work anywhere, rather than
starting a new class to do this, mDNS and now Tor use the end-most
non-null label to signal, "Don't look this up in the IANA root."

But it seems to me that the fact people are inventing ways to do the
things the protocol already offers, and doing violence to the overall
system at the same time, suggests that we're doing something
fundamentally wrong with DNS.  I wish I had a clue what to do about
this, because I think there's faint hope that we're going to be able
to prevent these continued innovations: RRTYPEs are not a great deal
easier to deploy (though they're easy in nameservers themselves), and
CLASSes still don't really work[1].  I don't know whether what this
shows is that we just have to put up with the mess that all of this is
making, or whether what it's really telling us is that DNS's seams are
finally bursting from all the stuff we have tried to stick in there
(cf. http://www.cafepress.com/nxdomain/8592477 Note: possibly
offensive term).

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

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

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.

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