Subject: [DNSOP] A comparison of IANA Considerations for .onion

From: hellekin <[email-masked]>
Date: Mon, 11 May 2015 18:15:47 -0300

Since Alec Muffett seems to have better things to do, I feel obligated
to do what he should have done before publishing his draft: comparing
the IANA Considerations for .onion in the
draft-grothoff-iesg-special-use-p2p-names-04 (P2PNames) and
draft-appelbaum-dnsop-onion-tld-01 (OnionTLD).

# OVERVIEW

draft-appelbaum-dnsop-onion-tld-01 came as way to fast-track the
processing of .onion special-use TLD, as the P2PNames draft was
considered too controversial (and maybe too complicated?).  But this
work, although sporting the name of a co-author of the P2PNames draft
and claiming support by the Tor Project community, did not benefit
neither from concerted action with, nor consideration for the existing w
ork.

A simple comparison of the IANA Considerations for the P2PNames and the
OnionTLD drafts highlights critical flaws in the OnionTLD draft that
curiously didn't receive any attention at all so far (except my own, but
I reserved my comments up until now for others to come up with this, in
vain.)

I noticed 3 major issues in the OnionTLD draft:

1. the users considerations pretend that users must use onion-aware
software in order to access Onionspace, but I assert that you and I can
use an ordinary Web browser, type in a .onion address, and access the
requested service.  Not only OnionTLD conflicts with P2PNames on that
point, it also confuses users' awareness and application software
responsibility (and possibly the scope of IANA Considerations' first
question).

2. more importantly, where P2PNames imposes NXDOMAIN response to
authoritative name servers, OnionTLD makes it a soft requirement, thus
leaving the possibility for name servers to hijack Onionspace without
user consent nor awareness.

3. this error is confirmed for DNS server operators, where OnionTLD
makes it a soft requirement not to override responses.

Given the complementarity of 2. and 3. for successful dragnet abuse, I
have difficulty believing in a coincidence, and am very concerned that
such points could go through an IETF process without an itch.

That the P2PNames draft remains controversial should not remove from its
qualities, and notably its technical fitness and attention to detail.
As the editor of this draft, I apologize for the shameless
self-promotion and urge the DNSOP WG members to not confuse diligence
and precipitation.

# IANA CONSIDERATIONS DETAILS

This verbose section details point by point the differences and put them
in context with RFC6761 questionnaire.

## 1. Users

- From RFC6761: "Are human users expected to recognize these names as
special and use them differently?  In what way?"

