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

Richard Barnes <rlb@ipv.sx> Wed, 02 August 2017 13:58 UTC

Return-Path: <rlb@ipv.sx>
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 B8FC2126C83 for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 06:58:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.773
X-Spam-Level:
X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 mp1BMs4ATTY5 for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 06:58:47 -0700 (PDT)
Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (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 6FB4912008A for <dnsop@ietf.org>; Wed, 2 Aug 2017 06:58:47 -0700 (PDT)
Received: by mail-wr0-x22d.google.com with SMTP id v105so19136118wrb.0 for <dnsop@ietf.org>; Wed, 02 Aug 2017 06:58:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8rOT+LZkD6gCdYU8igsCFeawUgutx3cB4V8z050TQEE=; b=zCwKMzej3o6NpA9w4ZwY/1GYAdao+jG0xr7VOHeN4koBZo5EKy7nJk7bwx4pRK7U+1 ED9JKakjshT0VP+QsH8ULbld77GXSLN7ZTtXguonw80m5uwvfyTZ2RludfzG+Q0PmRTe +JqblSJXPlWiBrexShMDj+AzYNkU5VKQLEb+fsnMSMOcXgOk3dd9Hd7YnXeCJaeIMPZH 6Wh5GqQwpxWMd8EIfVNdfnDZPhOluCw5ZpMB5+pjLEQtfWz5+hvy5CUHxMT8qw1kZatb uXF/vaCjPO/w9RVb0phL2DEVAjbARo57Xn49bjOHQ5alcsViUXr/Q/cikQdToNqg5H3X 5jSw==
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=8rOT+LZkD6gCdYU8igsCFeawUgutx3cB4V8z050TQEE=; b=SWftsqioqDWZxoaREg8c213/kSm6MCiY+d95xrDYeupon5Kxo3dL0bj7B5ahf51S3A orNALZuicWJjeKpbdaXSJU1qsPc/sNKOSznX/JmlAtr3zg3w9lM28SvtN05vWyS7zhiR jgUPG9f7U/IkrCTWryUfS0CZf/WosGMA1qyrquvsKSQotZBIHmN/qd88TLoXsFH5FgXe m3g8wLgNxyKU77wKj+rjtxeyEOYUDDDBFbI/1Vh3hBVWbcEOwMpPx0e6cjb/lRrMA+NI k01f1Ud8ZhiNWcz/j1ZQ1oka/b1OgFCEu2pqWrg1ImlzmLee1ZIb+jClhC5lq67TCJku v0SQ==
X-Gm-Message-State: AIVw111WbqZ1MRARzPakMEPUXKEU0cQUQmLC3eTljWLpeIb9GPZ+eImW BIKcv++dBsnDh9zv7H2xxymDaQNTBUC9
X-Received: by 10.223.149.102 with SMTP id 93mr16624751wrs.25.1501682325747; Wed, 02 Aug 2017 06:58:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.225.5 with HTTP; Wed, 2 Aug 2017 06:58:44 -0700 (PDT)
In-Reply-To: <CAL02cgShGOix14+QqmDur1kD6xsvV2J1p+MEnbHuEvVw_aut+w@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> <7066211F-69B4-4B69-840B-A811D19980BF@fugue.com> <CAL02cgShGOix14+QqmDur1kD6xsvV2J1p+MEnbHuEvVw_aut+w@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 2 Aug 2017 09:58:44 -0400
Message-ID: <CAL02cgTfiKkx=9O+UixeL18Z_nfu8NPCKG11XvGnCrXzrSK12g@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: william manning <chinese.apricot@gmail.com>, dnsop <dnsop@ietf.org>, Jacob Hoffman-Andrews <jsha@eff.org>
Content-Type: multipart/alternative; boundary="94eb2c0df18c9791f50555c5a9b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qxVqFSFi9tGdJHMmmC5MKBU9WtI>
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, 02 Aug 2017 13:58:49 -0000

On Wed, Aug 2, 2017 at 9:18 AM, Richard Barnes <rlb@ipv.sx> wrote:

>
>
> On Wed, Aug 2, 2017 at 9:10 AM, Ted Lemon <mellon@fugue.com> wrote:
>
>> On Aug 2, 2017, at 9:02 AM, Richard Barnes <rlb@ipv.sx> wrote:
>>
>> But of course having IP addresses in URLs is both a PITA for developers
>> and an anti-pattern more generally.
>>
>>
>> While true, I would argue that this is actually a problem.   E.g., I
>> actually literally cannot surf to a link-local URL without having a DNS
>> record for it, because http://[
>> <http://%5Bfe80::1806:ec37:3d5f:9580%25en0%5D/>fe80::1806:ec37:3d5f:9
>> 580%en0]/ <http://%5Bfe80::1806:ec37:3d5f:9580%25en0%5D/> has an
>> interface identifier in it, and modern browsers consider this an
>> anti-pattern, I guess.   And you don't want to put link-local addresses in
>> DNS, even if it made sense to do so, so what is one to do?   I'm not
>> convinced that this anti-pattern is the wrong anti-pattern, but here we
>> have two examples of it being problematic, in the least.
>>
>> If "localhost" were properly defined to be loopback, then applications
>> could just hard-wire resolution, and not depend on the good graces of the
>> platform resolver.  As, for example, Firefox does with ".onion" today:
>>
>>
>> Right.   But there was actually a long discussion on why that's
>> problematic when we were doing the .onion RFC.   The reason is that one
>> can't count on any particular piece of application software correctly
>> interpreting the rightmost label.   We can write RFCs encouraging it, but
>> if I am writing a URL into a piece of HTML, I have no idea whether the
>> thing that interprets the HTML will or will not do the right thing.
>>
>
> The point you're missing here is that the application is both the thing
> relying on the definition of "localhost" and the thing empowered to enforce
> the RFC.  If the application doesn't care whether "localhost" resolves to
> anything special, then it can pass it to the platform and take its
> chances.  If it does, it can hard-wire it to loopback.
>

To address the concerns of HTML authors here:

As with any change to web semantics, this introduces a challenge for web
developers because different versions of browsers will interpret things
differently.  For example, if the W3C Secure Contexts spec changes to treat
"localhost" URLs as secure, and browsers implement that, then if you load "
http://localhost" in a new browser, it will be get access to certain APIs
that it wouldn't on earlier versions.

Two points here:

1. It's up to the browsers to make this transition fail safe, in the sense
that if you write code that depends on "localhost" being secure, then your
code will break if the browser is not going to ensure that "localhost" is
loopback.  This is what the Secure Contexts spec is for, and the gist of my
comments above.

2. Web developers have to deal with this sort of incompatibility all the
time anyway, because their sites are accessed by many different browsers
with different capabilities.

In other words, there's only breakage risk here (not security risk), only
for new things, and not any worse than web developers already have to deal
with.

And based on the feedback from web developers so far, the risk of breakage
is strongly preferred to the pain of hard-coding IP addresses.

--Richard




>
>> We just accept that as a risk with .onion because we don't have a better
>> option, but for localhost we definitely do have a better option.   That's
>> all I'm saying.
>>
>
> Using IP addresses is not a better option.
>
> --Richard
>