Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt

[Alec Muffett <[e-mail]>]

> On Aug 27, 2015, at 21:46, Kathleen Moriarty <[e-mail]> wrote:
> Hi,
> I don't see any on list responses to the points Christian raised, have
> they been addressed?

Hi Kathleen!

I'm Alec, I am one of the co-authors of the draft.

At the suggestions of Mark Nottingham & Richard Barnes (cc:) we have refrained from issuing revisions to the draft because of the impending 2015-09-03 IESG telechat, in order that discussion does not derail for pursuit of a moving target; that said, we authors and our helpers and experts in IETF process (for whose help we are extremely grateful) have been discussing the best ways to address the handful of issues which have been raised.

One question under discussion has included a proposed amendment from IANA regards "registration" versus "delegation" and whether the notes kindly provided by IANA might, if their suggested amendment were made, cause a lack of orthogonality between the draft and other relevant documents. Suzanne raised that matter and we feel it's something best discussed and perhaps addressed in batch with other changes.


In particular reference to Christian's comments:

>> I am a bit puzzled by the way the security section is written. Since the
>> purpose of the draft is to reserve the “.onion” TLD, I would expect the
>> security section to present the security issues mitigated or introduced by
>> this TLD reservation. As far as I understand, the main security issues come
>> from client confusion, which could cause “.onion” names to be resolved
>> through the standard DNS process.

That is correct and is the intention, although perhaps my preferred phrasing would be "present '.onion' names as if they were subdomains of some other domain within an arbitrary top-level domain" - since this is really about the existence of Layer 7 proxies attempting to provide 'semi-transparent' access to the Tor Onion network as-if the onion namespace were a virtual namespace of some corporate enterprise.

An example of this would be:

https://3g2upl4pq6kufc4m.tor2web.org/ <https://3g2upl4pq6kufc4m.tor2web.org/>

...which is the (independent, non-Tor) Tor2web organization's link to the DuckDuckGo hidden service; the onion address is hidden as the leftmost label.

Precisely the same website is served though another proxy at:

https://3g2upl4pq6kufc4m.onion.cab/ <https://3g2upl4pq6kufc4m.onion.cab/>

...which is a layer 7 proxy run by Seotecs UG in Germany, but whose choice of DNS domainname under ".cab" leads to a more obvious risk of confusion.


>> A number of bad things happen then, from
>> simple information disclosure that a client is trying to access a TOR
>> service, to potential spoofing of secure TOR services.

Some bad things are possible, yes - HTTP man in the middle, not least - but to my mind the risks are little worse than risks the likes of "www.fac3b00k.com <http://fac3b00k.com/>.cab" would offer, and in fact I believe such risks underscore the importance of registering ".onion" so that SSL EV certificates can be brought to bear upon the mitigation of some of these risks.


>> In fact, the main
>> reason for the registration request is to mitigate these security issues, by
>> requesting that standard DNS resolvers and servers recognize “.onion”
>> requests and refuse to forward them.

Incorrect; the main reason for registration of ".onion" is CA/B-Forum Ballot 144:

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

...which permits the existence of SSL Certificates for Onion addresses until 1 November 2015.

If (upon that date) the ".onion" namespace has not been recognized as a global TLD, all SSL certificates for the ".onion" namespace will be killed and SSL will no longer be able to mitigate these threats for Onion sites.

This will lead to the shutdown of the Facebook ".onion" site, another that is owned by blockchain.info, and the SSL service for The Intercept magazine, amongst others.

Thus, my motivation.


>> The security section makes all these points, but it also mixes in a
>> description of the structure of .onion names and their cryptographic
>> components. I believe the issues would be easier to understand if the main
>> body of the document included a short description of the TOR naming process
>> and name resolution.

Per the comments above, a draft explanation of Onion address syntax (summary: they will remain compatible with DNS syntax) is with Mark and Richard for discussion but is on hold for the reasons explained above.

Regards Onion name "resolution", we believe that that matter is best dealt with outside the scope of this document, not least because the resolution mechanism is defined by software which is open to change.

It seems more important to confirm that Onion addresses will remain legal within the constrains of DNS label syntax.


>> The security section also does not explain how the “leakage of names” issue
>> is mitigated for legacy systems.

Simple: it's not.  The goal of leak-reduction is to reduce leaks, rather than to assure security.

There certainly is leakage of lookups for the ".onion" TLD to the root servers, and eliminating that 100% is unlikely, but it is a wasteful thing and should be inhibited for reasons of hygiene rather than security.


>> By definition, these systems have not been
>> updated and do not perform special treatment of “.onion” names. The TLD
>> reservation probably helps somewhat, but this is not discussed.

Agreed. That's never been the intent of the document, thus it should be fine.


>> Then, the security section also does not discuss how malicious name
>> resolvers could be deployed in order to attack the TOR network. For example,
>> if TOR security relies on DNS servers “black holing” misrouted request to
>> resolve “.onion” names, what happens if malicious servers replace the
>> suggested black-holing with some malicious tampering?


Tor security does not rely on blackholing DNS requests, it relies upon cryptographic technology.

Tools which are Tor-aware will not have the leakage problem.

Tools which make a half-assed approach towards Tor access  by passing names through DNS resolution should be encouraged towards failure, but it is not required for security.

    - alec


--
Alec Muffett
Security Infrastructure
Facebook Engineering
London