Subject: [DNSOP] Localhost - more reliable options?

From: Brian Dickson <[email-masked]>
Date: Thu, 17 Aug 2017 15:22:05 -0700

The discussions about localhost (and 127.0.0.1 and ::1) have ben very
enlightening.

However, I wonder whether the desired use case -- reliably establishing a
connection to a host, based on information in DNS -- might be more
securely/reliably solved using other mechanisms?

Using "localhost" is basically making unilateral assumptions (and using ::1
or 127.0.0.1 equally so).

I think the reliability, and possibly the security, are better achieved
with bilateral mechanisms.

E.g. If the specific use case is a client trying to talk to a server, on a
particular port and protocol, then a more robust method of determining that
the server offers such a service, would be using SRV or URI records.

When the client, resolver, authority server, and service-server may not be
tightly coupled, it might require additional enhancements, such as client
subnet (or similar), to ensure the appropriate answer is given.

The specific value returned to the query might be 127.0.0.1, or might be
some other address; the main thing is that the address is deliberately
associated with a service that wants the client to use, and presumably the
service knows that the client is on the same host.

Sorry if this isn't as clear as I intended - basically, what I'm saying, is
that the answer might not even be an IP, protocol and port, but might even
be a "file:///" URI, for a named pipe, which avoids the whole IP stack.

Hope this provides useful ideas which point away from localhost per se.

Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Aug 2017 21:28:40 -0400

El 17 ag 2017, a les 18:22, Brian Dickson <[email-masked]> va escriure:
> Sorry if this isn't as clear as I intended - basically, what I'm saying, is that the answer might not even be an IP, protocol and port, but might even be a "file:/// <file:///>" URI, for a named pipe, which avoids the whole IP stack.

It's hard to see how this is going to help.   What we are trying to do here is bypass DNS; now you are asking us to go through DNS to get the name of a local resource and contact it.   So really you've just increased the attack surface.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 17 Aug 2017 18:54:05 -0700

On Thu, Aug 17, 2017 at 6:28 PM, Ted Lemon <[email-masked]> wrote:

> Sorry if this isn't as clear as I intended - basically, what I'm saying,
> is that the answer might not even be an IP, protocol and port, but might
> even be a "file:///" URI, for a named pipe, which avoids the whole IP
> stack.
>
>
> It's hard to see how this is going to help.   What we are trying to do
> here is bypass DNS; now you are asking us to go through DNS to get the name
> of a local resource and contact it.   So really you've just increased the
> attack surface.
>
>
If you're trying to use "localhost", that means you're using some kind of
name resolution, whether it be DNS, /etc/hosts, NIS+, or anything else.
I'm suggesting that by using DNS, you can take advantage of what DNS has to
offer, which includes potentially DNSSEC.

There is a bootstrap problem, in that the client might have to know
something about its own name...

In the use case, are you trying to bypass DNS because you don't trust it?
That part isn't really clear.

What are the assumptions that are being made, best case vs worst case, and
which are known to be "guaranteed"?

Is the server doing dynamic update to whoever its DNS authority is? Is
DNSSEC an option (sometimes?) or not... etc.

So, here's one model that might work.

Put the "localhost" at the deepest part of the namespace, *below* the host
name. I.e., if my name is fully.qualified.domain.name, then I "control" my
own name and things below it, and do an update for "
localhost.fully.qualified.domain.name".

IFF that name exists, then the server is smart enough to be assumed to be
listening on whatever IP address (v4 or v6) is registered, and the client
can reasonably trust that.

Using SRV at that point is maybe overkill, maybe not (depending on the
trust model).
Add DANE stuff if you really want to do some kind of validation, etc.
Or use URI for getting off the IP stack, if "file:///" makes sense.

I think someone should write up the problem statement, since it is possible
that what you really want has nothing to do with localhost, and having the
"let localhost" kind of presumes the solution before identifying the real
problem...

What are you actually trying to do, and why?

Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Aug 2017 22:20:18 -0400

El 17 ag 2017, a les 21:54, Brian Dickson <[email-masked]> va escriure:
> If you're trying to use "localhost", that means you're using some kind of name resolution, whether it be DNS, /etc/hosts, NIS+, or anything else.
> I'm suggesting that by using DNS, you can take advantage of what DNS has to offer, which includes potentially DNSSEC.

DNSSEC can't work, or even be used, if you are spoofing localhost.   If you used DNSSEC, the answer would fail validation.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 17 Aug 2017 20:19:25 -0700

Sent from my iPhone

> On Aug 17, 2017, at 7:20 PM, Ted Lemon <[email-masked]> wrote:
> 

Correct, so to clarify:
Use DNSSEC, and use something other than "localhost."

Does the host know its own name(s)?

Brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Aug 2017 10:45:55 -0400

> Does the host know its own name(s)?

Depending on the context, the host likely doesn't have a name.   If it does have a name, PKI works, so there's no need for some sort of ad-hoc trust regime.   You should assume that the only reason someone would use localhost is that it's the best alternative, and propose solutions that work in that situation.   Localhost might get used in other situations, but if you can't solve for that situation, you don't actually have a solution.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 18 Aug 2017 13:38:09 -0400

Sorry, but point of order: We have a solution that entails a minimal change
from the current state of the art and minimal incremental security risk.
Let's not re-open fundamental questions, please.

On Thu, Aug 17, 2017 at 6:22 PM, Brian Dickson <
[email-masked]> wrote:

> Using "localhost" is basically making unilateral assumptions (and using
> ::1 or 127.0.0.1 equally so).
>
> even be a "file:///" URI, for a named pipe, which avoids the whole IP stack.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>