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

Mike West <mkwst@google.com> Thu, 03 August 2017 10:52 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 28EE9131D27 for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 03:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, RP_MATCHES_RCVD=-0.001, 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 BDf80-w4xsMH for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 03:52:12 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 9BDFB131D6B for <dnsop@ietf.org>; Thu, 3 Aug 2017 03:52:12 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id d71so9106228oih.0 for <dnsop@ietf.org>; Thu, 03 Aug 2017 03:52:12 -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=bQNA7FHyw+MCv7aSIXI9rwuVGNsief6xzAmdh3jTJJY=; b=vY3KUjaXBP6oIFAwk1qRLG96xdpJzpBEo89V1pP01YfLHPaIAAJP0YEV3K6g2Nrbb8 rX3wu0FH9PQobK4I6QoG3e3vLPU1tNhnTCI2K04d1uvpMApJKVXO8bao2g6iDBkBYIVm BVK3Kuz6Vupr6BQqK3VWgvtrc7Is/MtqOnCBhJkltkCQU82Q4DN3hwV3lYLYx9QNC/vf hGWht/XB0woMrloec6Z1Z790nAit9bIUO4d53AKOTKZsx3lRy+nhyp5Dt1L5I/PV2vuS icpbN3rRYXdHRUE378Sec4X0l0yj5lx7qnGGs0iv2+VUh469FQuIppuTAppJQTKGLX++ 8zIA==
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=bQNA7FHyw+MCv7aSIXI9rwuVGNsief6xzAmdh3jTJJY=; b=FQkOZGwF6ESG3POLK+/om+juUixV+BGagAhFbhUXxqld/EQJ96TXepyYSrIkepwdG5 /aVoJSBZE512+JN5Ke7LagVx9b4T05BPCytEQUJcrTN64gb/4IVyw6l94tvRe2Y73YuF JvFOAoPTup6Cm8jXR3cwRXoMOLjid4Zin0PLKCiqJKgNpIHpaFRVg65+THjboiMURVCP ESz7qGIVD7QVTuxfhqzyUo5DiR0mkulwaCtZouw4jIBysTD6X3lof98Crjvwa7EOPX4s PFywkcpNulbErjOiD00fFVfQoORNVz7bDTnZEYmYgDcP3jv8dU9D7oRIHvnALgbQ4zQl fXOw==
X-Gm-Message-State: AIVw1117z1tXVgn2o0Pv07iXYfiHkulFvWYc3sJcvPEOvNhSc1RDSEHl +fSIBVqNOxtnaU2QWBYJaP3wvmT24GeJ
X-Received: by 10.202.199.138 with SMTP id x132mr1065287oif.52.1501757531339; Thu, 03 Aug 2017 03:52:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.47.5 with HTTP; Thu, 3 Aug 2017 03:51:50 -0700 (PDT)
In-Reply-To: <CAL02cgQJ0UMHMJa8B59mZO8up7gPg=f8QbR_iyunW7ZCzScW8A@mail.gmail.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> <F19EC009-0301-4C23-BC27-FFF021C77C02@fugue.com> <CAL02cgQJ0UMHMJa8B59mZO8up7gPg=f8QbR_iyunW7ZCzScW8A@mail.gmail.com>
From: Mike West <mkwst@google.com>
Date: Thu, 3 Aug 2017 12:51:50 +0200
Message-ID: <CAKXHy=cvw+sz-WuFdGPYY4zx6VKUNn1pqQShe7JBuZNDmHnfbw@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: Ted Lemon <mellon@fugue.com>, Robert Edmonds <edmonds@mycre.ws>, dnsop <dnsop@ietf.org>, Jacob Hoffman-Andrews <jsha@eff.org>, william manning <chinese.apricot@gmail.com>, Erik Nygren <erik+ietf@nygren.org>
Content-Type: multipart/alternative; boundary="001a11c180443375e60555d72c16"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mVc270_8X0fHeRCKf18y2_dcoZU>
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: Thu, 03 Aug 2017 10:52:15 -0000

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 <rlb@ipv.sx> wrote:

>
>
> On Wed, Aug 2, 2017 at 4:27 PM, Ted Lemon <mellon@fugue.com> wrote:
>
>> On Aug 2, 2017, at 2:02 PM, Robert Edmonds <edmonds@mycre.ws> wrote:
>>
>> 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"?
>>
>>
>> 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
>
>