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: Thu, 26 Nov 2015 07:54:10 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20151126065410.GC1889@1wt.eu>
On Thu, Nov 26, 2015 at 04:29:30PM +1100, Mark Nottingham wrote:
> Now that we have RFC7686, there's a new requirement applicable to HTTP clients:
> 
> """
> Applications (including proxies) that implement the Tor protocol MUST recognize .onion names as special by either accessing them directly or using a proxy (e.g., SOCKS [RFC1928]) to do so.  Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup.
> """

I'm surprized that an RFC on standards track managed to redefine how
non-interested implementations must behave :
  - there's this paragraph that you quoted above which affects perfectly
    standards-compliant applications
  - standards-compliant name resolution APIs and resolvers are now
    required to respond with NXDOMAIN if they don't implement the spec
  - caching DNS servers must be modified
  - authoritative servers must respond with NXDOMAIN
  - etc etc ...

Normally they only define the behaviour for compliant ones.

I smell a massive mess here. Had we adopted such a method to force
HTTP/2's on-wire compatibility with HTTP/1 by deciding how current
H1 implementations must behave, we'd have had less difficulties to
build a handshake. Eg: "deployed implementations must suddenly not
do this nor that and it magically works".

There's no way existing implementations will change their deployed
working code just to take in consideration something they're not
interested in, so I don't know what the end result will be when
non-compliant implementations face compliant ones.

Definitely strange form of alternate history :-/

Regards,
Willy
Received on Thursday, 26 November 2015 06:54:37 UTC

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