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

From: Mike West <[email-masked]>
Date: Tue, 1 Aug 2017 12:48:51 +0200

Hey Jacob, thanks for flagging this! I'm also interested in getting this
draft moving again, and I'm willing to poke at it in whatever ways the
group's happy with.

The only open issue I know of is some discussion in the thread at
https://www.ietf.org/mail-archive/web/dnsop/current/msg18690.html that I
need help synthesizing into the draft. I don't know enough about the
subtleties here to have a strong opinion, and I'm happy to accept the
consensus of the group.

Coincidental, I raised the draft again briefly with a few folks in Prague
(CC'd here), and I'm hoping for some feedback about reasonable next steps.

-mike

On Tue, Aug 1, 2017 at 1:17 AM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> Hi,
>
> I'm interested in seeing
> https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-03
> move from draft status to become a standard. In particular, it would
> allow browsers to start treating "localhost" as a secure context, which
> would reduce attempts by application developers to abuse the public Web
> PKI in order to issue certificates for localhost, which harms security.
> See:
>
> https://groups.google.com/d/msg/mozilla.dev.security.
> policy/T6emeoE-lCU/-k-A2dEdAQAJ
> https://groups.google.com/d/msg/mozilla.dev.security.policy/eV89JXcsBC0/
> wsj5zpbbAQAJ
>
> What further steps are needed to move this draft along, and how can I help?
>
> Thanks,
> Jacob
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 1 Aug 2017 11:59:42 -0700

> subtleties here to have a strong opinion, and I'm happy to accept the

Reading back through this thread, it seems like the concerns were about
how to represent the  ".localhost" TLD in the root zone, or how to use
DNSSEC to express that the root zone will not speak for ".localhost".
However, I think we don't need either. This draft attempts to codify the
idea that queries for "localhost" or "foo.localhost" should never leave
the local system, and so it doesn't matter what the root zone says about
".localhost".

I would even take it a step further: It would be a mistake to add any
records for ".localhost" to the root zone, because it would mask
implementation errors. If a local resolver accidentally allows a query
for "foo.localhost" to hit the wire, it should result in an error.

IMHO, the document is good as it stands.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Aug 2017 11:23:45 +1000

> IMHO, the document is good as it stands.

The query for foo.localhost doesn't need to hit-the-wire for this
to be a issue.  Ask your self why RFC 6303, Security section has

   As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
   namespaces, the zones listed above will need to be delegated as
   insecure delegations, or be within insecure zones.  This will
   allow DNSSEC validation to succeed for queries in these spaces
   despite not being answered from the delegated servers.

or draft-ietf-homenet-dot-10 is doing the same thing for "home.arpa".

We didn't add the requirement for insecure delegations for the fun
of it.  We added it so that the tools that validate will not break
when those names are being used.

The only difference between the names in the above documents and
.localhost is the size of the space where they are valid.  It is
restricted to the node rather than the site.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mike West <[email-masked]>
Date: Wed, 2 Aug 2017 10:54:50 +0200

> restricted to the node rather than the site.

Thanks for the feedback, Mark!

What would you like to see in the document in order to address this
concern? A requirement that a `localhost` zone be created and delegated as
an insecure delegation, using some of the language from the draft above
(e.g. "This delegation MUST NOT be signed, MUST NOT include a DS record,
and MUST point to one or more black hole servers, for example '
blackhole-1.iana.org.' and 'blackhole-2.iana.org.'.")?

-mike

---

From: william manning <[email-masked]>
Date: Wed, 2 Aug 2017 03:39:47 -0700

localhost is just a string, like www or mail or supralingua.  A DNS
operator may
chose to map any given string to any given IP address.  restricting  ::1
 so that it never leaves
the host is pretty straight forward.  if I map localhost to
3ffe::53:dead:beef and NOT ::1 in my
systems, why should you care?
if you are concerned that completion logic is broken in resolvers and the
string "localhost" is not
appended to the domain, then you really are asking for the root servers to
backstop the query with
an entry for localhost.  and for the first 20 years of the DNS, there was
an entry for localhost. in
many of the root servers.  it was phased out for several reasons, two key
ones were DNSSEC and
the fact that most resolvers had corrected their broken completion logic.
There is no good reason to bring it back for special processing.  It's just
a string.

/Wm

---

From: Richard Barnes <[email-masked]>
Date: Wed, 2 Aug 2017 08:40:32 -0400

> systems, why should you care?

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.

--Richard

> There is no good reason to bring it back for special processing.  It's
> just a string.
>
> /Wm
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Aug 2017 08:48:24 -0400

On Aug 2, 2017, at 8:40 AM, Richard Barnes <[email-masked]> 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.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 2 Aug 2017 09:02:26 -0400

On Wed, Aug 2, 2017 at 8:48 AM, Ted Lemon <[email-masked]> wrote:

> 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.)

---

From: Mike West <[email-masked]>
Date: Wed, 2 Aug 2017 15:07:43 +0200

On Wed, Aug 2, 2017 at 3:02 PM, Richard Barnes <[email-masked]> wrote:

>> The point of this document is to avoid this disconnect by discouraging
>> the sorts of remappings you're talking about.
>>
>>
> But of course having IP addresses in URLs is both a PITA for developers
> and an anti-pattern more generally.
>

I was typing basically this when Richard's message came in. So I'll simply
add that Problem 8 in https://tools.ietf.org/html/draft-ietf-sunset4-
gapanalysis-09#section-5 suggests that we already know that this kind of
hard-coding will cause issues for future migrations. Just as we'd like to
discourage folks from hard-coding `127.0.0.1` to be certain that they're
talking to the loopback interface, it seems reasonable to discourage folks
from hard-coding `::1`.

-mike

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Aug 2017 09:10:45 -0400

On Aug 2, 2017, at 9:02 AM, Richard Barnes <[email-masked]> wrote:
> But of course having IP addresses in URLs is both a PITA for developers and an anti-pattern more generally.

While true, I would argue that this is actually a problem.   E.g., I actually literally cannot surf to a link-local URL without having a DNS record for it, because http://[ <http://%5Bfe80::1806:ec37:3d5f:9580%25en0%5D/>fe80::1806:ec37:3d5f:9580%en0]/ <http://%5Bfe80::1806:ec37:3d5f:9580%25en0%5D/> has an interface identifier in it, and modern browsers consider this an anti-pattern, I guess.   And you don't want to put link-local addresses in DNS, even if it made sense to do so, so what is one to do?   I'm not convinced that this anti-pattern is the wrong anti-pattern, but here we have two examples of it being problematic, in the least.

> 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:

Right.   But there was actually a long discussion on why that's problematic when we were doing the .onion RFC.   The reason is that one can't count on any particular piece of application software correctly interpreting the rightmost label.   We can write RFCs encouraging it, but if I am writing a URL into a piece of HTML, I have no idea whether the thing that interprets the HTML will or will not do the right thing.

We just accept that as a risk with .onion because we don't have a better option, but for localhost we definitely do have a better option.   That's all I'm saying.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Aug 2017 09:17:26 -0400

On Aug 2, 2017, at 9:07 AM, Mike West <[email-masked]> wrote:
> I was typing basically this when Richard's message came in. So I'll simply add that Problem 8 in https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09#section-5 <https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09#section-5> suggests that we already know that this kind of hard-coding will cause issues for future migrations. Just as we'd like to discourage folks from hard-coding `127.0.0.1` to be certain that they're talking to the loopback interface, it seems reasonable to discourage folks from hard-coding `::1`.

I don't think I agree.   It's entirely possible that at some future time, [::1] will have symbolic meaning but will not refer to a transport protocol destination address.   But we are arguing that "localhost" should be treated specially by every piece of software that looks at it, when its default meaning is "look up localhost in the DNS and connect to one of the addresses that you get in response."   The default meaning of "[::1]" is "connect to the local host."   There isn't even an implicit indirection there.

So if you have a host running IPv10, where [::1] doesn't have an explicit meaning, one of two things will be the case: either the piece of software looking at [::1] will do an explicit transformation from [::1] to the right thing, or it won't.   If it does, things just work.   If it doesn't, they fail safe: the connection fails.   With localhost, if the software does the wrong thing, it does not fail safe.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 2 Aug 2017 09:18:25 -0400

On Wed, Aug 2, 2017 at 9:10 AM, Ted Lemon <[email-masked]> wrote:

> While true, I would argue that this is actually a problem.   E.g., I
> actually literally cannot surf to a link-local URL without having a DNS
> record for it, because http://[
> <http://%5Bfe80::1806:ec37:3d5f:9580%25en0%5D/>fe80::1806:ec37:3d5f:
> 9580%en0]/ <http://%5Bfe80::1806:ec37:3d5f:9580%25en0%5D/> has an
> interface identifier in it, and modern browsers consider this an
> anti-pattern, I guess.   And you don't want to put link-local addresses in
> DNS, even if it made sense to do so, so what is one to do?   I'm not
> convinced that this anti-pattern is the wrong anti-pattern, but here we
> have two examples of it being problematic, in the least.
>
> Right.   But there was actually a long discussion on why that's
> problematic when we were doing the .onion RFC.   The reason is that one
> can't count on any particular piece of application software correctly
> interpreting the rightmost label.   We can write RFCs encouraging it, but
> if I am writing a URL into a piece of HTML, I have no idea whether the
> thing that interprets the HTML will or will not do the right thing.
>

