Treat `*.local.` as link-local.

[mikewest]

As per https://tools.ietf.org/html/rfc6762.

[mnot]

Note that this may or may not happen one day: https://www.ietf.org/archive/id/draft-cheshire-homenet-dot-home-02.txt

Background: https://tools.ietf.org/wg/homenet/charters

[letitz]

Looks like .home.arpa. is the new .home, per RFC 8375.

[mikewest]

I don't recall why I filed this bug, but at the moment I'm not sure that looking at anything other than the IP address of the socket connection is a reasonable thing to do. Would it be helpful to do this? Is it possible for these TLDs to resolve outside of the private IP ranges?

[letitz]

We already look at the scheme part of the origin to special-case file: URLs, so we have the machinery in place to inspect the domain name as well. Thus this seems reasonable to consider.

As for whether it is helpful, that's a good question, which I will try to answer in two parts:

1. Is it superfluous? Do .local domains always resolve to private IP addresses? I just skimmed through RFC 6762 again and I can't find anything saying that the IP addresses resolved from .local domains must be link-local themselves. At most I found that the reverse DNS mappings use link-local IP address prefixes.

2. Is it useful? No idea! I think we should get some data on this point to make a decision. Namely, we should try to answer the question: How often does this case come up?

[jschuh]

Perhaps this is a dumb idea, but should we be treating any qualified DNS hostname not on the TLD list as private by default?

[mikewest]

These two questions seem to boil down to the same thing to me:

Should we be treating any qualified DNS hostname not on the TLD list as private by default? ... Is it useful?

I don't think it is. There's nothing preventing a coffee shop's DNS resolver (which you'll be using because DHCP) from resolving *.justin domains to any IP address, public or private. It seems reasonable to simply look at the IP address rather than the domain in these cases. I don't understand what special-casing certain TLDs would buy us?

(Note: Separately, I think host-based matching is likely going to be something we need for enterprisey deployments, where folks are hosting "intranet" stuff on various public services (AWS, Azure, Cloud, etc). I'd suggest, though, that we rely on enterprise policy for these decisions rather than baking certain suffixes into the spec.)

[jschuh]

Well, the coffee shop's DNS resolver in the scenario you describe is in fact resolving private names (because they're not registerable), so it seems like a reasonable argument for treating them as private. Yes, this is a belt-and-suspenders approach where the set of what is private is the union of both addresses and hostnames the browser can infer as private, but I see some value in defaulting to the least permissive approach.

+1 on the enterprise policy for anything more complex/finer-grained than the defaults. I had always assumed that would be necessary, but I can't recall if it was captured anywhere.

[annevk]

Unless private to private communication is always preflighted, wouldn't that allow novel attacks if you can manipulate DNS somehow? (I think it would be ideal if it was always preflighted, but it's not clear how realistic that is.)

[letitz]

Yeah, the proposal is a double-edged sword:

• public websites cannot make malicious requests to totally-private.justin anymore
• totally-private.justin can make all the requests it wants to router.local

[jschuh]

Reasoning through this, to stage such an attack you need to control DNS resolution (or the equivalent). E.g. let's assume I share my ISP with a malicious party, and there's insufficient segmentation, such that the attacker can hijack DHCP resolution and act as my DNS resolver. At that point, the attacker can now have their own hosts treated as private.

I'm honestly a bit doubtful at the viability of that sort of attack vector. However, given that both IPv4 and IPv6 have defined private address ranges, I appreciate that opportunistically making hosts private based on their qualified name would be largely redundant, and thus not worth the risk anyway.

So, I'll drop it, and note that I did open with a clear "perhaps this is a dumb idea" clause.

[DavidSchinazi]

If this specification doesn't treat *.local as private, it won't actually protect users. The first example in the spec (router.local) will commonly resolve over both IPv4 and IPv6. In that scenario, most users will use RFC1918 space for IPv4 and globally reachable addresses for IPv6 (for example, router.local will resolve to both 10.1.1.1 and 2604:5eda:c1ed:add5::1). In that scenario, modern Web browsers will prefer IPv6 and connect to the globally reachable IPv6 address, completely bypassing these protections.