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

[Ted Lemon <[e-mail]>]

El 14 ag 2017, a les 7:30, Mike West <[e-mail]> va escriure:
> I've uploaded an -05 draft (diff to -04) that addresses some of the feedback in this thread, Ted Lemon's in particular. It attempts to spell out the rationale for the NXDOMAIN change more clearly, boiling it down to Ted's suggestion that we ought to be recommending that stub resolvers fail closed when they forward requests for localhost names on to recursive resolvers.

This doesn't actually address my concerns.   Sorry to be a sticky wicket.   Here is what I think the text should say:

OLD:
    This document updates RFC6761 with the goal of ensuring that
    "localhost" can be safely relied upon as a name for the local host's
    loopback interface.  To that end, stub resolvers are required to
    resolve localhost names to loopback addresses.  Recursive DNS servers
    are required to return "NXDOMAIN" when queried for localhost names,
    which will cause non-conformant stub resolvers to fail safely closed.
    Together, these requirements would allow applications and
    specifications to join regular users in drawing the common-sense
    conclusions that "localhost" means "localhost", and doesn't resolve
    to somewhere else on the network.

NEW:
    This document updates RFC6761 with the goal of ensuring that
    "localhost" can be safely relied upon as a name for the local host's
    loopback interface.  To that end, stub resolvers are required to
    resolve localhost names to loopback addresses.  Recursive DNS servers
    are required to return "NXDOMAIN" when queried for localhost names,
    making non-conformant stub resolvers more likely to fail and produce
    problem reports that result in updates.
    Together, these requirements would allow applications and
    specifications to join regular users in drawing the common-sense
    conclusions that "localhost" means "localhost", and doesn't resolve
    to somewhere else on the network.


OLD:
    This document hardens [RFC6761]'s recommendations regarding
    "localhost" by requiring that name resolution APIs and libraries
    themselves return a loopback address when queried for localhost
    names, bypassing lookup via recursive and authoritative DNS servers
    entirely.  Further, recursive and authoritative DNS servers are
    required to return "NXDOMAIN" for such queries, ensuring that non-
    conformant stub resolvers will fail safely.
NEW:
    This document updates [RFC6761]'s recommendations regarding
    "localhost" by requiring that name resolution APIs and libraries
    themselves return a loopback address when queried for localhost
    names, bypassing lookup via recursive and authoritative DNS servers
    entirely.

    In addition, recursive and authoritative DNS servers are
    required to return "NXDOMAIN" for such queries.   This increases the
    likelihood that non-conformant stub resolvers will not go undetected.
    Note that this does not have the result that such resolvers will
    fail safe—it just makes it more likely that they will be detected
    and fixed, since they will fail in the presence of conforming
    name servers.

    These changes are not sufficient to ensure that "localhost" can
    be assumed to actually refer to an address on the local machine.
    This document therefore further requires that applications that
    wish to make that assumption handle the name "localhost" specially.

OLD:
        If application software wishes to make security decisions based
        upon the assumption that localhost names resolve to loopback
        addresses (e.g. if it wishes to ensure that a context meets the
        requirements laid out in [SECURE-CONTEXTS]), then it SHOULD avoid
        relying upon name resolution APIs, instead performing the
        resolution itself.  If such software chooses to rely on name
        resolution APIs, it MUST verify that the resulting IP address is
        a loopback address before making a decision about its security
        properties.
NEW:
        If application software wishes to make security decisions based
        upon the assumption that localhost names resolve to loopback
        addresses (e.g. if it wishes to ensure that a context meets the
        requirements laid out in [SECURE-CONTEXTS]), then it MUST
	directly translate the name "localhost" to an IP address that
        connects locally, and MUST NOT rely upon name resolution APIs.
        
The text about checking the address returned by the API doesn't make sense—it's easier to just do the translation, and so an application that doesn't do the translation isn't going to check.   Keep it simple.

OLD:
        In any event, application software MUST NOT use a searchlist to
        resolve a localhost name.  That is, even if DHCP's domain search
        option [RFC3397] is used to specify a searchlist of "example.com"
        for a given network, the name "localhost" will not be resolved as
        "localhost.example.com", and "subdomain.localhost" will not be
        resolved as "subdomain.localhost.example.com".
NEW:
        Application software MUST NOT use a searchlist to
        resolve a localhost name.  That is, even if DHCP's domain search
        option [RFC3397] is used to specify a searchlist of "example.com"
        for a given network, the name "localhost" will not be resolved as
        "localhost.example.com", and "subdomain.localhost" will not be
        resolved as "subdomain.localhost.example.com".

(For consistency with previous change)

On the topic of DNSSEC, the root currently returns a secure denial of existence.   This is exactly right—there's no reason to change it.

You need a security considerations section.   I suggest the following:

---
Some applications may consider it useful to treat a connection to an endpoint on the same host as more trustworthy than a connection to other endpoints.   This assumption is not entirely safe—it is possible for example that an application that is sandboxed could still listen for connections from the local host, and thereby present a security vulnerability to other applications that mistakenly assume that some other service is listening for connections on that port.  A similar risk can be present for a sandboxed application connecting to localhost if the local host is infected by malware that listens on a particular local port.   Such situations may be considered out of scope, however, in the sense that if malware is running on the local host, it may have easier opportunities for attack than listening for connections on a local port.   The sandbox example is mentioned because malware that successfully attacks a sandboxed application may still be contained in the sandbox; trusting localhost in this case could penetrate that protection.

Applications that attempt to use the local resolver to query "localhost" do not fail safe: if an attacker sets up a DNS server returning a non-local answer for "localhost," such applications will connect to that remote server assuming it is local.   This is the reason for the requirement that applications using "localhost" process it specially, rather than relying on the local resolver.   

There may be cases where the target runtime environment is such that it can be safely assumed that the local resolver does the right thing; in this case the requirement that the application do the translation on its own may be safe to ignore, but only if all of the requirements under point 2 of section 3 are known to be followed by the resolver that is known to be present in the target runtime environment.
---

The first paragraph is rather tendentious.   My reason for presenting it is not to claim that you should put that exact text in the security considerations section, but rather to suggest that this is possibly something that the working group should consider doing if the document is adopted, as seems likely.   My personal opinion is that trusting localhost is a bad idea, but I realize that this may not be the consensus.