The point you're missing here is that the application is both the thing
relying on the definition of "localhost" and the thing empowered to enforce
the RFC.  If the application doesn't care whether "localhost" resolves to
anything special, then it can pass it to the platform and take its
chances.  If it does, it can hard-wire it to loopback.

> We just accept that as a risk with .onion because we don't have a better
> option, but for localhost we definitely do have a better option.   That's
> all I'm saying.
>

Using IP addresses is not a better option.

--Richard

---

From: Joe Abley <[email-masked]>
Date: Wed, 2 Aug 2017 14:34:15 +0100

Hi Mike,

On Aug 2, 2017, at 09:54, Mike West <[email-masked]> wrote:

> What would you like to see in the document in order to address this concern? A requirement that a `localhost` zone be created and delegated as an insecure delegation, using some of the language from the draft above (e.g. "This delegation MUST NOT be signed, MUST NOT include a DS record, and MUST point to one or more black hole servers, for example 'blackhole-1.iana.org.' and 'blackhole-2.iana.org.'.")?

Any such delegation would be lame, and is a bad idea just for that reason. There's no foolproof way to add or drop zones hosted on the whole AS112 server ssystem due to the lack of coordination between AS112 node operators -- despite the good communication between many such operators, there's no good way to tell what nodes you don't know about.

If you really wanted to sink queries in the top-level domain LOCALHOST a better approach would to use DNAME (see RFC 7535). But note that I'm not expressing an opinion on whether that's a good idea, either philosophically or practically, in this specific example.

Joe

---

From: Richard Barnes <[email-masked]>
Date: Wed, 2 Aug 2017 09:38:12 -0400

On Wed, Aug 2, 2017 at 9:34 AM, Joe Abley <[email-masked]> wrote:

> Any such delegation would be lame, and is a bad idea just for that reason.
> There's no foolproof way to add or drop zones hosted on the whole AS112
> server ssystem due to the lack of coordination between AS112 node operators
> -- despite the good communication between many such operators, there's no
> good way to tell what nodes you don't know about.
>
> If you really wanted to sink queries in the top-level domain LOCALHOST a
> better approach would to use DNAME (see RFC 7535). But note that I'm not
> expressing an opinion on whether that's a good idea, either philosophically
> or practically, in this specific example.
>

It seems like the desired behavior for the DNS infrastructure here is the
same as for .onion -- return NXDOMAIN.  After all, these are queries that
should never leave the end host, so anything not on the host should handle
them as an error.

cf. https://tools.ietf.org/html/rfc7686#section-2

---

From: Mike West <[email-masked]>
Date: Wed, 2 Aug 2017 15:44:03 +0200

On Wed, Aug 2, 2017 at 3:38 PM, Richard Barnes <[email-masked]> wrote:

>> Any such delegation would be lame, and is a bad idea just for that
>> reason. There's no foolproof way to add or drop zones hosted on the whole
>> AS112 server ssystem due to the lack of coordination between AS112 node
>> operators -- despite the good communication between many such operators,
>> there's no good way to tell what nodes you don't know about.
>>

I'm pretty sure this is what the draft we're discussing attempts to do. See
#2 under
https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-03#section-3.
It could be more explicit about the response, however... I can address that
in a -04 if folks agree with the approach.

