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