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

Mike West <mkwst@google.com> Wed, 16 August 2017 10:18 UTC

Return-Path: <mkwst@google.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 56170132076 for <dnsop@ietfa.amsl.com>; Wed, 16 Aug 2017 03:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=google.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 yDQxoV6q8tE3 for <dnsop@ietfa.amsl.com>; Wed, 16 Aug 2017 03:18:09 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 CFBD013207A for <dnsop@ietf.org>; Wed, 16 Aug 2017 03:18:08 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id x191so17421724qka.5 for <dnsop@ietf.org>; Wed, 16 Aug 2017 03:18:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NCOFrqmk5EelY3eCJgguUSsJ/V2Mqtz8F3aqn8votE0=; b=sVOEUaXT6py6mmWapAMFz1W7mqS/ywOQGUubgray9cv6n0/re8Txufj+ktRUHedzP8 hQkkuen1olF7KIMnUmsAY0XCmXrs+/74sZBKpZX1JGucXLO4XEX9s3qFpM0nzVu22Uu4 FwdUnC3WcvC5s57sW3e3+PeIhy8Z2jQ+bZRay8EpbK60kTvshcpg+KkUuOd1gt/MMoh3 +G7gPyenrJhyvlvxvLyYe10/ygQcaam0Wqv50de6H+OwNYg+DN9sAjteQatPrynh8BMs iYtYWWADIhAmloI/2X3mdWkL9f6tJK6dvw+39g0rhsf6+sZSplLXfe7WejcyVyIPGZVO tZtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NCOFrqmk5EelY3eCJgguUSsJ/V2Mqtz8F3aqn8votE0=; b=DKS3Btw+7pNY2Mpl4w68/73nuarxx8y6yWx4BDYyxyvnhev7VNf027D3wIeERZbJp6 MhT5XCnNaE/ot3RTLxSP4bAmvHUVgr7uUnEecXKCedyXmPsUBZ+gAgs9ReFF22bPL3IM 7v0KjHkhbI8wZ3ZZob0z/3p4rvW4nxwGuSI1yVSR/sgPJrhwOVSQhflI/BmbgVr48Psm w4DZVLOEj3IyXjQYWhxWU+tdl/IZzN5ue++zZYVDMNoyoRavccMaH9RjJJnBYpKBDNBo yaQArQ7cxcCFhkZ7bkdNLahF3AQg7HUDSeOHYX6+DUZ8NYf9fcIwRGNDoFenl/+Fa8ql fIzw==
X-Gm-Message-State: AHYfb5iO/70IVvZLiMxg1L9QzePCfTxJtWtTPF5FuKotplOcQoSz4TE3 vAgyI8CUSMAUKCc2SJeWrm/yb+5XkKp9zQiBLg==
X-Received: by 10.55.16.34 with SMTP id a34mr1464624qkh.124.1502878687655; Wed, 16 Aug 2017 03:18:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.25.236 with HTTP; Wed, 16 Aug 2017 03:17:46 -0700 (PDT)
In-Reply-To: <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> <198D730F-F932-4220-8CDF-106D6BC77AFF@fugue.com>
From: Mike West <mkwst@google.com>
Date: Wed, 16 Aug 2017 12:17:46 +0200
Message-ID: <CAKXHy=chbyfempMDtk-tJMkzDL3oeOdJdyujxuK2-qH4E5Hp_w@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: dnsop <dnsop@ietf.org>, Tony Finch <dot@dotat.at>, Mark Andrews <marka@isc.org>
Content-Type: multipart/alternative; boundary="001a11475f3851f0680556dc36fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uHVmHC_D7dpKc2XWHpm3PEgmRtA>
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: Wed, 16 Aug 2017 10:18:12 -0000

On Mon, Aug 14, 2017 at 4:36 PM, Ted Lemon <mellon@fugue.com> 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. :)


> 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


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