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

Ted Lemon <mellon@fugue.com> Mon, 14 August 2017 14:37 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E60132344 for <dnsop@ietfa.amsl.com>; Mon, 14 Aug 2017 07:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1f7vW8s-wKA for <dnsop@ietfa.amsl.com>; Mon, 14 Aug 2017 07:36:57 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D13713232C for <dnsop@ietf.org>; Mon, 14 Aug 2017 07:36:57 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id a77so51214619qkb.0 for <dnsop@ietf.org>; Mon, 14 Aug 2017 07:36:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MElMcZjrEyiFjpiSaqdd+qpFZE3kN5vqHu0DeTPVYFk=; b=ZlqEi1VSvEcUatzhUayjmd4rNkCGvlzUbhtCOJpeo+LfQdQSzcd9YnTEtSAFGMZTuK RkBEFw7iGj7SomLUZjsmOJIzbAiNAemDeidY4zavGqzAIj8hP3PqRrOFylTlSKjoet++ 70t5sxS11AKy8sBkpkNSCabDRqIAnOf1f+JT3QUXWSVHb2Qoez0Krc/0gvoqaG83y4t8 72yw4LkUYcF52F9B34kT+LLO43nu6Q1CSVAYNxzl5I50vN8ubEvvDjGqVBHUDQqrOJlD 1rzSWG+fqOhe2MZFlVwSkKWV+u0AqQH6/HboZK4DxIhgzRNWVA2ANgmyn55Uxh65hiQK T6VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MElMcZjrEyiFjpiSaqdd+qpFZE3kN5vqHu0DeTPVYFk=; b=MCjpiLue3tfc/4prmGGd4R4jAwQsqAJqvunLdRl0dHw2h3JsfmpXl8xUsUEtOg53Yj ZQGISttSQV+jjHS7ZQ4bRZsZQ9kRFUBnCqkoz22aKklZU3SjodJROpWI2eFrA6hIGp9R 7BdhfqwCS8bP3u6+z0CRREK/xz+lROrgVyZCnrjstwSKguGfU9H4pI91w3m4JLaSbKjz FYE4D+dwv20ijiebvU39AtbXK8ZFQTk1UP1tuBVwGaNLSePysQziwqU2mwJ8o+Pw0JrK FMcf/Mt/IOYaqi+hB/qz1H0D7aJ9azpao1qBKC3W3rq2P7pCKJHzs90VttvtOssiRaFc Whfw==
X-Gm-Message-State: AHYfb5goYS9TGiNj0EcQx0GjOzzThImcDp49nGYkxtW1JVocc1RHzEkf 62MJiTv1E7hCL1aI
X-Received: by 10.55.207.72 with SMTP id e69mr6143883qkj.34.1502721416499; Mon, 14 Aug 2017 07:36:56 -0700 (PDT)
Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 22sm5370066qto.36.2017.08.14.07.36.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 07:36:55 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <CAKXHy=doWBA8NbCfzV74zs71JBJjs3nET-kBJ0+ohY5EZLM=1Q@mail.gmail.com>
Date: Mon, 14 Aug 2017 10:36:54 -0400
Cc: dnsop <dnsop@ietf.org>, Tony Finch <dot@dotat.at>, Mark Andrews <marka@isc.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <198D730F-F932-4220-8CDF-106D6BC77AFF@fugue.com>
References: <20170812170958.14197.qmail@ary.lan> <B21C539E-75AF-43F1-B6B0-4BDC25C6D670@fugue.com> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> <C12D3CFC-74DF-49C1-8947-863D49EEEEA5@dotat.at> <D4C0F17B-A939-41BD-855A-77A6E7986941@vpnc.org> <3617BEAA-8DCE-4BB5-9408-3AA78E986F27@dotat.at> <CAKXHy=doWBA8NbCfzV74zs71JBJjs3nET-kBJ0+ohY5EZLM=1Q@mail.gmail.com>
To: Mike West <mkwst@google.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uAqQqJsaxfQVHdgUU9M-c12X7E0>
Subject: Re: [DNSOP] Status of "let localhost be localhost"?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Aug 2017 14:37:00 -0000

El 14 ag 2017, a les 7:30, Mike West <mkwst@google.com>; 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.