*
The OnionTLD interpretation is wrong.  I want for proof that I can
browse Onionspace with an ordinary Web browser that does not treat
.onion sites any differently from a .org or a .net.  The OnionTLD
interpretation also contradicts the P2PNames interpretation, and pushes
responsibility to the users (who should know what they're doing).
Moreover, the OnionTLD interpretation also says that onion addresses are
"only available through [onion-aware] software", which is not the case.
*

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

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

OnionTLD contradicts this: "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."

## 2. Application Software

- From RFC6761: "Are writers of application software expected to make
their software recognize these names as special and treat them
differently?  In what way?  (For example, if a human user enters such a
name, should the application software reject it with an error message?)"

*
The OnionTLD interpretation only covers the case of onion-aware
applications, and then do not specify the response.
*

P2PNames says: "Application software MAY recognize .onion domains as
special, and SHOULD use these names as they would other domain names.

Application software MAY implement mechanisms helping the user to ensure
their privacy expectations are met, such as warning the user if they do
not detect an active local Tor resolver, displaying a warning on
first-use of an .onion domain to explain the necessity of a Tor resolver
to reach such domains, etc.

If an application knows how to differenciate between DNS and P2P name
resolution, it:

   *  SHOULD NOT pass requests for .onion domains to DNS resolvers
      or libraries,

   *  MUST expect NXDOMAIN as the only valid DNS response, and

   *  SHOULD treat other answers from DNS as errors.

Tor-aware applications MAY also use Tor resolvers directly."

OnionTLD says: "Application Software: Applications 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."

## 3. Name Resolution APIs and Libraries

RFC6761 says: "Are writers of name resolution APIs and libraries
expected to make their software recognize these names as special and
treat them differently?  If so, how?"

*
Here comes a good mark to OnionTLD: it's more precise than the P2PNames
draft on this point, imposing a MUST on resolution vs. NXDOMAIN.  The
P2PNames authors preferred not making any difference there between
onion-aware applications and not.
*

P2PNames says: "Name resolution APIs and libraries SHOULD either respond
to requests for .onion names by resolving them via the Tor protocol, or
respond with NXDOMAIN."

OnionTLD says: "Name Resolution APIs and Libraries: Resolvers that
implement the Tor protocol MUST either respond to requests for .onion
names by resolving them (see [tor-rendezvous]) or by responding with
NXDOMAIN.  Other resolvers SHOULD respond with NXDOMAIN."

## 4. Caching DNS Servers

RFC6761 says: "Are developers of caching domain name servers expected to
make their implementations recognize these names as special and treat
them differently?  If so, how?"

*
In P2PNames, "immediate negative responses" is not specified yet (for
lack of discussion about it across domain names) as negative responses
might be different than NXDOMAIN in some case (e.g. for .gnu domains).
*

P2PNames says: "Caching DNS servers SHOULD recognize .onion names as
special and SHOULD NOT attempt to look up NS records for them, or
otherwise query authoritative DNS servers in an attempt to resolve
.onion names.  Instead, caching DNS servers SHOULD generate immediate
negative responses for all such queries."

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

## 5. Authoritative DNS Servers

RFC6761 says: "Are developers of authoritative domain name servers
expected to make their implementations recognize these names as special
and treat them differently?  If so, how?"

*
This is the main conflicting point: OnionTLD does not recognize .onion
as special and allows Authoritative DNS servers to respond for .onion
("SHOULD").  From the P2PNames perspective, this is unacceptable, and a
complete failure to address the privacy concerns set forth by the draft.
 If OnionTLD would be accepted in that form, it would allow the root
servers to capture leaked onion requests AND RESPOND POSITIVELY FOR THEM
!
*

P2PNames says: "Authoritative DNS servers are not expected to treat
.onion domain requests specially.  In practice, they MUST answer with
NXDOMAIN, as "ONION" is not available via global DNS resolution, and not
doing so MAY put users' privacy at risk (see item 6)."

OnionTLD says: "Authoritative DNS Servers: Authoritative servers SHOULD
respond to queries for .onion with NXDOMAIN."

## 6. DNS Server Operators

RFC6761 says: "Does this reserved Special-Use Domain Name have any
potential impact on DNS server operators?  If they try to configure
their authoritative DNS server as authoritative for this reserved name,
will compliant name server software reject it as invalid?  Do DNS server
operators need to know about that and understand why? Even if the name
server software doesn't prevent them from using this reserved name, are
there other ways that it may not work as expected, of which the DNS
server operator should be aware?"

*
Again, the OnionTLD authorizes normal use of .onion in the DNS, which is
totally out of the question and conflicts with the purpose of the
P2PNames draft to protect users' privacy.
*

P2PNames says: "DNS server operators SHOULD be aware that .onion names
are reserved for use with Tor, and MUST NOT override their resolution
(e.g., to redirect users to another service or error information)."

OnionTLD: "DNS Server Operators: Operators SHOULD 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

RFC6761 says: "How should DNS Registries/Registrars treat requests to
register this reserved domain name?  Should such requests be denied?
Should such requests be allowed, but only to a specially-designated
entity?  (For example, the name "www.example.org" is reserved for
documentation examples and is not available for registration; however,
the name is in fact registered; and there is even a web site at that
name, which states circularly that the name is reserved for use in
documentation and cannot be registered!)"

*
Yet another example of the difference between documentation and command:
P2PNames explains why it is so, while OnionTLD simply states it without
any context.
*

P2PNames says: "DNS registries/registrars MUST NOT grant any request to
register .onion names.  This helps avoid conflicts [SAC45].  These names
are defined the Tor protocol specification [TOR-PROTOCOL], and they fall
outside the set of names available for allocation by registries/registra
rs."

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

# CONCLUSION

Until now the debate has been in opposition to a single P2PNames draft
covering more than one domain, and this argument mostly suspended actual
criticism of the contents of the draft itself.  I would like that this
comparison bring forward another process to consider the P2PNames draft:
instead of focusing on how it should be (split), attention should be put
on what is good (or wrong) with each treated domain, so that
collaborative work is not stuck on beliefs and political arrangements,
but keeps the technical merits first and foremost.

I firmly believe that even in the event of splitting the P2PNames draft,
various RFCs covering the P2PNames should belong to a single family of
publications, maybe with one Informational RFC covering all of the
pTLDs, and one or more pTLDs per Special-Use Domain Names reservations
to keep reading simple to digest for administrative entities who do not
need to delve into the technical details.  Whether we split the P2PNames
draft or not, I think that 1) further work on these domains SHOULD be
collaborative and not competitive; 2) the Peer-to-Peer systems form a
single logical entity that should be addressed as such.

