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

Richard Barnes <rlb@ipv.sx> Wed, 02 August 2017 13:02 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 5ADFF132094 for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 06:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham 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 nKmR-d2FLf-r for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 06:02:29 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 B3671132007 for <dnsop@ietf.org>; Wed, 2 Aug 2017 06:02:28 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id y43so18476230wrd.3 for <dnsop@ietf.org>; Wed, 02 Aug 2017 06:02:28 -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=qXIAEuPkC7DNFV/p2PKSPLQufOwCYMAtXxd8kIL2cRg=; b=ZUSaMgh2jX4rrxcvJi47Bp0H1Wpg9Qw49r23kUbdmKPR861mlp0V40HQYELSigO3mg 8z+h5OGurZ+UpRT8KMybyMKOYyE1XUHRQg1oFLqcb5eyNGX2poIQcVpaRpQvSuQDqMUA 7A8LZRMGrqwSmSCwvb1QhB434rBikqun1Og8gSYJGCIbRAxX1Q5ghBoq0Dn1WVlqCCVJ VP+WZ6BrM56n9yXz1Z2Sc+BVc2fqlkV/RKfUEh5+Nm3QUQ1ReKM8Tozoo9yEa0Ep8bZU 5ZlRS3p00+Hcm0fh+T8xLCLdP8RWpeULyV9wMRYMVUk2HD5njeJbZgYw3fAFrgOaX5in nh9w==
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=qXIAEuPkC7DNFV/p2PKSPLQufOwCYMAtXxd8kIL2cRg=; b=rISHsbyvtTtwQxWo34FUq+N3dPkh10UiTlzdw47ae9StypiKtGM8Y5P88SBJoiFpBm UlHthNi1HTh3O18g0KqeULFncGhwuij7UkzFPo/0J8kSh6NU/zB1DeHh0/O6hUK4EOMi lwY8GmwUSF7ryWuTXnRFd8OChO958CVRd1eNrWFY9CHzbOZkwtMDVo9b6//sxmGa6pfd p13d52K2vPW4Fyh2REQVQmwO0/IC1m79Fn23WrEGy9EPPh0bNc+RiFUo91SFTUJKuRhq maP+kxGIZiKtDvyoSon96/o2WCrM9HlsxXxrFIMC64mzBEbR2eATtxBtzBDYRXr8lXkp yJ+A==
X-Gm-Message-State: AIVw112INtQxAhNBl1xOmNroVyRO+INuOYI6dWMLyEBEYHvlsJymfv9Y hM97l9RZ9/uWYG8T8GwwQnoitTqO1b3y
X-Received: by 10.223.179.13 with SMTP id j13mr16690970wrd.228.1501678947001; Wed, 02 Aug 2017 06:02:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.225.5 with HTTP; Wed, 2 Aug 2017 06:02:26 -0700 (PDT)
In-Reply-To: <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.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>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 2 Aug 2017 09:02:26 -0400
Message-ID: <CAL02cgQ2z9Fze-Q2QWQ=+PHJEO_S3bTaq1fPJ6XSEwFUQ=ftvw@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="94eb2c1b4eb43443170555c4e026"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_l5q86U6JL-oMpkyHxRmS4_MxMk>
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:02:30 -0000

On Wed, Aug 2, 2017 at 8:48 AM, Ted Lemon <mellon@fugue.com> wrote:

> On Aug 2, 2017, at 8:40 AM, Richard Barnes <rlb@ipv.sx> wrote:
>
> The underlying need here is that application software would like to make
> use of the fact that it is connecting to "localhost" (vs. other domain
> names) to make security decisions based on whether traffic is going to
> leave the host.  So if the network layer remaps localhost to something
> other than a loopback interface without telling the applications, then
> you're going to have security problems.
>
> The point of this document is to avoid this disconnect by discouraging the
> sorts of remappings you're talking about.
>
>
> Of course, arguably this is the wrong approach.   Perhaps the right
> approach is to understand that the security characteristics of "localhost"
> are not the ones that we want when our goal is to be sure we are connecting
> to the local host.   Apps don't control the name resolution software that's
> running on the local host.   If they want to be sure they are connecting
> locally, perhaps they should be using ::1 instead of localhost as their
> explicit destination identifier.
>

This is indeed what happens today.

https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy

But of course having IP addresses in URLs is both a PITA for developers and
an anti-pattern more generally.

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:

http://searchfox.org/mozilla-central/source/netwerk/dns/nsDNSService2.cpp#708

(The "localhost" stuff in that method is unrelated to this discussion BTW;
it relates to a Firefox-internal mapping of other domains to localhost.)