Re: Browsers and .onion names

Hey Cory,

On 29 Nov 2015, at 8:52 pm, Cory Benfield <cory@lukasa.co.uk> wrote:
> 
> 
>> 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.

I think that's a fair position; just a bit surprised at the vehemence of the response from everyone. While 7686 could have been a lot more precise in that phrasing, I think the assumption was that software where it didn't make sense would just ignore that text (or the whole RFC).

After all, despite our best efforts, there still are no standards police.

If it's really bugging people, we can try to get an errata in, but I suspect the wording is going to be tricky, and likely quite verbose.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

Received on Sunday, 29 November 2015 09:59:16 UTC