I'm looking forward to break this opportunistic behavior to play
politics and satisfy administrative formalities, and instead use the
precious resources of our brains to constructive dialog towards rough
consensus on privacy matters.  I dearly miss the (volunteer) time I had
to spend on making this document available.

==
hk

---

From: Alec Muffett <[email-masked]>
Date: Mon, 11 May 2015 23:21:24 +0000

Hi Hellekin!

 >Since Alec Muffett seems to have better things to do

I'm sorry if you've been waiting for my input - I am not the primary
author of the document; Jacob Appelbaum's name is in the document's
title for a good reason, and my involvement has been one of tuning a
few paragraphs, providing some wordsmithing, and cheerleading loudly.

Jake is - as I am sure you are aware - working for Tor, and is a busy
guy (last I heard was off in China doing something amazing) hence I
mailed out the latest draft when there was in extended (and ongoing)
lull in the desire for anyone on our editorial maillist to tweak it.

I'll do my best to respond to your points, albeit Jake and other
(wiser?) heads may have additional insights that I may miss by dint of
this being dropped on me at 10pm the night before the big phone call
to discuss such matters.

On that basis, you'll also please forgive me excising brevity.

 >software in order to access Onionspace, but I assert that you and I
 >can use an ordinary Web browser, type in a .onion address, and
 >access the requested service.

If you are consciously running TAILS, I suppose so [ED: TAILS is a
Linux distribution which funnels almost all communication through Tor]
albeit that Tor would likely recommend against using a vanilla browser
in default configuration to access any part of Tor, let alone ".onion"
addresses, because risk of deanonymisation is too high with normal
browsers.  Hence the imprecations in favour of informed users,
reflecting Tor user-policy.

If you are not talking about running TAILS (or similar) then I must be
misapprehending what you mean by "can use an ordinary Web browser,
type in a .onion address, and access the requested service" because
your average browser - say Chrome - cannot access ".onion" without Tor
software help and some fiddly configuration.

 >authoritative name servers, OnionTLD makes it a soft requirement,
 >thus leaving the possibility for name servers to hijack Onionspace
 >without user consent nor awareness.

Yeah, we tossed that one back and forth a bit, and eventually if
slightly grudgingly went with the "SHOULD" on the basis that we wanted
the draft to be adopted more than we wanted to be thinking wishfully.

 >makes it a soft requirement not to override responses.

This might be an issue so long as your threat model includes blindly
unaware users who are typing ".onion" addresses into non-Tor-capable
browsers in the (presumably first-time) expectation that it will work,
and using resolver libraries which don't honour the imprecation that:

    [draft-appelbaum-dnsop-onion-tld-01]
    Resolvers that implement theTor protocol MUST either respond to
    requests for .onion names by resolving them (see [tor-rendezvous]
    [ED: A TOR-INTERNAL THING]) or by responding with NXDOMAIN.

...on a network infrastructure which is thoroughly pwned by a capable
bad actor.  Not totally impossible, I'll grant you, but threat models
which start from the assumption of a wholly ignorant userbase are
(joking aside) pretty flawed.

Continuing...

[DELETIA]

 >Since there is no central authority necessary or possible for
 >assigning .onion names, and those names correspond to cryptographic
 >keys, users need to be aware that they do not belong to regular DNS,
 >but are still global in their scope."
 >
 >OnionTLD contradicts this: "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."

Please explain the contradiction, I fail to see it?

