El 14 ag 2017, a les 7:30, Mike West <[email protected]> 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.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