(I also wonder whether it would be a better idea to reframe this draft as
something akin to the "onion" RFC: that is, defining the behavior as a
stand-alone document rather than monkey-patching RFC 6761.)

-mike

---

From: Joe Abley <[email-masked]>
Date: Wed, 2 Aug 2017 14:48:21 +0100

Wow. That was horribly-formatted. Apologies for the iPad MIME-crime.

> On Aug 2, 2017, at 14:34, Joe Abley <[email-masked]> wrote:
> 
> Hi Mike,
> 
> What would you like to see in the document in order to address this concern? A requirement that a `localhost` zone be created and delegated as an insecure

[...]

---

From: Richard Barnes <[email-masked]>
Date: Wed, 2 Aug 2017 09:58:44 -0400

On Wed, Aug 2, 2017 at 9:18 AM, Richard Barnes <[email-masked]> wrote:

>> <http://%5Bfe80::1806:ec37:3d5f:9580%25en0%5D/>fe80::1806:ec37:3d5f:9
>> 580%en0]/ <http://%5Bfe80::1806:ec37:3d5f:9580%25en0%5D/> has an

To address the concerns of HTML authors here:

As with any change to web semantics, this introduces a challenge for web
developers because different versions of browsers will interpret things
differently.  For example, if the W3C Secure Contexts spec changes to treat
"localhost" URLs as secure, and browsers implement that, then if you load "
http://localhost" in a new browser, it will be get access to certain APIs
that it wouldn't on earlier versions.

Two points here:

1. It's up to the browsers to make this transition fail safe, in the sense
that if you write code that depends on "localhost" being secure, then your
code will break if the browser is not going to ensure that "localhost" is
loopback.  This is what the Secure Contexts spec is for, and the gist of my
comments above.

2. Web developers have to deal with this sort of incompatibility all the
time anyway, because their sites are accessed by many different browsers
with different capabilities.

In other words, there's only breakage risk here (not security risk), only
for new things, and not any worse than web developers already have to deal
with.

And based on the feedback from web developers so far, the risk of breakage
is strongly preferred to the pain of hard-coding IP addresses.

--Richard

---

From: Tony Finch <[email-masked]>
Date: Wed, 2 Aug 2017 15:26:46 +0100

Ted Lemon <[email-masked]> wrote:
>
> And you don't want to put link-local addresses in DNS, even if
> it made sense to do so, so what is one to do?

As far as I know it isn't even possible :-)

(Some time ago I investigated support for link-local addresses in stub
resolvers, and I found that it was usually broken or nonexistent. A common
bug is to squash the recursive server into a 128 bit v6 address and 16 bit
port, omitting any interface ID.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
North Utsire, South Utsire: Southwesterly 3 or 4, backing southerly or
southeasterly 5 to 7, perhaps gale 8 later in South Utsire. Slight becoming
moderate. Showers then rain. Moderate or good.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 02 Aug 2017 07:45:13 -0700

william manning wrote:
> ...
> if you are concerned that completion logic is broken in resolvers
> and the string "localhost" is not appended to the domain, then you
> really are asking for the root servers to backstop the query with an
> entry for localhost. and for the first 20 years of the DNS, there was
> an entry for localhost. in many of the root servers. it was phased
> out for several reasons, two key ones were DNSSEC and the fact that
> most resolvers had corrected their broken completion logic. There is
> no good reason to bring it back for special processing. It's just a
> string.

+1.

-- 
P Vixie

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 2 Aug 2017 10:24:05 -0700

> or draft-ietf-homenet-dot-10 is doing the same thing for "home.arpa".

RFC 6303 says "as DNSSEC is deployed within...". There's no plan to
deploy DNSSEC within .localhost, because it doesn't make sense there;
all resolutions should be handled locally.

> when those names are being used.

Can you tell me more about what type of tools you're thinking of here?
Are those tools expected to handle "foo.localhost" domains? If so, what
do they currently do with such domains?

To put it another way: is your concern about new potential for breakage
under this draft, or are you saying that there is existing breakage that
we might as well fix as long as we are touching ".localhost"?

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 2 Aug 2017 14:02:21 -0400

Ted Lemon wrote:
> But we are arguing that "localhost" should be treated specially by every piece of software that looks at it, when its default meaning is "look up localhost in the DNS and connect to one of the addresses that you get in response."

RFC 6761 §6.3 already says that "localhost" should be treated specially
by pretty much every piece of software that looks at it. But especially:

   2.  Application software MAY recognize localhost names as special, or
       MAY pass them to name resolution APIs as they would for other
       domain names.

   3.  Name resolution APIs and libraries SHOULD recognize localhost
       names as special and SHOULD always return the IP loopback address
       for address queries and negative responses for all other query
       types.  Name resolution APIs SHOULD NOT send queries for
       localhost names to their configured caching DNS server(s).

(In practice, "localhost" already does get treated specially, especially
by operating systems that place a "Name Service Switch" or similar
component in front of the DNS stub resolver. If you put
"http://localhost/" into your browser bar, you shouldn't see a DNS query
for "localhost" leave your machine.)

Doesn't "Application software MAY recognize localhost names as special"
already give more than enough permission for browser developers to treat
"localhost" (and any subdomain of "localhost") specially, for instance
by hardcoding the names to a loopback address, or filtering the result
from the system's name resolver to verify that only a loopback address
is used? Or only allowing the "Secure Context" flag to be set when the
localhost name resolves to a loopback address.

draft-west-let-localhost-be-localhost-03 upgrades the requirements in
RFC 6761 §6.3 to make them much stricter, for all applications,
converting SHOULDs to MUSTs, etc. So we're not arguing about whether
localhost "should" be treated specially, but whether it MUST be treated
specially, by all applications. Can the W3C not impose stricter
requirements on browser developers even if 6761 doesn't impose mandatory
treatment for "localhost"?

Maybe a smaller addition to RFC 6761 §6.3 would be sufficient for the
W3C? Something like:

    Application software specifications MAY require that application
    software recognize localhost names as special.

But that seems weird because it's arguably just a specific case of
requirement #2.

-- 
Robert Edmonds

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 2 Aug 2017 15:09:35 -0400

> all resolutions should be handled locally.

6303 is talking about what to do with DNS zones for RFC1918 and other
local-scope address space when their global-scope parent zones are signed.
The correct rephrasing of that quote which would apply to .localhost is "as
DNSSEC is deployed within the root namespace..."  An event which is long
past.

In the case where 'localhost' is being passed to DNS resolution software, a
validating stub (for example inside a web browser) needs a way to know that
the 'localhost' TLD should be treated as insecure.  In that case, the only
way to accomplish that is with an insecure delegation at the root.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Aug 2017 16:27:45 -0400

> treatment for "localhost"?

It should be MUST in both cases.   But writing that in an RFC doesn't make it so.   Bear in mind when you look at the W3C document that it is talking about what would be ideal, not what is actually present in browsers.

As an app developer worried about security footprint, I would be wiser to be cautious and use ::1 or 127.0.0.1, rather than using localhost and relying on the name resolution infrastructure.   But the use case that I would be most skeptical about is using localhost in a URL.   I think that should be MUST NOT.   Apparently there is not wholehearted agreement on this topic, however... :)

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 2 Aug 2017 14:06:20 -0700