[DELETIA]

 >This is the main conflicting point: OnionTLD does not recognize
 >.onion as special and allows Authoritative DNS servers to respond
 >for .onion ("SHOULD").  From the P2PNames perspective, this is
 >unacceptable, and a complete failure to address the privacy concerns
 >set forth by the draft.  If OnionTLD would be accepted in that form,
 >it would allow the root servers to capture leaked onion requests AND
 >RESPOND POSITIVELY FOR THEM !  *

There are entire papers about that.  Thank you for raising that point,
I wanted an excuse to post this URL to the DNSOP list:

    https://petsymposium.org/2014/papers/Thomas.pdf

    Measuring the Leakage of Onion at the Root - A measurement of
    Tor’s .onion pseudo-top-level domain in the global domain name
    system

...to help drive home the need for making ".onion" special.

As before, ignoring the potential for privacy-leakage of which site
you are seeking to connect to, this notion of "ZOMG THEY COULD HIJACK
THE SITE!!!!" is not a problem if you're using Tor-enabled software
and have awareness of the issue, per the draft security
considerations.

[DELETIA - I WANT TO GO TO BED I HAVE A VERY LONG DAY TOMORROW]

Your conclusions mostly seem to be a matter of what you want the RFC
to look like; that's a matter upon which I shall punt.

You also use the word "competitive" which (at the risk of overcooking
my interpretation) is a feeling that I have not felt during the
development of this draft.

I do want to address that, though.

There is no politics being played here.  This is not a race between
RFC drafts, this is a matter of considering a small, neat document
that delineates how to address one small, and fairly clear, "Special
Name" problem, seeking to address it properly in the time allotted
before November 1st swings by and Ballot-144 kills ".onion", possibly
forever.

I was brought in to help with a largely pre-written draft which -
as-above - I've merely helped edit a bit.  Come to that, Mark
Nottingham has played possibly an equal role in keeping us on the path
and helping wordsmith things up to IETF standards, though he seems to
not want direct credit.

I can't address your larger feelings about the two drafts and the time
that you committed to one of them, but having been invited to become
involved with _this_ one, and having edited it a little bit, and
having pushed it into the queue, I am proud to say that I have been
involved.

And - speaking as the engineering lead for one of the newest and
arguably most notorious ".onion" addresses - I feel that it's a pretty
good document, and one that is fit for purpose.

  - alec

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 May 2015 20:26:35 -0400

Hi there,

On Mon, May 11, 2015 at 06:15:47PM -0300, hellekin wrote:

> considered too controversial (and maybe too complicated?).

As one of the people who has objected to the p2pnames draft, I would
say that appelbaum-dnsop-onion is an attempt to break out one of the
candidate special names from the others, so that all the applications
don't share fate. 

> I reserved my comments up until now for others to come up with this, in

Well, they're different drafts, and therefore it's not completely
surprising that they don't agree.  I suspect part of the issue here is
that appelbaum-dnsop-onion has been adjusted because of some comments
some of us made.

