W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: Browsers and .onion names

From: Mark Nottingham <mnot@mnot.net>
Date: Sun, 29 Nov 2015 10:27:32 +1100
Cc: Jacob Appelbaum <jacob@appelbaum.net>, Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <73931F2D-9BB9-40A8-953C-C3F6460A84C2@mnot.net>
To: Cory Benfield <cory@lukasa.co.uk>

> On 29 Nov 2015, at 3:59 am, Cory Benfield <cory@lukasa.co.uk> wrote:
>> On 28 Nov 2015, at 11:56, Jacob Appelbaum <jacob@appelbaum.net> 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?

"""Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup."""

... because I (and I think most others) read that as being in the context of the operation of the DNS protocol (given the nature of the registry).


Mark Nottingham   https://www.mnot.net/
Received on Saturday, 28 November 2015 23:28:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC