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

Re: Browsers and .onion names

From: Willy Tarreau <w@1wt.eu>
Date: Sat, 28 Nov 2015 11:09:59 +0100
To: Jacob Appelbaum <jacob@appelbaum.net>
Cc: Mark Nottingham <mnot@mnot.net>, Cory Benfield <cory@lukasa.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20151128100959.GB4937@1wt.eu>
Hi Jacob,

On Sat, Nov 28, 2015 at 09:53:06AM +0000, Jacob Appelbaum wrote:
> > A lot of people
> > use ".local" as the TLD for their local network. Someone might suddenly
> > decide that ".local" must not be forwarded nor resolved for whatever reason
> > and suddenly all compliant agents will break existing setups. You know
> > better
> > than any of us that a cleanly designed protocol doesn't require existing
> > implementations to change to serve its purpose.
> Uh, I'm not sure if you're telling a joke or not but this entire
> process started because of .local as a Special-Use-Domain-Name:
>   https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

I didn't even know it was reserved. Once browsers start to block it, I know
quite a number of people who will report breakage such as inability to access
internal resources in their companies. Locally-administered TLDs are a missing
feature to complement RFC1918 but that's out of the scope of this discussion.

> Thus the Pandora's box opened up without notice, I guess? Perhaps it
> is time to implement them both?
> In any case, yes, we have Special-Use-Domain-Names and there is a list
> that some applications need to handle in a special manner. The IETF
> seems to be blocking all other new Special-Use-Domain-Names, so the
> flood you've express concern about is unlikely to happen.

Fine, at least the mess will be limited.

> >> If they accidentally make .onion queries without configuring to use
> >> Tor, they'll be unpleasantly surprised (and the consequences could be
> >> much
> >> worst, depending on their situation).
> >
> > So that basically means that Tor is unsafe without this ? Thus maybe using
> > this DNS mechanism was a poor choice to start with, and it's a bit late to
> > change all DNS agents just to fix the protocol's design issues.
> >
> No, Tor is safe and complies with RFC7686. Other browsers and software
> that leak .onion names are now understood to be unsafe.

So if they're safe, why should they implement this ?

> Just as time
> moved on, many browsers don't implement HTTP 2. Or browsers which
> still use SSLv2/SSLv3.
> There are lots of changes happening in browsers - this is no different
> - it is a security and privacy concern. It has been identified as a
> concern that we can resolve by following RFC7686, no pun intended.
> Browsers SHOULD implement it but as Mark has said: we have no RFC
> police.

But you understand the trouble and precedent it's setting up ? "yes I
know you're not interested in this protocol but despite this you should
implement its RFC". I could as well suggest that for the sake of any
protocol of mine, browsers take care to send even number of bytes in
any request and that proxies should block requests containing an odd
number of bytes.

I think it would be easier to suggest browsers to support a blacklist
of TLDs that should not be resolved nor passed to proxies and then let
users decide what TLDs they want to block. Those who use .onion addresses
probably know it.

Received on Saturday, 28 November 2015 10:10:30 UTC

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