On 08/02/2017 12:09 PM, Matthew Pounsett wrote:
> In the case where 'localhost' is being passed to DNS resolution
> software, a validating stub (for example inside a web browser)
Ah, this may be where we are finding a disconnect. I believe web
browsers never operate validating stub resolvers, but generally ask the
operating system resolver library. Do you have a counter-example?

I think it's also rare for operating system resolver libraries to
validate DNSSEC (rather than leaving it to an upstream recursive
resolver). However, even if we take it as a given that operating system
stub resolvers should implement DNSSEC validation, they clearly already
treat localhost specially, so there is no reason to believe that they
would start trying to validate it with DNSSEC once this document is
finalized.

---

From: George Michaelson <[email-masked]>
Date: Thu, 3 Aug 2017 08:55:41 +1000

A possibly stupid random thought: is there a strong barrier in *all*
kernels which enforces 127.0.0.0/8 and ::1 to actually *have* to be
local?

The 240/4 problem is 5-6 lines of code in *some* UNIX. It wasn't in
any sense globally applied.

I suspect localhost is somewhat more strongly coded, but I did wonder
because Ted's suggestion that use of the literal IP address in either
family would the stronger 'keep it local' made me think: what if
somebody hand installed a route which somehow took it off-box?

I think proscriptive/definitive language over the FQDN/label localhost
in DNSSEC is probably still a good thing.  IETF is defining behaviours
for home.arpa in HOMENET which logistically fall into a very similar
bucket (for me at least) so its not like we can't chose to say what
behaviours we expect of a label.

-G

---

From: Richard Barnes <[email-masked]>
Date: Wed, 2 Aug 2017 19:27:40 -0400

On Wed, Aug 2, 2017 at 4:27 PM, Ted Lemon <[email-masked]> wrote:

> It should be MUST in both cases.   But writing that in an RFC doesn't make
> it so.   Bear in mind when you look at the W3C document that it is talking
> about what would be ideal, not what is actually present in browsers.
>
> As an app developer worried about security footprint, I would be wiser to
> be cautious and use ::1 or 127.0.0.1, rather than using localhost and
> relying on the name resolution infrastructure.   But the use case that I
> would be most skeptical about is using localhost in a URL.   I think that
> should be MUST NOT.   Apparently there is not wholehearted agreement on
> this topic, however... :)
>

You have this backwards.  Browser today do take the more cautious, IP-based
approach.  It sucks for developers.  They want to be able to use
"localhost", but in order to do it safely, they will need to hard-wire it
internally (since as you say, writing an RFC doesn't make resolvers
change).  And they don't want to hard-wire unless that's the clear semantic
because standards are what make the web work.

--Richard

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Aug 2017 09:39:21 +1000

In message <[email-masked]>, Jacob Hoffman-Andrew
> would start trying to validate it with DNSSEC once this document is

The deployment goal of DNSSEC was to have *every* machine/application
validating DNSSEC responses or to have a crytographically secure
path to one that did for which you knew and accepted its security
policy.  DNSSEC was designed with this in mind.  DNSSEC also requires
recursive servers to validate responses or else you can't handle
certain threats DNSSEC is designed to handle.  Turning on DNSSEC
in resolvers also provides some protection from some threats to
non-validating clients.  Getting validation turned on in recursive
servers is the first step in this multi-year plan.  We are at about
the 60% level for recursive servers and a few percent (maybe) for
the machine/application level.

Most OS's don't treat localhost specially.  It is just a entry in
/etc/hosts and/or a zone in the local recursive server and/or
localhost.<zone> in a zone on the search list.  The last of these
is how localhost is actually resolved on my machine (MacOS 10.12.6)
as the resolver doesn't treat "localhost" as special.  It's processed
the same way as any other single label name.

When you look at foo.localhost the resolution mechanisms /etc/hosts
and/or a zone in the local recursive server.  If you are mad you
apply the search list.

Mark

---

From: Mike West <[email-masked]>
Date: Thu, 3 Aug 2017 12:51:50 +0200

It seems like there's clear agreement that `localhost` "should" map to
loopback addresses. That's what the RFC already says, after all, and it
matches my anecdata from conversations with developers (I haven't talked to
anyone (outside this group) who expected `localhost` to ever resolve
anywhere else). So, that's a good place to start.

Some folks in this thread (including me) think that "should" is too weak,
and that it would be helpful to make a stronger guarantee that `localhost`
matches its colloquial meaning. I think there are some pretty reasonable
arguments for this position:

1.  RFC6761 says <https://tools.ietf.org/html/rfc6761#section-6.3> that
users "may assume that IPv4 and IPv6 address queries for localhost names
will always resolve to the respective IP loopback address". It violates the
principle of least astonishment to allow the underlying platform to behave
at odds with that assumption. I'd suggest that we should either harden the
requirements below, or stop inviting users to make incorrect assumptions.
Given the widespread acceptance of those assumptions, the former seems like
the right course of action to me. :)

2.  Various bits of software behave in various (and inconsistent) ways when
presented with a DNS query for `localhost`. "Should" has not been as
effective as I'd like in creating an environment in which user expectations
are met. Chrome is the client I'm most familiar with, and it takes
advantage of the "should"'s and "may"'s in some circumstances to hard-code
resolution of `localhost`. That behavior isn't consistent across platforms,
however, and, as Richard notes, it would be helpful in our decision-making
if we clarified the guarantees the platform ought to provide.

