Re: Browsers and .onion names

> On 28 Nov 2015, at 23:27, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> 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?

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?

The answer, of course, is no: and to be clear, I’m not accusing your or Jacob of making that claim. I don’t believe the intent of the RFC was ever to make such a claim. However, the way the RFC is worded it *does* say that.

Again, I think with regard to *browsers* the advantage in implementing this requirement is clear, and I don’t object to it. I think with regard to curl the argument may apply too: it would be reasonable to want to enhance curl to talk over the Tor protocol. I think with regard to almost every other networked software application the SHOULD (NOT) is absurdly over-broad, and places a strong burden on them to defend against a user error that is extremely unlikely (the error, to be clear, is assuming the application can speak Tor).

I’m all for removing foot-guns, but at some point we need to accept that the value proposition does not extend as far as RFC 7686 wants it to: if all software really does need to defend against users speculatively adding .onion names to any configuration that accepts a domain then we’re clearly fighting a losing battle.

Cory