Re: Browsers and .onion names

On 30/11/2015 7:45 a.m., Eliot Lear wrote:
> Hi Cory,
> 
> On 11/29/15 10:52 AM, Cory Benfield wrote:
>> Mark,
>>
>> I’m sorry if I was insufficiently clear. When I said “rely on users not to just throw .onion names into every settings field they find”, I specifically meant that many applications have settings fields that allow users to provide names that will be looked up. For example, at my previous employer we had a RADIUS implementation that would talk over the network, and so would emit a DNS lookup. Are we really saying that that software should be filtering .onion names because a telco operator *might* put a .onion name into the “RADIUS server” configuration field?
> 
> 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?

Legacy install base. Old code of non-Tor applications always does (3).

What is being said is not what is being required.


If the application does not know how to handle FQDN (or something that
is indistinguishable from a public FQDN). Then it will not be going to
DNS, so is not a problem and will do #2 automatically anyway.

If it does know how to handle public FQDN (whether directly or via
third-party APIs), but was never coded to implement this RFC. Then it is
a problem, and is required to immplement this RFC.

 ... Doing either of step #2 and #3 *is* implementing this RFC.

Ergo, if one does not implement this RFC, one is required (MUST or
SHOULD) to implement this RFC.

Ridiculous situation. Everybody get to laugh at DNSOP.


This really does seem to be a problem that resolvers are the best placed
to fix. If a non-Tor application tries to resolve .onion and gets
NXDOMAIN or other error back. Then it is highly likely to handle that
appropriately by delivering an error to the user.
 No need to place special requirements on such applications in the first
place. They can and will just ignore this RFC.

Amos

Received on Monday, 30 November 2015 01:49:57 UTC