> responsibility (and possibly the scope of IANA Considerations' first

I've asked about this issue several times, and I keep getting
different answers.  What isn't clear to me is whether there is
somewhere in the user's stack -- maybe it's the resolver, maybe it's
the application, whatever -- that knows that onion is special and
therefore shouldn't be looked up in the public DNS.  I assume there
has to be _somewhere_ that is special, or the alternative resolution
obviously wouldn't work.  I think that needs to be indicated
somewhere, because this fact is what makes onion a candidate under
6761, I think.

> user consent nor awareness.

Yes.  That is in fact a possibility.  There is no way for a protocol
document to make it impossible for someone to redirect this name, and
if your queries for onion leak into the public DNS you have to be
prepared for the possibility that someone will provide a local answer.
It's a plain fact of working on the Internet, and trying to legislate
this in a protocol document provides inoperative assurances.  In fact,
the way that onion was deployed without a registration with the policy
authority over the root zone rather nicely illustrates this fact about
the DNS: the global DNS only works because everyone uses the same
root.  If people start fraying that use, then the DNS itself is in
trouble.

> makes it a soft requirement not to override responses.

But again, you simply can't legislate that.  People do this all the
time.  Indeed, some people pay for services in which the answers from
their resolvers are munged to prevent access to "bad" sites and so on.

You could make this sort of fiddling with the data possible to detect
using something like DNSSEC, but you can't make it impossible to do.

> qualities, and notably its technical fitness and attention to detail.

Issues 2 and 3 were problems with the p2pnames draft when it first
surfaced, and I believe I included them in the comments I sent on it
in the first place.  If I didn't I apologise.

> .onion sites any differently from a .org or a .net.

Well, surely _this_ isn't what you want, because if that were the case
then the onion TLD would fail to resolve at all, since it isn't
delegated.

> only available through software that is aware of onion addresses."

But the point is, you need to know whether you have an onion-aware
resolution path available, or else you will leak your queries to the
public DNS.  I think that's all it says.

> error upon the use of .onion, and SHOULD NOT perform a DNS lookup."

What's the problem with this?  Isn't this what you want, that the
onion queries don't leak?

> might be different than NXDOMAIN in some case (e.g. for .gnu domains).

Yes, that difference is precisely why some of us have claimed that
p2pnames can't go ahead as written, because the considerations are not
identical for every name.  Asking for "negative responses" gets us
back into the kind of imprecision that has vexed the DNS for years.
What kind of negative response do you want for each case?

> ("SHOULD").

"SHOULD" doesn't mean, "This would be a nice idea."  It means, "You
better do this, or have a pretty good reason why you don't."  One
possible local reason could be that a local authoritative server (or
rather more likely, resolver) is overloading onion -- for instance, to
catch queries that were going to the DNS that shouldn't be.  It's
certainly going to be necessary to have some authoritative servers
respond to onion queries if we hope to sink that traffic AS112 style.
And I presume that, as onion's popularity increases, we'll need to do
that.

> criticism of the contents of the draft itself.

I seem to recall writing quite a long series of comments about
p2pnames a long time ago.  I didn't send additional comments when the
document didn't get broken up, becuase I said in the first place that
I thought it was a fatal flaw.

> politics and satisfy administrative formalities

I think that's just an _ad hominem_ argument.  There are good reasons
for the changes in appelbaum-dnsop-onion as compared to p2pnames, as
outlined above.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Mon, 11 May 2015 20:28:13 -0400

> ...to help drive home the need for making ".onion" special.

To save some time, the headline number is: The rate of .onion requests
hitting the A and J roots is ~200k requests per day and growing.

--Richard

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

---

From: hellekin <[email-masked]>
Date: Mon, 11 May 2015 21:29:02 -0300

On 05/11/2015 08:21 PM, Alec Muffett wrote:
> browsers in the (presumably first-time) expectation that it will work
>
*** You probably mean to say: human beings.

> bad actor.
*** You probably mean: the Internet.

> Please explain the contradiction, I fail to see it?
*** How can you fail to see that P2PNames says "Users can use these
names as they would other domain names", while OnionTLD says they cannot
?

> and have awareness of the issue, per the draft security
*** So you recognize that if your Tor setup is wrong, and you're not
aware of this, then it could happen that a malicious entity could serve
a copy of the original site, but resolved over the DNS.  This to me,
sounds like the well-documented--not hypothetical--abuses of NXDOMAIN
that were historically performed by Verisign, Comcast, and others.  Are
you sure you still don't see any difference at all between MUST and SHOU
LD?

==
hk

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 May 2015 21:19:19 -0400

> names as they would other domain names", while OnionTLD says they cannot

I think people can see that, and they disagree with you.

If you put an onion name into an application and your system (somehow)
is onion-aware, it will behave differently than if it is
onion-unaware.  If you put a com name into an application, it Just
Works, because DNS resolvers are basically universal.  That's an
important difference.  (Note that I picked com on purpose.  Ask the
users of info domains how many problems they still have, 14 years
after that TLD was first delegated.)

> you sure you still don't see any difference at all between MUST and SHOU

Not every network is a public-access one.  For instance, there might
be a local policy at my employer that onion names are not to be
resolved.  I can certainly imagine them installing a resolver that
captured and redirected onion resolution attempts.  (That is not, of
course, a policy at _my_ employer, but I can imagine such a case
without trouble.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alec Muffett <[email-masked]>
Date: Tue, 12 May 2015 06:12:54 +0000

To put this to bed for Andrew’s benefit, I have uploaded a picture at:

http://i.imgur.com/tvXrD8N.png

The top is standard Firefox (for clarity it has also a BBC News tab open)

The bottom is Tor Browser, which is Firefox hardwired to a Tor SOCKS daemon that performs resolution.

On the Tor-enabled browser, you have access to extra sites in the “.onion” TLD, as illustrated.

For clarity of my terminology, I “used" both browsers in the same way: pasted the URL “https://www.facebookcorewwwi.onion/“ into both, hit “return”, clicked the mouse, etc, the same way I would “use” most browsers.

They are the same core codebase - Firefox - after all.

One of them - the Tor Browser - is using a SOCKS daemon which knows that “.onion” is special and shouldn’t be looked up in the public DNS.

The other has received NXDOMAIN from DNS.

I believe that this demonstrates the condition you were looking for?

The Tor browser also has special modifications (e.g.: plugins elided, features tweaked) to attempt to inhibit traffic ever hitting the internet except via the Tor SOCKS daemon, although these are more for privacy and consistency than for access.

    - alec

---

From: hellekin <[email-masked]>
Date: Tue, 12 May 2015 03:44:09 -0300

On 05/12/2015 03:12 AM, Alec Muffett wrote:
>
> ... both Firefox...
> One of them - the Tor Browser - is using a SOCKS daemon which knows 
> that “.onion” is special and shouldn’t be looked up in the public DNS.
> 
*** So in my understanding of the scope boundaries of RFC6761 IANA
considerations, which seems to be the main difference between our drafts
and our respective positions, the former is "an application", while the
latter bundles "an application" and "a name resolution API or library".

In this understanding, the result obtained by the naked Firefox is
consistent with the application not caring about name resolution, not
considering .onion special, and returning NXDOMAIN for the unknown
domain like it would for a non-existent .com ; respectively, the Tor
browser bundle matches the description as well, serving the onion site
successfully and without prejudice, thanks to the availability of
non-DNS Tor name resolution via the SOCKS proxy.

(Other successful Tor onionspace-browsing setups could use a naked
Firefox with an IPtables set to direct packets on port 53 to the Tor
resolver: a separate application + resolver setup.)

Sleep tight

==
hk

---

From: Alec Muffett <[email-masked]>
Date: Tue, 12 May 2015 07:18:27 +0000

> On May 12, 2015, at 7:44 AM, hellekin <[email-masked]> wrote:
> 

Being a SOCKS-based service, of course, any SOCKS-enabled client can talk to Onion-space; including SSH, for instance.

    -a

---

From: Warren Kumari <[email-masked]>
Date: Tue, 12 May 2015 10:10:47 +0200

On Tue, May 12, 2015 at 2:29 AM, hellekin <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>

I'm a little confused / would like some clarifications.

Which if the two below is your preferred outcome:
1: .onion is reserved as a special use name, using the
draft-appelbaum-dnsop-onion-tld document, with the (alleged) warts],
or:

2: you toss a bunch of hand-grenades, alienate most of the working
group with pissy / passive-aggressive comments, *both* documents get
stuck in a morass of sniping and .onion doesn't get reserved?

Because at the moment it looks like #2 is where things are headed...

Sometimes the perfect is the enemy of the good.
Pragmatism over Idealism
Tuppence more and up goes the donkey!
How's your granny off for soap?
Other Platitudes Inserted Here.

W

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQJ8BAEBCgBmBQJVUUlGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
> ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg962AP/0A7YE1UslDCKctnm2CRC39V
> OMIPlVRITQNyAXE7FlqFL5W1PoebmZZsU5ITFiTUXnsPEonPon4KU9ZbGkFVhZ0q
> BQdGL77d1F6dCzBX0E50ePaBgiwFVS4mqIdNH0QWIgk4iE+3pduLP5kZSZcFzvuJ
> OWy/sOCZMdBdCUzV13Rg7UzYql89uYFGpg6o8Ti7AkdQM2soGdkht6mx/s4kN7qJ
> BE2JpXbgKvyYwlwx5J6kvwhN2tnhIDWFLGRZ3U6pqHZXaI9QvzfoLaFm/for7Ha6
> psjBirbqXJ5/+PPv2qt0ad4sJCBE3FFknLL+c4zDWGWo8ReiqOjDJ2yc1Jru31Lu
> a7EOejrv6Oor/owFBEIElzI/X4gdnwpuA5P4GSTFnjartAPzn98aylTC3S0GZwAe
> KudvUZABkQOOE/jTGGckYRYPmcQhOUXz4dfWQ2ZismYVEoNzqQFLrfU+6GmlkY4X
> Im70HVL5i72LMljuphlfForu8XPDdl0/uTPra6mE65cA9Wf85PBenbSd/YKGd33b
> Z+LxReRj5Q5l8+nDyQZJNqadadwPdsvPh4WknBDbio7CpX86bBHfNA4xEHe/lUGr
> J6k8KQ1SRilOfDF/9U7REQwQ3J3LSzTIObGxvtxtgJ3txRNzt+PmSbIiuApYrwj+
> l6Vq+UOxnV7rCEHEjoOl
> =/L7B
> -----END PGP SIGNATURE-----
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: hellekin <[email-masked]>
Date: Tue, 12 May 2015 09:06:44 -0300

On 05/12/2015 04:18 AM, Alec Muffett wrote:
>> considerations, which seems to be the main difference between our 
>> drafts and our respective positions, the former is "an application",
>> while the latter bundles "an application" and "a name resolution API
>> or library".
> 
> Being a SOCKS-based service, of course, any SOCKS-enabled client can
> talk to Onion-space; including SSH, for instance.
> 
*** I'm sorry Alec, but I don't understand the meaning of your response.

On the one hand you seem to agree ("of course"), but on the other hand
you seem to talk about something different.

Let's see.  "Naked firefox" is one case.  The TBB is another.  SSH is
yet another.  All three match the "application" case.  But only the TBB
comes with a built-in Tor resolver (and matches the "name resolution API
or library" case.)  Do you agree with that interpretation?

==
hk

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 May 2015 08:15:58 -0400

> I believe that this demonstrates the condition you were looking for?

Yes, and it's exactly the model I had in mind, and it also
demonstrates that users do in fact need to use different software in
order to access onion.  Moreover, it demonstrates that onion queries
will leak to the public DNS if such special software is not in place.
I think this shows that appelbaum-dnsop-onion is in fact correct.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 May 2015 08:23:07 -0400

> or library" case.)  Do you agree with that interpretation?

If the Tor Browser has its own resolver that is used just by it and
that is not a separate service installed with the expectation that
other clients will use it, then it seems to me the built-in Tor
resolver is part of the application, even if it happens to be built
out of components that _could_ be a name resolution API or library in
the general case.  It is definitely my impression that (for instance)
the Onion Browser installed on my iphone doesn't provide services to
other applications, and has its very own resolution system as a
result.  That suggests to me that there's more than one way to do
this, and one of those ways is for the application to be special.
It's not the only way, though, I agree.

Is your complaint that appelbaum-dnsop-onion reads to you as though
such special applications are the only way to do this?  If so, then
you're right that it needs adjustment.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: hellekin <[email-masked]>
Date: Tue, 12 May 2015 10:17:31 -0300

> you're right that it needs adjustment.
*** Yes, my concern is that we can get consensus on how to interpret
what an "application" means, and what a "name resolution APIs and
libraries" mean in a consistent manner in the context of RFC6761, as it
can lead to wide differences in the resulting rules for the readers.

==
hk

P.S.: your previous response was instrumental in my understanding of the
difference of views on MUST and SHOULD, and on the point developed in
this message, and I thank you for that.

---

From: Tom Ritter <[email-masked]>
Date: Tue, 12 May 2015 08:34:49 -0500

> It's not the only way, though, I agree.

Like you say there are a multitude of ways to do it, and there are
examples of most of them:

The tor daemon (often called little-t tor or just "tor") is a daemon
running on the OS that exposes a SOCKS service for anyone who speaks
SOCKS to connect to. You can point an unmodified browser at it, and
access .onion services. [0]  This is also how OrBot works on Android!

You can configure little-t tor to act as a DNS resolver, point
/etc/resolve.conf at it, and have all your DNS queries go through tor,
but not any of your actual traffic.[1][2]

You can use iptables and transparently proxy non-SOCKS traffic through
tor as either the main mechanism for internet access or as a backup to
prevent anything from not going through tor. TAILS and other anonymous
LiveDVD systems do this, and OrBot on Android supports this mechanism
also, if you have root access.

You can use TorBrowser, which bundles little-t tor, uses the SOCKS
access method, and requires no configuration to access .onion
services.

You can use a SOCKS aware program to access .onion services (or the
Internet) using TorBrowser's bundled tor, which is how Pond works.
Shutting down TorBrowser closes the connection to .onion services, and
Pond is stranded.

You can create a bundle, like Onion Browser on iPhone, which does
_not_ allow other applications to make use of the bundled daemon.

-tom

[0] As mentioned, this is a wholly insecure way to access sites
anonymously, as there are ways to a) get your real IP address b) link
you between TLDs c) correlate your browsing sessions and d)
fingerprint you uniquely.

