Re: Browsers and .onion names

On Sat, Nov 28, 2015 at 11:56:56AM +0000, Jacob Appelbaum wrote:
> I think that .local is reserved by RFC6762 which is around two and a
> half years old. Most Apple computers have been using .local for mDNS
> related stuff for a lot longer, which is how .local was reserved by
> Apple in the first place. Most GNU/Linux systems with systemd also use
> .local.
> 
> Will it break stuff? No, probably not, as the way .local is handled is
> such that absent infrastructure, it Just Works (TM). Will it conflict
> with other systems? Probably sometimes.
> 
> Does that mean .local is going away and that we need to ignore how it
> is being used? I don't think so....
> 
> Does it mean that local admins who picked .local are probably sad
> about that choice? Yes, I suspect you are correct, it would.
> 
> What shall we do here? Abandon all Special-Use-Domain-Names? What
> about the other dozen? And why shall we do that?

No, just register some permanent and reliable names. RFC6762 suggested
that a number of people were using .local prior to the RFC and would be
bothered. It suggests to use other TLDs instead such as .lan, .private
etc... None of them is reserved, and there's even an errata on the RFC
now suggesting to remove this suggestion to avoid breaking setups a
second time. All it shows is that declaring breakage *after* a standard
is a bad thing for users and is a proof of poor initial design.

> >> 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 ?
> 
> Tor is safe. The thing that isn't safe is users attempt to resolve
> host names that they are incapable of resolving. We should not pollute
> the root servers with such queries and we should fail closed to
> protect users.

OK so that's less dramatic than what Mark appeared to think if
implementations do not obey this spec that they're not necessarily
going to read.

> The mere queries of the label may be problematic as we
> explained in our RFC...
> 
> We explained this in RFC7686 - if you read it and it is unclear, I'm
> happy to clarify further; I'd rather not repeat that RFC in full
> here...

I've mostly spent time on the parts that were declaring existing
implementations non-compliant if they didn't apply these new rules, I
didn't read everything.

> Could you propose a counter proposal for how to keep users safe as we
> have done in RFC7686?
> 
> I'd be happy to support such an RFC and in two years, we'll probably
> have a similar discussion about your proposal from different
> stakeholders. :-(

No but I'm not going to play that game consisting in saying "look I did
my part of the job, if it doesn't suit you please provide something better".
I'm not the guy in charge for this protocol, I'm not the one responsible
for finding and validating all the possibilities. All I'm seeing is that
it declares suddenly non-compliant some components that previously were
compliant and that it's not the best way to get a standard applied for
real in field.

> > 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.
> 
> And when a browser pre-fetches a list of urls, did the user know they
> were a .onion user? No, of course not. There are dozens of similar
> situations. We solve a real problem with RFC7686 and browsers, as well
> as other software, have a duty of care to implement the solution. It
> is a free choice, of course. There are no RFC police, only software
> that is compliant with relevant RFCs or not.

Except that here it's mandated that software that does not implement
the protocol must comply with this spec for the sake of the protocol.
That's quite a confusing approach.

Regards,
Willy

Received on Saturday, 28 November 2015 22:53:20 UTC