Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[Alec Muffett <[e-mail]>]

Hi!

I’m Alec Muffett, I am the other author of this document.

I am a software engineer working at Facebook, and am the lead on the
Facebook over Tor project - https://facebookcorewwwi.onion/

I’ll do my best to answer as many of the extant questions as possible, so
far:


On 3/17/15, 1:14 AM, "Paul Wouters" <[e-mail]> wrote:

>On Mon, 16 Mar 2015, Jacob Appelbaum wrote:
>> Subject: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
>
>Is this meant to replace or augment
>draft-grothoff-iesg-special-use-p2p-names ?


My understanding is that this is not meant to replace that document, but
instead that this document is a separate one.

Being as I am one of the authors of this document, I believe that my
opinion carries some weight in this matter.

The reason I am not more emphatic in this matter is that the question
as-phrased is essentially about *that* document, not this one, and I do
not speak for or on behalf of Christian Grothoff, author of that document.

Thus, I shall cc: Christian into this message, in case he wishes to
describe his perspective of that document with respect to this one.


>How does the certificate "dead line" affect (non-)DNS for .onion?

Permit me to quote Brad Hill:

Quote: "The end date for the internal names loophole* is October - all
public certs [which are issued] not for public namespaces MUST be revoked
at that point. CAs can continue to issue up to that time, but they all
must expire or be revoked on Oct 1, and no new ones issued. Those certs
are really extremely dangerous, and [Brad has] been working for NINE YEARS
now to make them go away. Can't happen soon enough.” <endquote/>

The “facebookcorewwwi.onion” certificate (please feel free to examine the
SSL certificate issued by facebook.com for details) is currently issued
under a loophole that permits Subject Alt Names to contain "local” and
domain-names.

CA/B Forum have - as Brad hints above - planned to kill such, for some
time.

In Ballot 144, CA/B Forum approved process for formal issuance of SSL
certificates to ".onion” addresses, providing satisfactory means to
attribute ownership.

Note, though, Brad’s comment, "not for public namespaces”, ie: that
certificates will, after October 1st, only be issued for approved public
namespaces.

Thus: ".onion” needs to become a formally approved public namespace.

Hence this document: The goal is seek formal approval of “.onion” as a
TLD.  

I will defer to Richard Barnes and Mark Nottingham regards the larger
aspects of this process, but in passing note that Hellekin’s observation:

Quote: “we can also consider it a god-given gift for people who argued
against multiple TLDs in a single draft” <endquote/>

…is precisely correct; this is a small, simple proposal for (we hope) a
small, simple change, in (ideally) prompt time.



>I have reviewed the document and I'm not sure what is intended? I think
>it is meant as advise to DNS implementors? I guess it is an attempt to
>reduce .onion leaks if those happen to hit the DNS infrastructure?

The goal is to seek formal approval of “.onion” as a TLD; as such, that
the larger DNS community understands the special nature of the onion
namespace is an important thing.

To paint a naive, thumbnail sketch of how “.onion” addresses work:

1) A user creates a RSA key, distinct from SSL or IPSec or any other form
of crypto
2) The user hashes the public key using a specific hash function.
3) The hash, being unfeasibly large, is truncated a bit and the resulting
bitstring rendered as a (currently) 16-character string
4) The resultant string has the word “.onion” appended to it, and the
whole serves as a layer-3-like endpoint in an encrypted peer-to-peer
mesh-type network “cloud”

All communications are protected by RSA under the key of the server which
someone is connecting to.

As is obvious, in this scheme there is no “root zone” for “.onion” and
there is no “directory” either; instead the “cloud” maintains a dynamic
set of mappings from Onion Address to IP Address, which (by design) change
at regular intervals to defeat various attacks.

People are expected to gather the onion address to which they are
connecting via other means, eg: advertising or social media.

By a process of mining arbitrary keys and experimentation, an onion
address which is semi-human-meaningful can be established in order to make
things easier for people, eg: blockchainbdgpzk.onion or
facebookcorewwwi.onion

However, to reinforce: there is no root zone, no centralised directory.
You can see elements of the underlying entropy of the hash in the “dgpzk”
of “blockchainbdgpzk.onion” - these are actually binary strings with a
hint of human readability, rather than “domain names”, and thus no
centralised repository is required since they can be accessed via
mechanical discovery, quite similar to “192.168.1.1” is accessed via ARP &
Routing.

But, again by analogy to IPv4, you can see the potential risk to
192.168.1.1 if someone were to register a “.1” top level domain, however
silly a concept that might be.

Hence the importance of DNS being (at least) slightly aware of “.onion”.

Plus, as noted elsewhere, information leaks
("whom-is-accessing-which-sites") are often considered risky, by Tor/Onion
users.

[deletia]


>	The Tor network [Dingledine2004] has the ability to host network
> 	services using the ".onion" Top-Level Domain.
>
>Well, it does not because there is no Top-Level Domain of ".onion" and
>we have the cryptographic proof of that in the root zone.


Which is what the document seeks to address.


>
> 	Applications that do not implement the Tor protocol
> 	SHOULD generate an error upon the use of .onion, and SHOULD NOT
> 	perform a DNS lookup.
>
>If an application does not implement tor, and is not tor aware, it
>_will_ do a DNS lookup. You can't really go ask the world to stop
>doing that. You need to deal with that fact.


I understand your point, and reality is a good check; by analogy though,
most (?) programmers are aware not to try looking up “192.168.1.1” in a
the “.1” top-level domain, and I hope this “should not” phrasing will
grow, with the establishment of “.onion” as a TLD, to reflect similar sane
practice.



>	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.
>
>Again, stating what software that is not TOR aware should do is a lost
>cause. They will just think it is a real DNS query and process it that
>way.


Quite. That is, indeed, how it currently works.

When we launched the Facebook Tor Onion we were concerned that malicious
people would seek to attack users by setting up local DNS resolvers to
point a DNS address of “facebookcorewwwi.onion” to a malicious IP address,
and then persuade users with non-Tor-capable browsers to access it.

This concern was fortunately mitigated by our broad use of SSL; but this
threat model understores the importance of proper SSL certification and
putting “.onion” on a proper footing as a TLD and within DNS.

With the aid of CA/B Forum Ballot 144, the first portion of that risk has
been addressed - it should become astonishingly hard to generate an
acceptable SSL certificate for an "onion address” for use on the IP-based
network space.

[deletia, apologies, I am going to skip some stuff and seek to revisit it
later, due to time constraints.]



>    Users must take special precautions to ensure that the .onion name
>    they are communicating with is correct, as attackers may be able to
>    find keys which produce service names that are visually or apparently
>    semantically similar to the desired service.
>
>    Also, users need be aware of the difference between a .onion name
>    used and accessed directly via Tor-capable software, versus .onion
>    subdomains of other TLDs and providers (e.g., the difference between
>    example.onion and example.onion.tld).
>
>I don't think an RFC can tell enduers what to do or expect?


Actually, I feel that an RFC can tell users what to do and/or expect.

That’s what “documentation” is *meant* to be for. :-)

But, again, I think I take your point.  Do you feel the wording is perhaps
too aggressive?

    - alec


--
Alec Muffett
Security Infrastructure
Facebook Engineering
London