On Wed, Aug 9, 2017 at 12:31 PM, Stuart Cheshire <chesh...@apple.com> 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).
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