3.  Groups like SUNSET4 are actively opposed to hard-coding IP addresses
like `127.0.0.1`, but if that's the only way that developers can really
ensure users' expectations are met, that's what they'll end up doing. As
Richard has noted a few times in this thread: that would be a worse outcome
than making stronger guarantees about the meaning of an mapped label.

If y'all decide that this is really just something that browsers need to
care about, then it's of course possible to address Chrome's use case by
overriding RFC 6761 in a W3C spec. If that's the course of action y'all
would prefer, I can do that. It seems like taking browsers' handling of
`localhost` out of the hands of DNSOP/IETF would be a bad outcome for this
group, but it's certainly an option.

With regard to DNSSEC delegations, my intuition is that Jacob's assessment
is reasonable, but I recognize that I don't know nearly enough about DNSSEC
to have a meaningful opinion. I'm happy to accept the group's assessment on
this point.

Thanks for continuing the conversation!

-mike

On Thu, Aug 3, 2017 at 1:27 AM, Richard Barnes <[email-masked]> wrote:

>> It should be MUST in both cases.   But writing that in an RFC doesn't
>> make it so.   Bear in mind when you look at the W3C document that it is
>> talking about what would be ideal, not what is actually present in browsers.
>>
> You have this backwards.  Browser today do take the more cautious,
> IP-based approach.  It sucks for developers.  They want to be able to use

---

From: "John Levine" <[email-masked]>
Date: 5 Aug 2017 21:01:17 -0000

In article <CAAiTEH9=RNDrUmSOs8Rg2Ea4+as9pg=j5jnU6Y=[email-masked]> you write:
>way to accomplish that is ...

 ... by having the stub or cache treat localhost as a special case.

I use unbound as my cache which as far as I know has always done that.
Are there caches that don't?  Are there validating stubs that don't?

My reading of this draft is that if you don't treat localhost as a
special case already, it's time to get with the program.  

R's,
John

> with an insecure delegation at the root.

---

From: william manning <[email-masked]>
Date: Sat, 5 Aug 2017 17:34:09 -0700

---------- Forwarded message ----------
From: william manning <[email-masked]>
Date: Sat, Aug 5, 2017 at 5:33 PM
Subject: Re: [DNSOP] Status of "let localhost be localhost"?
To: John Levine <[email-masked]>

i think the question hinges on zone completion logic and fully qualified
domain names.

when localhost appears as:

localhost   IN  AAAA   3ffe:53::53

without the trailing dot, zone completion logic should ensure that it is
NOT treated as a TLD.
whereas if I code this:

localhost.  IN AAAA  3ffe:53::53

that is a clear indication that I am running my own root zone and defining
my own view of the DNS namespace for class IN.   Shouldn't apps depend on
the DNS to serve trustworthy, correct, data?

/Wm

---

From: Mike West <[email-masked]>
Date: Mon, 7 Aug 2017 10:41:18 +0200

On Wed, Aug 2, 2017 at 3:44 PM, Mike West <[email-masked]> wrote:

> I'm pretty sure this is what the draft we're discussing attempts to do.
> See #2 under https://tools.ietf.org/html/draft-west-let-localhost-b
> e-localhost-03#section-3. It could be more explicit about the response,
> however... I can address that in a -04 if folks agree with the approach.
>

I poked at the draft a bit over the weekend, reworking it into a
stand-alone document in https://tools.ietf.org/html/
draft-west-let-localhost-be-localhost-04. I think it ends up being clearer
overall, and hopefully y'all agree.

Regarding the outstanding question of DNSSEC and insecure delegations, this
new draft takes the same approach as the ".onion" RFC, as Richard
suggested. I'm willing to run with whatever the group agrees upon on this
point, but this seems like a reasonable approach that's both simple to
explain and consistent with existing recommendations.

Feedback on that new draft would be very welcome indeed!

-mike

---

From: Erik Nygren <[email-masked]>
Date: Mon, 7 Aug 2017 12:29:14 -0400

On Mon, Aug 7, 2017 at 4:41 AM, Mike West <[email-masked]> wrote:

> stand-alone document in https://tools.ietf.org/
> html/draft-west-let-localhost-be-localhost-04. I think it ends up being
> clearer overall, and hopefully y'all agree.
>

This is looking good.  Thank you for driving this forward.

I think it is crucial to make the "localhost" abstraction be usable without
concerns
(but with caveats and guide-rails as proposed in the doc).  Otherwise we'll
be stuck eternally with people using "http://127.0.0.1/" URLs and will need
to special-case that when we want to retire IPv4 off of hosts.

It might make sense to collect some statistics on how often "localhost"
is looked up on various recursive resolvers to determine how big of a
problem
it will be for them to "NXDOMAIN".

       Erik

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 09 Aug 2017 09:31:33 -0700

I’m puzzled by much of this discussion.

We want a way for an application to indicate that it wants a loopback connection to another port on the local host.

People widely use “localhost” for this.

But other people argue that a mere RFC can’t guarantee that a host doesn’t violate the assumption that “localhost” means “local host”.

So, to indicate that it wants a loopback connection to another port on the local host, an application needs to use “127.0.0.1”. By, by the same logic, a mere RFC can’t guarantee that a host doesn’t violate the assumption that “127.0.0.1” means loopback. Who knows what a host OS will do with that address, if it does not follow the relevant RFCs? [*]

Forgive me, I forgot, “127.0.0.1” is obsolete. I should have written, “::1”. I’ll try again:

So, to indicate that it wants a loopback connection to another port on the local host, an application needs to use “::1”. By, by the same logic, a mere RFC can’t guarantee that a host doesn’t violate the assumption that “::1” means loopback. Who knows what a host OS will do with that address, if it does not follow the relevant RFCs?

So, “127.0.0.1” and “::1” are not suitable, both because a host OS might choose not to follow the relevant RFCs, and more importantly, they’re both address-family-specific.

What we really need is some symbolic way for an application to indicate unambiguously that it wants a loopback connection to another port on the local host.

We should reserve a specific string and define that it has this meaning. Some operating systems will follow the specification, and will work as expected, and others will not, which is a bug. Don’t use those products.

