Re: Browsers and .onion names

On 11/29/2015 11:45 AM, Eliot Lear wrote:

> I'm still not entirely clear on what the concern is.  I *think* what is
> being said is the following:
> 
>  1. .onion requires special handling.
>  2. If you don't know how to handle it, pass an error back to the user.
>  3. If you're about to query the DNS for a .onion name, then you don't
>     know how to handle it.
> 
> Whether this is with a browser or curl or something else, that seems to
> make sense to me.  I could easily envision a proxy that can handle
> .onion.  That means one might never get to step 3 if you're using a proxy.
> 
> Or have I missed the point?


AFAICT, the biggest one is that the correct "special handling" by
non-Tor applications is undefined. You have [essentially] said "If
you're about to query the DNS for a .onion name, then pass an error back
to the user instead". This instruction is missing the "else" clause:
What if I am not about to query the DNS for a .onion name? What should I
[not] do to comply in that case?

As my earlier questions attempted to show, there are many areas where
there is no DNS lookup but there may be leakage, and it is not clear
whether that leakage complies with or violates the spirit of RFC 7686.

While the RFC claims that

""".onion names are "special" [because] they require hardware and
software implementations to change their handling in order to achieve
the desired properties of the name."""

Those "desired properties" are left undefined as far as non-Tor
applications are concerned so it is difficult for a non-Tor application
to know what to do with .onion names (other than not doing a DNS lookup
with them -- which is usually best handled by a DNS library anyway).


If the RFC can be adjusted to limit its scope to DNS lookups, everything
will become clear AFAICT, but I do not know whether that narrow
interpretation would still prevent the leaks that Tor folks want to prevent.


Alex.

Received on Monday, 30 November 2015 07:08:35 UTC