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

Re: Browsers and .onion names

From: Cory Benfield <cory@lukasa.co.uk>
Date: Fri, 27 Nov 2015 08:32:32 +0000
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <8DF63452-9BBB-4890-A159-1E76119A00F1@lukasa.co.uk>
To: Willy Tarreau <w@1wt.eu>

> On 27 Nov 2015, at 07:41, Willy Tarreau <w@1wt.eu> wrote:
> 
> On Fri, Nov 27, 2015 at 11:24:57AM +1100, Mark Nottingham wrote:
>> I'm wondering specifically about browsers that don't implement the Tor protocol; so far it looks like they don't conform. A few bugs:
>> 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1228457
>> https://code.google.com/p/chromium/issues/detail?id=562265
>> https://github.com/bagder/curl/issues/543
>> Apple bug 23672882
>> 
>> I don't have a Windows box on hand, would love it if someone could test there and file a bug if appropriate.
> 
> So are we going to scan each and every DNS client that was written in the last
> 30 years and suddenly declare them non-compliant with a new standard that was
> written *after* them and not specifically for them ?
> 
> I mean, I think it's really the first time I'm seeing bugs filed at products
> for not complying with a spec they do not implement!

I agree with Willy here, sadly. I have absolutely no intention of adding this exception for .onion names to any software I work on.

Why is this the DNS client’s problem? If we really don’t want .onion names to leak over DNS, why don’t we add a new DNS RFC that specifies that conformant resolvers don’t emit queries for .onion names?

Also, as the RFC points out:

> Also, users need to understand the difference between a .onion name
> used and accessed directly via Tor-capable software, versus .onion
> subdomains of other top-level domain names and providers (e.g., the
> difference between example.onion and example.onion.ld).

Given that the DNS search path exists, how am I (a client that accepts URLs) supposed to know whether “some-url.onion” is meant to be a Tor onion URL, or whether the user expects the search path to be appended to get to “some-url.onion.corp.org”. Am I to require that previously working URLs now fail because they *might* be a valid .onion name, even though the user can’t reasonably expect to *reach* that name through the Tor protocol using my software because I don’t implement it?

As Willy points out, it is *crazy* to open bugs that say that “your implementation does not comply with an RFC it does not implement”. That is true of all software ever written. Never before have we had a normative requirement to comply with RFCs we do not implement.

Received on Friday, 27 November 2015 08:33:06 UTC

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