[1] This is kind of a nifty way to get DNS privacy.

[2] If you attempt to resolve a .onion this way (as opposed to letting
SOCKS resolve it), this is the response:
dig @127.0.0.1 -p 5353 facebookcorewwwi.onion

; <<>> DiG 9.10.1-P1 <<>> @127.0.0.1 -p 5353 facebookcorewwwi.onion
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41248
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;facebookcorewwwi.onion. IN A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Tue May 12 09:31:31 EDT 2015
;; MSG SIZE  rcvd: 40

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 May 2015 09:36:41 -0400

> can lead to wide differences in the resulting rules for the readers.

Could you clarify what differences you see arising?

The difference between "application" and "name resolution" seems pretty
clear to me.  A name resolution library looks up information related to a
name; an application does more.  It's a functional distinction more than a
distinction between two pieces of software.  (As Andrew notes, they can be
combined.)

In any case, this doesn't seem like a hugely critical distinction, since
the requirements on both are pretty much the same -- do the special Tor
stuff with .onion domains or fail.

--Richard

> iQJ8BAEBCgBmBQJVUf1iXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9CCoP/26lZAk6UymUHKe6CyjG+XDe
> yvIgtI/vWvIlr2RvUycRO6mQwrDij6ZHi7lt/+ku0Xqrr+cDlNo55zfw5DrzJ8G7
> r31m7RS1mq6y4H9aPxkGwgB3FhrAM9A7hj/3Mu0zgewv0QrhSgW+zW9pw/315SM3
> h5Xaj4tVx6tsXAPkG6pefDaXFfXjJhuRtL0vXsk8pn2s1kc/2RekX0InUABEiKUf
> h6Y3M4uoYxfoMcbj6a0x7udihaANxt9/6B/npqjvyZXrSemYsxvUqEOcw32NtweD
> +C5EJJur7yFrAL3xYvRHKSVJSs1XJvjY3FvpfC0yhYmEUO7QUHmMYYAYVjCVpgEF
> 2raqdVaFoICARdiCbm/d5dQujfXPQfti8o5vQy72H2ZYiSgScO3GnwYHil70RhkN
> JcTbWeQ2+oyKvWEuVwF/I2E0WWXXSbZmbRKCKJQ4RnKfM1IOxfCnpx3wBoLk8nLX
> hKAB9pgjyk0T8T7v9wXeCKyIP18L82iGJQi9MCc/YOaSTL1tyNKjs/Hso5p1LSxS
> tuAAouE5TONI37Ud77Up13Mw9OJkCxse6o2bNs0Jox4laxvJV+nAJzSOwa6F6noj
> 8sU0Gv+v037U/bZQHRq/PIk4ELoAs3dxPhpG3AHCH0iqFPDAvTd/WkNzK/zmhPnN
> TeB49F986AAe85Hph8AA
> =qKXA

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 May 2015 09:41:14 -0400

> _not_ allow other applications to make use of the bundled daemon.

Thanks for enumerating the possibilities :)  I think those are all
consistent with the guidance in draft-appelbaum-dnsop-onion-tld, yes?  Most
of them correctly handle .onion names properly, and the DNS resolution
fails (correctly).

--Richard