Re: Browsers and .onion names

bear in mind also not all internet software uses the system's resolver.

It was fairly common for mail delivery software to do its own resolution 
(e.g. craft UDP packets etc) in order to perform MX lookups.

It's also common for customers to remove all resolution capability of an 
underlying host for various reasons (e.g. to prevent malware from having 
connectivity by name), and the proxy does its own resolution (WinGate 
has had its own resolver for well over a decade).

So relying on OS vendors to patch resolvers is probably going to catch a 
lot less than you might think.

Sure I could put handling (e.g. return NXDOMAIN) for .onion in our 
resolver, but it seems like a fairly nasty hack and it's not scalable - 
when will some other special use domain come along and become a problem 
like this.  Every time one is added, every resolver needs to be updated. 
  Also what about every DSL/NAT on the planet which does DNS forwarding.  
You really expect those to be updated for this?  It's just not 
happening.

Personally I think it should have been possible to solve authentication 
and discovery issues for Tor in ways other than overloading DNS like 
this.  And sanctifying such overloading with RFC6761 seems a move in the 
wrong direction to me.

Adrien


------ Original Message ------
From: "Cory Benfield" <cory@lukasa.co.uk>
To: "Amos Jeffries" <squid3@treenet.co.nz>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 30/11/2015 9:16:59 p.m.
Subject: Re: Browsers and .onion names

>
>>  On 30 Nov 2015, at 01:48, Amos Jeffries <squid3@treenet.co.nz> wrote:
>>
>>  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).
>
>Which is a substantial part of the problem, because the legacy install 
>base is actually *every DNS-using piece of software ever deployed*, 
>minus anything that already implements Tor. That is a sizeable base of 
>software. As I said earlier, it’s a much larger space of software than 
>the space of DNS resolvers, which are also the natural place to fix 
>this problem in the software stack.
>
>The complaint has never been that the requirement not to leak .onion 
>names is bad. The complaint is that chasing applications up for this in 
>the RFC is a poor fix. *Resolvers*, which already have an incentive to 
>implement the RFCs that come from DNSOP, are the perfect place to do 
>it, and fixing those will have the effect of propagating the correct 
>behaviour transparently to applications.
>
>It’s totally reasonable for active projects with large resources (e.g. 
>web browsers) to make an effort to improve this *right now*, but 
>otherwise it seems a terrible misallocation of resources to pressure 
>applications to fix what the resolver should.
>
>In practice, Mark raised his issues only against browsers (and curl, 
>which may be a special case because curl implements nearly every 
>protocol ever designed and it’s reasonable that Tor might want to be 
>one of them). That, I think, is reasonable. The push-back is coming 
>from maintainers of other applications who quite reasonably believe 
>that the RFC applies to them, but think it shouldn’t.
>
>IMO, the normative language should have applied to resolvers and been a 
>MUST. The application directive should either have been non-normative 
>or should have been MAY, providing guidance for developers of 
>applications where the risk of users accidentally providing a .onion 
>name is high (or at least moderate). Unfortunately, the horse has 
>already bolted. We could prepare an erratum, but Mark has suggested 
>that the value of that would not be very high.
>
>Frankly, I think the main thing we get out of this is a learning 
>experience. This is why RFC authors need to restrict their normative 
>language to things that can be enforced/detected by compliant 
>implementations. Any other use of normative language is just to make 
>the author feel better, rather than something that will actually get 
>done. It’s incredibly tempting to have broad-scoped unenforceable 
>normative directives: I seem to recall Martin shooting down a number of 
>them over the course of the writing of RFC 7540. I’m now personally 
>much happier with why we shouldn’t.
>
>Cory
>

Received on Monday, 30 November 2015 18:18:27 UTC