Re: [DNSOP] Status of "let localhost be localhost"?

[Richard Barnes <[e-mail]>]

On Wed, Aug 2, 2017 at 8:48 AM, Ted Lemon <[e-mail]> wrote:

> On Aug 2, 2017, at 8:40 AM, Richard Barnes <[e-mail]> wrote:
>
> The underlying need here is that application software would like to make
> use of the fact that it is connecting to "localhost" (vs. other domain
> names) to make security decisions based on whether traffic is going to
> leave the host.  So if the network layer remaps localhost to something
> other than a loopback interface without telling the applications, then
> you're going to have security problems.
>
> The point of this document is to avoid this disconnect by discouraging the
> sorts of remappings you're talking about.
>
>
> Of course, arguably this is the wrong approach.   Perhaps the right
> approach is to understand that the security characteristics of "localhost"
> are not the ones that we want when our goal is to be sure we are connecting
> to the local host.   Apps don't control the name resolution software that's
> running on the local host.   If they want to be sure they are connecting
> locally, perhaps they should be using ::1 instead of localhost as their
> explicit destination identifier.
>

This is indeed what happens today.

https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy

But of course having IP addresses in URLs is both a PITA for developers and
an anti-pattern more generally.

If "localhost" were properly defined to be loopback, then applications
could just hard-wire resolution, and not depend on the good graces of the
platform resolver.  As, for example, Firefox does with ".onion" today:

http://searchfox.org/mozilla-central/source/netwerk/dns/nsDNSService2.cpp#708

(The "localhost" stuff in that method is unrelated to this discussion BTW;
it relates to a Firefox-internal mapping of other domains to localhost.)