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

[Mike West <[e-mail]>]

On Wed, Aug 2, 2017 at 3:02 PM, Richard Barnes <[e-mail]> wrote:

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

I was typing basically this when Richard's message came in. So I'll simply
add that Problem 8 in https://tools.ietf.org/html/draft-ietf-sunset4-
gapanalysis-09#section-5 suggests that we already know that this kind of
hard-coding will cause issues for future migrations. Just as we'd like to
discourage folks from hard-coding `127.0.0.1` to be certain that they're
talking to the loopback interface, it seems reasonable to discourage folks
from hard-coding `::1`.

-mike