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

Ted Lemon <mellon@fugue.com> Wed, 09 August 2017 16:45 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 9B7CA132423 for <dnsop@ietfa.amsl.com>; Wed, 9 Aug 2017 09:45:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 HCbWX7sHLKV3 for <dnsop@ietfa.amsl.com>; Wed, 9 Aug 2017 09:44:59 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 825DE132424 for <dnsop@ietf.org>; Wed, 9 Aug 2017 09:44:59 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id h68so30105058pfk.0 for <dnsop@ietf.org>; Wed, 09 Aug 2017 09:44:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EwN0pabjg5y+hVmN3W7H63PJToMk1zS/W4vcY9Pcp5A=; b=xeSmiISEn99qn9B7eG+MC6Wxl9rLIDfHvi/6jxmwhFL59AWqzffDkU/EYKjHs8BnX1 X7ywKBUxLQeNOQaZgJfd3vo5ePi42tju03kK/uTSrnbkRKkSYqxvYQVWcJD4nzM5glpU xvC6pcfpnFRoE75AXV+ToeHfYarh5TOy9Rwlv982keS+Gz+d8w2NBtftVOGyK4GNoTDS vzZVXzHkSfQC+2rsgu3ehwKbjuCpEiZkHrMuSzlnqYQw+aTKKLQdaSa+IOj6loI6Kwt+ XXX8Hid23eLMuPBPtW4zkPQx1+IuiTg6SqYyt8Gv1yvgDkFoME0nD0W7DVsPQI9IWbRD XV4g==
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=EwN0pabjg5y+hVmN3W7H63PJToMk1zS/W4vcY9Pcp5A=; b=qAO2Aws5HlP8grjjKYg1gGzbKYPgOy4PGMJBVnIRbdkC1OArDP2Zj+8Pa4KbCEhQvV z8LigGnCUyF+OB4psBWVApCRfhgkrrR3lGZ6GDtBva27K2LmLGioV6afY7i/qkbX+UpJ 7xG9D/3p27XadwGD0vtvQihKrJZf5UsduqQUgkIiUHi/PHLsLYBOqR2igG83gnWLm2NW 1becCQ3VMIfi188YOg8bXcI3boMPXqYBqtbCrpzLi5GK9IybrdB7Z8cn8rdc71p6J/1h StZeHxvRTyt4CSuuhVz3nb/xz34xvtHoJaylJKgy5MQH+Q5LtDFqkqHzvYSLQmKZUz52 Pyyw==
X-Gm-Message-State: AHYfb5isW7FmcDBiXeZD5LrHM69k9WHx5tHfliCGt4Y5OTnsfaG8lgPv VIuEPZtxmmqDdZyYrLsevwzTDQWw2hJt
X-Received: by 10.99.107.193 with SMTP id g184mr8148113pgc.167.1502297098892; Wed, 09 Aug 2017 09:44:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.180.131 with HTTP; Wed, 9 Aug 2017 09:44:18 -0700 (PDT)
In-Reply-To: <820AEB88-C38C-4547-8F42-3C7C7E3D7ACC@apple.com>
References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <CAKXHy=ctB=LZkX9j=8-Jy0NkTAs2tAesa4gmFhfp94O5=9U4TA@mail.gmail.com> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <CACfw2hiX7U74n9+defcYiD7jLKZeLhtLM6WP5YM_WuAoA8ecYQ@mail.gmail.com> <CAL02cgRg6k7=b7berKr9J+9aL8PTS81nJ_yXQO8QTYqgiqXSbg@mail.gmail.com> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <CAL02cgQ2z9Fze-Q2QWQ=+PHJEO_S3bTaq1fPJ6XSEwFUQ=ftvw@mail.gmail.com> <CAKXHy=eV0OBW+S308rdiHZ523foOgxYNB3i07RkeFJiTjMYQEQ@mail.gmail.com> <D9568E51-3C48-4BA3-9797-3F7756E857C9@fugue.com> <20170802180221.n7ezh5yzr5cuxklz@mycre.ws> <820AEB88-C38C-4547-8F42-3C7C7E3D7ACC@apple.com>
From: Ted Lemon <mellon@fugue.com>
Date: Wed, 9 Aug 2017 12:44:18 -0400
Message-ID: <CAPt1N1=hse1dYB7OhJvdXdtO+R2cZC6XRo-2-rupVy6dOqivfA@mail.gmail.com>
To: Stuart Cheshire <cheshire@apple.com>
Cc: dnsop <dnsop@ietf.org>, Robert Edmonds <edmonds@mycre.ws>, Richard Barnes <rlb@ipv.sx>, Mike West <mkwst@google.com>, william manning <chinese.apricot@gmail.com>, Jacob Hoffman-Andrews <jsha@eff.org>
Content-Type: multipart/alternative; boundary="94eb2c14088aed4dd8055654cc52"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/iWhQcrKjCgM89GwuXUcV_WZUTHA>
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, 09 Aug 2017 16:45:02 -0000

On Wed, Aug 9, 2017 at 12:31 PM, Stuart Cheshire <cheshire@apple.com> 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).