Re: Browsers and .onion names

On 29/11/2015 12:27 p.m., Mark Nottingham wrote:
> Cory,
> 
>> On 29 Nov 2015, at 3:59 am, Cory Benfield wrote:
>>
>>
>>> On 28 Nov 2015, at 11:56, Jacob Appelbaum wrote:
>>> We solve a real problem with RFC7686 and browsers, as well
>>> as other software, have a duty of care to implement the solution.
>>
>> The browsers part makes sense to me, it really does, and I (and maybe Willy) would not have objected in the slightest if this was brought up as a suggestion instead of what felt like a mandate. I don’t object to browsers refusing to process .onion domains, that makes perfect sense. I care much more about claiming that the requirement extends to anything that processes domain names (your “other software", even if that application makes no claim to support Tor or actively claims it does not.
>>
>> It is worth remembering that the space of things an piece of software does not implement is far larger than the space of things it does. It is a difficult and fraught endeavour to try to mandate behaviour in implementations whose authors had no reason to read your RFC because they had no plans to go anywhere near the Tor protocol.
>>
>> It’s also unhelpful to claim that all software that does DNS lookups has a duty to filter out .onion URLs to save users from themselves. This requirement is prima facie absurd: are we to require that, for example, Python’s logging library should filter .onion URLs in case a user tries to put a syslog daemon behind such a domain? Or, a more extreme case, that RADIUS implementations should do so? Remember, any RADIUS application is an “application that does not implement the Tor protocol”, so RFC 7686 would appear to affect those as well. This is so obviously absurd that I assume that it was not the intent of RFC 7686, but RFC 7686 is certainly worded so broadly that it can be read that way.
>>
>> There is nothing wrong with wanting browsers to filter .onion domains, because browsers can be extended to support the Tor protocol. There’s nothing wrong with wanting tools that could in principle support the Tor protocol, or that do not rule out doing so, to also special case the .onion domain. It is, however, totally barmy to claim a normative requirement on all DNS applications to filter out .onion domains and to (presumably) use that requirement as a cudgel to punish them with if they do not.
>>  
>> Many applications that process domain names come nowhere near a protocol or use that Tor is intended for, and shouldn’t be bound by this requirement. At some point, we have to rely on users not to just throw .onion names into every settings field they find.
> 
> Wait a minute -- you agree that the requirement is being placed specifically upon DNS applications, and then its application to things that have nothing to do with DNS. Has anyone actually been saying that .onion should be (e.g.) filtered out of logs?
> 
> Is this just a misunderstanding about the word "use" in the text below?
> 

No. I dont think so. For several reasons:

Requirement #1 is very arrogantly placed upon *human* behaviour.
  In what countries will this RFC be enshrined in national laws? and who
is going to enforce it?


Requirement #2 is placed upon "Application Software". The fact that it
is speaking of *all* application software is clear by calling out
proxies and browsers as being part of the group, and the split outlining
separate requirements #3-#7 for DNS implementation types.


For a case study:

Squid does *not* implement Tor. Which means that we SHOULD under this
protocol return an error page for .onion requests.

However, we do proxy anything by tunnelling. As per CONNECT method
definition.

Over the past few weeks there have been a growing number of user
complains about how their proxy is not working when used by browsers
configured to use Squid proxy to (securely) relay requests to a
Tor-enabled proxy / gateway.


As for .local being a precedent. It *is* perfectly valid for a LAN DNS
resolver to implement .local diversion. And for any software that does
not implement .local gatewaying to simply ask its local resolver for
those .local names.
This .onion RFC is actually forbidding that demonstrated working
behaviour by .local from being used to fix .onion problems.

HTH
Amos

Received on Sunday, 29 November 2015 03:35:32 UTC