Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Mark Andrews <marka@isc.org> Fri, 02 February 2018 20:11 UTC

Return-Path: <marka@isc.org>
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 2F6A5124BAC for <dnsop@ietfa.amsl.com>; Fri, 2 Feb 2018 12:11:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 T2V9R5TVtfrB for <dnsop@ietfa.amsl.com>; Fri, 2 Feb 2018 12:11:41 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69BC128C0A for <dnsop@ietf.org>; Fri, 2 Feb 2018 12:11:40 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 7F2693AB05B; Fri, 2 Feb 2018 20:11:37 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 44FA3160071; Fri, 2 Feb 2018 20:11:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1E93B16006F; Fri, 2 Feb 2018 20:11:37 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7zLaJ-kR3WqS; Fri, 2 Feb 2018 20:11:37 +0000 (UTC)
Received: from [172.30.42.88] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B4D91160038; Fri, 2 Feb 2018 20:11:35 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-F69834A8-7B6B-497A-90B2-5FDD6D2E9A9A
Mime-Version: 1.0 (1.0)
From: Mark Andrews <marka@isc.org>
X-Mailer: iPhone Mail (15D60)
In-Reply-To: <CA+nkc8D_JUaWhW8eZ3KuMKJsyVd1ddMtFLhk5Tne1oH2eEHhZg@mail.gmail.com>
Date: Sat, 3 Feb 2018 07:11:33 +1100
Cc: Ted Lemon <mellon@fugue.com>, IETF DNSOP WG <dnsop@ietf.org>, Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Transfer-Encoding: 7bit
Message-Id: <01C3E853-A14F-4D1B-865D-5B74C9F1F999@isc.org>
References: <9DCE2F63-EE37-4865-B9D6-6B79BBE05593@gmail.com> <20180129155112.GC16545@mx4.yitter.info> <5A6F5CF1.4080706@redbarn.org> <CA+nkc8D7tne5SxGOUhvJqstmDa=1=RmvcHQte1byAab5dUd5sQ@mail.gmail.com> <AE634FC4-0EAF-4F54-8860-61E41284F873@fugue.com> <20180130185919.GJ19193@mx4.yitter.info> <3b57a486-df8e-ca57-ab89-c167cea0dcc9@bellis.me.uk> <20180131161507.GP3322@mournblade.imrryr.org> <20180201172644.GD26453@mx4.yitter.info> <1D7693F7-000C-451A-8F7A-45B94366240F@fugue.com> <20180201204833.GA27125@mx4.yitter.info> <777C7B4A-A8D6-4E14-9DBF-360B6BDF4A95@fugue.com> <CA+nkc8D_JUaWhW8eZ3KuMKJsyVd1ddMtFLhk5Tne1oH2eEHhZg@mail.gmail.com>
To: Bob Harold <rharolde@umich.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xgnpI1chZaaWNz8JhfIqnRKnn7Y>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02
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: Fri, 02 Feb 2018 20:11:44 -0000

The problem is that search lists are being applied when “localhost” is being entered into name lookup APIs and is being matched against localhost.example which isn’t expected to  to a address on the current machine and that the search list may be auto constructed or come from a untrusted source.

There is also a small risk that hotspots will return something other than a local address if a address lookup for .localhost is made. 

This is all in the context of processing  urls.

Localhost is the last remanent of the pre hierarchical host scheme. 

The risks are eliminated if the name APIs use local lookup sources in those contexts.

Then you have legacy clients. As long as the servers for the namespace on the public Internet don’t return A or AAAA records for localhost the issue is addressed there.

You then have the recursive server where you would like it, by default, return a answer without contacting the root servers.  The only safe way to do that is to have it serve a empty zone for localhost.  As this zone isn’t linked into the global DNSSEC chain of trust the root zone needed a insecure delegation for localhost. 



-- 
Mark Andrews

> On 3 Feb 2018, at 05:25, Bob Harold <rharolde@umich.edu> wrote:
> 
> 
>> On Thu, Feb 1, 2018 at 4:26 PM, Ted Lemon <mellon@fugue.com> wrote:
>> On Feb 1, 2018, at 2:48 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
>>>> As a general principle, when what the RFC says to do is not the right thing to do, the solution is to update the RFC, not to ignore the problem.
>>> 
>>> I strongly agree with this (as I think or anyway hope you know)
>> 
>> Yes, I will admit I was a bit surprised that you put it that way, although as you say, your position is more clear in your formal review of the document.
>> 
>> As for why I responded to this and not to the formal review, the answer is that the formal review was a bit overwhelming.  You made a lot of assertions of fact that didn't sound like fact to me—they sounded like strongly-held opinion.   You are a much more experienced DNS expert than I am, so for me to argue you away from those opinions is a tall order—I don't think you've really expressed the underlying belief that is the keystone to the whole edifice.
>> 
>> The problem I have is that to me it's dead obvious that the name hierarchy and the set of names in the DNS are not the same thing.   We've had that discussion before.   We even published a document about it, which hasn't quite made its way out of the RFC editor queue yet.   It seems to me that it is demonstrably the case that these two sets are disjoint.
>> 
>> But you explain your reasoning on the basis that clearly they are the same set, and that they are the same set is left unexamined.   So if we were to succeed in understanding why we disagree on this point, it would be necessary to dig down into that.
>> 
>> Having seen you give keynotes at the plenary, I know that you are deeply concerned about computer security.   The reason that I am in favor of the behavior I'm propounding is that I think it closes a small security gap through which a truck might some day be driven, to our woe.   So to me, the need to leave that gap, which I admit is small, open, seems inconsistent with what I know of you.
>> 
>> So clearly you value this idea that localhost is a name that exists in the DNS, even though it doesn't exist in the DNS.   It might be fruitful to explore that further.   It might also be a waste of time.   I don't honestly know.   But that is, I think, the key to our disagreement.
> 
> 
> Could someone explain the security problem?  If it really is bigger than the problems that will be caused by changing resolvers to answer with NXDOMAIN, then you might convince me.  
> 
> -- 
> Bob Harold
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop