Re: I-D Action: draft-west-let-localhost-be-localhost-00.txt

Emily Shepherd <emily@emilyshepherd.me> Tue, 27 September 2016 21:12 UTC

Return-Path: <emily@emilyshepherd.me>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E78E12B215 for <ietf@ietfa.amsl.com>; Tue, 27 Sep 2016 14:12:26 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emilyshepherd.me
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 vkmqUlHbRYsX for <ietf@ietfa.amsl.com>; Tue, 27 Sep 2016 14:12:24 -0700 (PDT)
Received: from lucy.sweeb.net (lucy.sweeb.net [139.162.207.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608F412B156 for <ietf@ietf.org>; Tue, 27 Sep 2016 14:12:24 -0700 (PDT)
Received: by lucy.sweeb.net (Postfix, from userid 115) id 4146B1F549; Tue, 27 Sep 2016 22:12:19 +0100 (BST)
Authentication-Results: lucy.sweeb.net; dkim=pass reason="1024-bit key; unprotected key" header.d=emilyshepherd.me header.i=@emilyshepherd.me header.b=HLjSyeNl; dkim-adsp=pass; dkim-atps=neutral
Received: from emily-tablet (host81-157-247-194.range81-157.btcentralplus.com [81.157.247.194]) by lucy.sweeb.net (Postfix) with ESMTPSA id B45EC1F43B; Tue, 27 Sep 2016 22:12:18 +0100 (BST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=emilyshepherd.me; s=mail; t=1475010738; bh=wfJWywR7jObdCA8hkzZDvzM4ADHh3zHZiqsbRRhBxS8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HLjSyeNl2H4ezcumSaug7+1dOVTHexBBSeJTw3ogi3S5ZaAFpENrNXMY/WMZL1w37 WTXEiZS/iSfWZdMcerPXX8+Re8U+PyGDYkQtc6QvqsUlCflcXa957Y/KdDO6GBcq80 V8a4xee3xF72qZGGPYn3KfnMoYK5ZEuq99T5lwGo=
Date: Tue, 27 Sep 2016 22:12:08 +0100
From: Emily Shepherd <emily@emilyshepherd.me>
To: John Levine <johnl@taugh.com>, mkwst@google.com
Subject: Re: I-D Action: draft-west-let-localhost-be-localhost-00.txt
Message-ID: <20160927211208.zrkp4txdpelw3at4@emily-tablet>
References: <CAKXHy=fCoQPb4EJ2aS9Lfj6yKM-HotjhO_VsPk2PDeFATxpGdg@mail.gmail.com> <20160927184845.5034.qmail@ary.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="3vz4wodwvn5vtcpi"
Content-Disposition: inline
In-Reply-To: <20160927184845.5034.qmail@ary.lan>
User-Agent: Mutt/1.6.0.1 (2016-04-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/JbFqhidDLm-ZJncERcJfQBUigT0>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2016 21:12:26 -0000

>>> As this proposal is in the name of consistency, is there an argument 
>>> we
>>> should be strict and explicitly define *which* loopback address DNS servers
>>> must return when queried?
>>
>>I was intentionally vague on that point, as one of the scenarios raised in
>>https://github.com/w3c/webappsec-secure-contexts/issues/43 was a developer
>>who was pointing `project1.localhost` to 127.0.0.1, and
>>`project2.localhost` to 127.0.0.2 in /etc/hosts (and presumably had a
>>server configured accordingly). It seems like that's a reasonable thing to
>>support. Any loopback address is fine with me.

Sorry, my question was unclear - I was referring to point 3 about 
authoritative nameservers rather than local setups; I agree that locally 
developers should be allowed to use whatever local addresses they want.  
Anyway, that's been cleared up by fixing the typo so that's no longer an 
issue :)

On Tue, Sep 27, 2016 at 06:48:45PM -0000, John Levine wrote:
>I use multiple IPv4 127/8 addresses all the time.  For example, I run
>a funky local stunt DNS server on 127.0.1.1 and configure my local DNS
>cache to use it for a branch of the name tree.  So yes, any loopback
>address will do.  (We can save the question about a link-local IPv6
>address on a loopback interface for later.)

Clearly this is a sensible and perfectly legal setup, however I worry 
that this proposal may interfere with it. If name resolution APIs are 
forbidden from forwarding localhost queries onto their DNS servers, how 
would they know that, in this case, the stunt DNS server *should* 
receive requests so it can route things to your preferred link local 
addresses?

I'm probably not explaining myself well so I'll give an example. In the 
setup above, let's say you've set 127.0.1.1 to be your local DNS server, 
meaning that you might expect the following commands to work:
    
    $ dig mysite.localhost
    mysite.localhost IN A 127.0.0.1

    $ dig myothersite.localhost
    myothersite.localhost IN A 127.200.200.200

But, under this proposal wouldn't dig be obliged to refuse to forward 
the request onto 127.0.1.1? How does dig (or your browser or any other 
resolving API) know the difference between a bog standard caching DNS 
server and a local DNS server that has explicitly been set up to route 
local lookups?

It's possible that I'm overcomplicating matters, and dig would never 
actually refuse to forward on such a request, but my fear is that the 
writers of browsers may use such a proposal to simply hard code 
"localhost" to resolve to 127.0.0.1 and then clever local setups like 
these would end up breaking.

We could possibly add some kind of exemption in the case of local DNS 
servers, eg: Name Resolution APIs and Libraries SHOULD send queries for 
localhost names to their configured caching DNS server(s) if and only if 
such server is itself running on a link local address.

Emily

-- 
Emily Shepherd
Computer Science Graduate, MEng (Hons)
W: https://emilyshepherd.me/
M: +44(0)7575 721 231