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" <p...@nohats.ca> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