A nice mnemonic string would be good. Something memorable, which conveys the meaning, “local host”.

I suggest “localhost”.

Stuart Cheshire

[*] 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.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Aug 2017 12:44:18 -0400

On Wed, Aug 9, 2017 at 12:31 PM, Stuart Cheshire <[email-masked]> 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).

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 9 Aug 2017 12:45:45 -0400

> [*] 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 loopba…

As far as I can tell, "let 127.0.0.1 be loopback" is more stupid because
RFC 1122 states that addresses of the form 127.0.0.0/8 MUST be used for
loopback traffic, while the considerations for "let localhost be
loopback" in RFC 6761 §6.3 use non-mandatory language.

-- 
Robert Edmonds

---

From: Ray Bellis <[email-masked]>
Date: Wed, 9 Aug 2017 17:48:39 +0100

On 09/08/2017 17:44, Ted Lemon wrote:

> 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.

Speaking of which, MySQL uses the word "localhost" as a switch to use a
UNIX domain socket instead of IP for its connection.

Just sayin' ;)

Ray

---

From: "Peter van Dijk" <[email-masked]>
Date: Thu, 10 Aug 2017 13:45:47 +0200

Hello Mark,

> the same way as any other single label name.

localhost entries in zones are dangerous and should (MUST?) be removed. 
Having them present allows exploits like 
https://googleprojectzero.blogspot.nl/2015/06/owning-internet-printing-case-study-in.html 
to reach beyond the vulnerable software, into the context of your 
domain.

On a sidenote, my Mac does not send out queries for localhost. I’m 
unsure if this is due to /etc/hosts or due to special casing in the 
stub.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: "John Levine" <[email-masked]>
Date: 12 Aug 2017 17:09:58 -0000

>protocol to resolve names.

Right.  That's why it's long past time that we make it clear that
non-broken resolvers at any level will treat localhost as a special
case.  As you may have heard, we are not the Network Police, but we do
publish the occasional document telling people what to do if they want
to interoperate with the rest of the Internet.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Sat, 12 Aug 2017 13:14:35 -0400

> to interoperate with the rest of the Internet.

With respect, John, the issue I raised here isn't interop.  It's security.   It may be that I'm wrong, but if indeed I am wrong about this particular point, it is not for this particular reason.

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 12 Aug 2017 11:36:17 -0700

On 12 Aug 2017, at 10:14, Ted Lemon wrote:

> With respect, John, the issue I raised here isn't interop.  It's 
> security.

It's security through interop. It's causing systems that want to hope 
that "localhost" has a particular meaning that has security implications 
to have a better chance that their hope is fulfilled.

--Paul Hoffman

---

From: Richard Barnes <[email-masked]>
Date: Sat, 12 Aug 2017 14:44:56 -0400

On Sat, Aug 12, 2017 at 2:36 PM, Paul Hoffman <[email-masked]> wrote:

>> With respect, John, the issue I raised here isn't interop.  It's security.
>>
>
> It's security through interop. It's causing systems that want to hope that
> "localhost" has a particular meaning that has security implications to have
> a better chance that their hope is fulfilled.

And giving systems that want to ensure that they never mistake "localhost"
for something other than loopback to have a better chance that they won't
break things.

--Richard

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 12 Aug 2017 12:03:44 -0700

On 12 Aug 2017, at 11:44, Richard Barnes wrote:

>> that

Sorry, yes: that too. It applies to hopefulness on both sides.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Sat, 12 Aug 2017 15:35:17 -0400

El 12 ag 2017, a les 14:36, Paul Hoffman <[email-masked]> va escriure:
> It's security through interop. It's causing systems that want to hope that "localhost" has a particular meaning that has security implications to have a better chance that their hope is fulfilled.

Yes, I get that, and I'm not sure that it's wrong, but you still haven't addressed the point that I raised.   That's fine—I don't know that you really need to.   But for some reason people keep replying to my point with statements that don't contradict it, as if they think they have contradicted it, which puzzles me.

To recap, my point is that fixing localhost and then relying on it doesn't fail safe, and there is reason not to be confident that implementations will conform, because they will appear to work even if they don't.   If we think that localhost is the right identifier to use to refer to the local host, then we ought to be taking steps to make it not be the case that broken implementations will appear to work: we should be systematically trying to ensure that as many environments in which such applications might run as possible produce failure when a broken resolver forwards a query for localhost to the local recursive resolver.

The document does the right thing on that front, as far as that goes, but if this is to be effective I think that it shouldn't be an aside, but should be the main point of the document.   That is, the title of the document should be "DNS servers should return NXDOMAIN for localhost" and the abstract should say why, and then the bit about stub resolvers translating "localhost" to a reachable identifier for the localhost such as 127.1 or ::1 should be the thing that's mentioned as an aside.

And then we should be socializing this to operators and filing bugs against it in the bug tracking systems of our favorite distros.

And after doing that, it will still be the case that references to "localhost" don't fail safe, but it will be more likely that they won't happen, so maybe my point will have been adequately addressed.   But I still think that it would be better to recommend some identifier that can't be looked up in the DNS.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 12 Aug 2017 15:10:35 -0700

Ted Lemon wrote:
> ...
>
> To recap, my point is that fixing localhost and then relying on it
> doesn't fail safe, and there is reason not to be confident that
> implementations will conform, because they will appear to work even if
> they don't. ...

i'm only excerpting a small bit of ted's text, so that i can say:

+1

and, please everybody go read the rest if you didn't already.

-- 
P Vixie

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sat, 12 Aug 2017 17:05:51 -0700

On 08/12/2017 12:35 PM, Ted Lemon wrote:
> The document does the right thing on that front, as far as that goes,
> but if this is to be effective I think that it shouldn't be an aside,
> but should be the main point of the document.   That is, the title of
> the document should be "DNS servers should return NXDOMAIN for
> localhost" and the abstract should say why, and then the bit about
> stub resolvers translating "localhost" to a reachable identifier for
> the localhost such as 127.1 or ::1 should be the thing that's
> mentioned as an aside.
I agree, this seems like a good addition to the doc. It makes explicit
what we've discussed on-list, and it codifies what is already common
practice in the wild, along with justification.

---

From: Tony Finch <[email-masked]>
Date: Sun, 13 Aug 2017 20:19:40 +0300

