On Wed, Aug 2, 2017 at 8:48 AM, Ted Lemon <mel...@fugue.com> wrote: > On Aug 2, 2017, at 8:40 AM, Richard Barnes <r...@ipv.sx> 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.)
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
