Re: Browsers and .onion names

On 11/28/15, Willy Tarreau <w@1wt.eu> wrote:
> Hi Mark,
>
> On Sat, Nov 28, 2015 at 10:40:32AM +1100, Mark Nottingham wrote:
>> That said, I don't see how it serves your users well to reject it out of
>> hand.
>
> It's not rejecting *this one* specifically, it's starting to add exceptions
> for everything even when you're not targetting a specific usage. This opens
> a pandora box. Now there is one exception. Next year maybe we'll have tens.
> And possibly some of them will conflict with internal names. 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

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.

>
>> 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. 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.

( I'm one of the authors of RFC7686, sorry for the hassle; we're
trying to protect users who don't understand complicated things like
XKeyscore and mass-surveillance and encryption and so on. )

All the best,
Jacob

Received on Saturday, 28 November 2015 09:53:36 UTC