> On 12 Aug 2017, at 22:35, Ted Lemon <[email-masked]> wrote:
> 
> That is, the title of the document should be "DNS servers should return NXDOMAIN for localhost" and the abstract should say why, and then the bit about stub resolvers translating "localhost" to a reachable identifier for the localhost such as 127.1 or ::1 should be the thing that's mentioned as an aside.

RFC 6761 requires recursive servers to return positive 127.0.0.1 and ::1 responses, not NXDOMAIN. I can't see an explanation in the draft for the change to NXDOMAIN.

https://tools.ietf.org/html/rfc6761#section-6.3

Should there also be some text about the wisdom (or otherwise) of localhost entries in public zones? E.g. localhost.cam.ac.uk - see also http://seclists.org/bugtraq/2008/Jan/270 and the follow up messages from Florian Weimer and David Malone.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Ted Lemon <[email-masked]>
Date: Sun, 13 Aug 2017 14:09:02 -0400

> RFC 6761 requires recursive servers to return positive 127.0.0.1 and ::1 responses, not NXDOMAIN. I can't see an explanation in the draft for the change to NXDOMAIN.

The reason to return NXDOMAIN is that it causes stub resolvers that look localhost up using DNS to fail, which is what should happen.   It is incorrect to look up localhost in the DNS.   Failure is preferred in this case.

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 13 Aug 2017 13:51:24 -0700

On 13 Aug 2017, at 10:19, Tony Finch wrote:

>> That is, the title of the document should be "DNS servers should 
>> return NXDOMAIN for localhost" and the abstract should say why, and 
>> then the bit about stub resolvers translating "localhost" to a 
>> reachable identifier for the localhost such as 127.1 or ::1 should be 
>> the thing that's mentioned as an aside.
>
> RFC 6761 requires recursive servers to return positive 127.0.0.1 and 
> ::1 responses, not NXDOMAIN. I can't see an explanation in the draft 
> for the change to NXDOMAIN.

And there should be. Proposed addition to the last paragraph of Section 
1:

A consequence of the requirement that the resolver APIs MUST resolve 
"localhost." and any names falling within ".localhost." to loopback 
addresses is that caching DNS servers and authoritative DNS servers MUST 
NOT resolve those names at all, and always return NXDOMAIN.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Mon, 14 Aug 2017 03:36:49 +0300

> On 13 Aug 2017, at 23:51, Paul Hoffman <[email-masked]> wrote:
> 
> And there should be. Proposed addition to the last paragraph of Section 1:
> 
> A consequence of the requirement that the resolver APIs MUST resolve "localhost." and any names falling within ".localhost." to loopback addresses is that caching DNS servers and authoritative DNS servers MUST NOT resolve those names at all, and always return NXDOMAIN.

Well, that isn't really the kind of text I wanted.

You have written a paragraph that is obvious from the internal logic of the draft, but it doesn't say why "a consequence" has changed from RFC 6761.

What we really need is an informed analysis of the consequences of different ways of sinking localhost queries on recursive servers. The de facto way is NXDOMAIN (same as what happens when there is no special case in the resolver, except without the recursion to the root servers). The RFC 6761 way is to return locally authoritative positive responses.

Either way, BIND (for instance) needs special configuration to be RFC 6761 compliant or NXDOMAIN compliant, so some kind of code change is needed to make the Right Thing the default, but which Thing's Rightness needs justification.

There are also missing security considerations. The whole draft is motivated by web security edge cases, so I would like to see a summary and citation of the same site scripting problem, and whatever other issues there might be.

Does the change from positive responses to NXDOMAIN have some connection to the web security motivation? It isn't clear to me and it ought to be.

There is also a weird compatibility awkwardness. RFC 6761 requires *.localhost to resolve to localhost, in stub and recursive resolvers. You can't implement this in traditional Unix libc resolvers. It's possible to implement this in a recursive server like BIND, but I realised this week that I had not implemented the wildcard in my config, so I bet proper RFC 6761 conformance is rare.

The upshot of the draft's current text is that full system behaviour will vary depending on libc version, recursor version, recursor config, etc.

I think it is still a good idea to tighten up the implementation requirements to MUST. That part of the draft is good, but trivial.

The interesting part is not stated in the current text: it is that application software that makes security assumptions about localhost MUST internally resolve localhost without relying on the shifting historical and operational variability of stub resolvers and recursive servers.

Tony.

---

From: Mike West <[email-masked]>
Date: Mon, 14 Aug 2017 13:30:01 +0200

I've uploaded an -05 draft
<https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-05> (diff
to -04
<https://tools.ietf.org/rfcdiff?url2=draft-west-let-localhost-be-localhost-05.txt>)
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.

The draft also follows up on recommendations that Mark and others have made
regarding DNSSEC by requesting an insecure delegation of `localhost.` in
the root-zone (I found Warren's notes on the topic in
https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00#section-4 quite
useful, btw).

Tony: I'd like to understand more clearly what justification you'd like the
draft to present. Do the changes in -05 give the reader enough context, or
does it need more work in that regard? Does shifting the application-level
requirements into the main body of the draft, out of the implementation
considerations section, make the requirements around security decisions for
localhost names clear enough?

-mike

On Mon, Aug 14, 2017 at 2:36 AM, Tony Finch <[email-masked]> wrote:

> ::1 responses, not NXDOMAIN. I can't see an explanation in the draft for
> the change to NXDOMAIN.
> >
> You have written a paragraph that is obvious from the internal logic of
> the draft, but it doesn't say why "a consequence" has changed from RFC 6761.
>
> What we really need is an informed analysis of the consequences of
> different ways of sinking localhost queries on recursive servers. The de
> facto way is NXDOMAIN (same as what happens when there is no special case
> in the resolver, except without the recursion to the root servers). The RFC
> 6761 way is to return locally authoritative positive responses.
>
> Either way, BIND (for instance) needs special configuration to be RFC 6761
> compliant or NXDOMAIN compliant, so some kind of code change is needed to
> make the Right Thing the default, but which Thing's Rightness needs
> justification.
>
> There are also missing security considerations. The whole draft is
> motivated by web security edge cases, so I would like to see a summary and
> citation of the same site scripting problem, and whatever other issues
> there might be.
>
> Does the change from positive responses to NXDOMAIN have some connection
> to the web security motivation? It isn't clear to me and it ought to be.
>
> There is also a weird compatibility awkwardness. RFC 6761 requires
> *.localhost to resolve to localhost, in stub and recursive resolvers. You
> can't implement this in traditional Unix libc resolvers. It's possible to
> implement this in a recursive server like BIND, but I realised this week
> that I had not implemented the wildcard in my config, so I bet proper RFC
> 6761 conformance is rare.
>
> The upshot of the draft's current text is that full system behaviour will
> vary depending on libc version, recursor version, recursor config, etc.
>
> I think it is still a good idea to tighten up the implementation
> requirements to MUST. That part of the draft is good, but trivial.
>
> The interesting part is not stated in the current text: it is that
> application software that makes security assumptions about localhost MUST
> internally resolve localhost without relying on the shifting historical and
> operational variability of stub resolvers and recursive servers.
>
> Tony.
> --

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Aug 2017 10:36:54 -0400

El 14 ag 2017, a les 7:30, Mike West <[email-masked]> 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.

---

From: Mike West <[email-masked]>
Date: Wed, 16 Aug 2017 12:17:46 +0200

On Mon, Aug 14, 2017 at 4:36 PM, Ted Lemon <[email-masked]> wrote:

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

These suggestions seem pretty reasonable, thank you for spending the time
writing them up. I've queued these up for an eventual -06 in
https://github.com/mikewest/internetdrafts/commit/10274f38ef92edcc2c9f4083ead7e49ccc926508#diff-a9d272c9ebfa20da41c3000f869001a4
.

> 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.
>

1.  I agree with you.

2.  I know I don't have enough expertise in this area to make an informed
decision, and smart folks on this thread and elsewhere have told me that an
insecure delegation would be better than status-quo. I added
https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-05#section-4.2
to the document on that basis.

I'm happy to accept the group consensus on this point, one way or the
other. :)

