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

[Ted Lemon <[e-mail]>]

On Wed, Aug 9, 2017 at 12:31 PM, Stuart Cheshire <[e-mail]> wrote:

> [*] If you think it’s stupid to suggest a host might not treat “127.0.0.1”
> as meaning loopback, why is that any more stupid than suggesting that a
> host might not treat “localhost” as meaning loopback? Both are just as
> arbitrary.


The reason is that we understand the process by which names are resolved,
and we understand the process by which addresses are configured.   You
likely have only one IP stack on your host.   You may have dozens of stub
resolvers.   So the stub resolvers are a target-rich environment for
failure, and they fail unsafe, not safe: by default, they go to the DNS
protocol to resolve names.   If the implementor assumes the DNS will return
127.0.0.1 or ::1, as indeed they tend to do, then they may not think to
read the RFC that says "you need a special case for localhost."

On the other hand, suppose that ::1 doesn't work on your host.   What
happens is that the network transaction fails.   This is a much better
outcome than connecting to an endpoint that is not on the local host,
assuming that it is, and making safety assumptions on the basis that it is.
  Suppose ::1 is configured to connect to an external host.   Well, a ton
of stuff is going to break, and it's going to be really obvious that it's
broken.   You may still experience some negative consequences, but this is
a much more detectable situation, because a lot more things will break.

Of course, the real answer to this is that neither solution is desirable.
I've heard several people here say that if localhost were "fixed" in an
RFC, then the W3C could mark http connections to localhost as secure,
rather than insecure.   This is of course nonsense.   The fact is that you
should always validate the endpoint you are connecting to using some secure
protocol.   With a unix domain socket, you can pass credentials over the
socket.   With a TCP or UDP connection, you can't do that, so you need to
use cryptography.   This is a problem for connections to localhost, of
course, since you can't get a cert for it, but that's probably okay.   A
better test for localhost for W3C is that if the page you are looking at
came from localhost and refers to localhost, *AND* the software that's
making the secure/not judgment is also doing name resolution, and it
implements the RFC we are talking about here, then it can assume that
resources addressed using http://localhost are both secure and
confidential.   Otherwise not (a web page referencing localhost that wasn't
served by localhost should be treated as an attack, for example).