> 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

In the commit linked above, I've adopted the second and third paragraphs
with minor wording changes. It's not really clear to me where the crux of
the first paragraph lies. IMO, malware is pretty clearly out of scope for
software's security decisions, as anything running on the local machine
with privilege equal to (or exceeding!) your own is basically impossible to
defeat. Are there scenarios in which you think that's not the case, at
least insofar as this draft is concerned?

if the document is adopted, as seems likely.

Given the level of interest in the document, I do hope that the group would
decide to adopt it. :) That said, it's not clear to me what the next steps
might be here.

My personal opinion is that trusting localhost is a bad idea, but I realize
> that this may not be the consensus.

Do you believe that trusting `127.0.0.1` is less risky? It seems to be less
risky today, and part of the goal of this draft is to bring localhost names
into line with the security properties that hard-coded loopback addresses
provide.

-mike

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Aug 2017 08:58:51 -0400

El 16 ag 2017, a les 6:17, Mike West <[email-masked]> va escriure:
> In the commit linked above, I've adopted the second and third paragraphs with minor wording changes. It's not really clear to me where the crux of the first paragraph lies. IMO, malware is pretty clearly out of scope for software's security decisions, as anything running on the local machine with privilege equal to (or exceeding!) your own is basically impossible to defeat. Are there scenarios in which you think that's not the case, at least insofar as this draft is concerned?

That's why I mentioned sandboxing.   A process running on the local host, inside a sandbox, listening on a local port, could be reachable by processes that aren't sandboxed, or are running in other sandboxes.   So trusting localhost provides a way for a sandboxed process to screw you, basically.   I don't know how serious a threat this is, but I think the idea that the set of trust zones on a single host is flat is not valid, and that's why I actually don't think that, even with this document published and in wide use, "localhost" should be considered trustworthy.

A slightly less vulnerable approach would be to allow reserved ports on localhost to be trusted, but to not trust other ports, on the basis that something that can get a reserved port has privileges.   This is still questionable, since a trusted sandboxed app could be compromised, but it's at least a smaller attack surface.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 16 Aug 2017 17:41:58 -0400

On Wed, Aug 2, 2017 at 2:02 PM, Robert Edmonds <[email-masked]> wrote:
> component in front of the DNS stub resolver.

Yup, you would think so -- unfortunately, this seems less true than
we'd expect (or hope!)

Around 0.3% of responses from Google Public DNS are for "localhost".
As an honest DNSSEC-validating resolver, Google Public DNS returns
NXDOMAIN for queries of localhost. (and all its subdomains). If you
ask with DO set, it returns the root NSEC records proving there is no
such domain (yes, this disagrees with the SHOULD in 6.3.4 of RFC6761).

As with many things in the DNS, the real world is messier than we'd --
I would have hoped that most systems would be answering locally for
queries for localhost, and never asking the DNS, but this turns out
not to be as true as we would have liked. I think that this supports
the case for the localhost document; this behavior should be firmed
up. It also exposes the fact that an application naively resolving
"localhost" and trusting the answer (for security purposes) is not
currently safe.

W

> If you put

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "John Levine" <[email-masked]>
Date: 17 Aug 2017 15:01:06 -0000

>to the document on that basis.

The problem with asking for an insecure root delegation is that the
IETF has no process for putting anything in the root.  In principle we
could work something out with ICANN, but that process would take
somewhere between a very very long time and forever.  It is likely to
be hijacked by other people who also want special treatment for their
pet TLDs which is why my estimate would be closer to forever.

So my inclination would be to say that localhost lookups that reach
the root will get a secure NXDOMAIN, which one could take as a hint
that it's time to update the stubs and caches that let the query leak.

We don't have to work this out now, we can adopt the document and
figure out what to fix later.

R's,
John

PS: For anyone who was going to say what about .ARPA, it was in the
root a long time before ICANN existed.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Aug 2017 10:36:51 +1000

> pet TLDs which is why my estimate would be closer to forever.

Well start now.  'localhost' was special before DNS, DNSSEC and
ICANN came into existence.  This is completing work that should
have been done at the time the root zone was signed.

> that it's time to update the stubs and caches that let the query leak.

Insecure NOERROR NODATA for A and AAAA are fine.  Secure NOERROR NODATA
for DS is what is needed.

---

From: "John R Levine" <[email-masked]>
Date: 17 Aug 2017 21:15:29 -0400

> for DS is what is needed.

If you believe that's important (I don't) the stubs and caches can special 
case that, too, of course.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly