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

Lanlan Pan <abbypan@gmail.com> Sun, 04 February 2018 03:32 UTC

Return-Path: <abbypan@gmail.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 8C60E126DEE for <dnsop@ietfa.amsl.com>; Sat, 3 Feb 2018 19:32:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BnPK83etumTg for <dnsop@ietfa.amsl.com>; Sat, 3 Feb 2018 19:32:04 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 7EA1D12420B for <dnsop@ietf.org>; Sat, 3 Feb 2018 19:32:03 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id r71so20003664wmd.1 for <dnsop@ietf.org>; Sat, 03 Feb 2018 19:32:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m3wlV6ahadnLGkh3ue4VGqG9oB6QPUyN93iBhUUqQyo=; b=tQIh06tb3BZKTaoFwBWAAa1gL2GZ/GWJN3bJX0eCGM6NH3q953M6Tm7ZBUhFPUP5Cq PubyfcKIF9einWU4WARxe7WpsLu67kvTO5KnOyYVIbMJGAl7Kstp+tEZWH/zLHPvS4fY F/CoCX+k8S68Gk06vgmQ8lGN4l7EWen/1+YWFYl6Jn+BdoIULRV7VI/UpQ26Aix51vYo 6NX/rTaKLri1rivCHXr7ZqWtJPYcpFjxmQM7Psd9Ilvg29MnA+ihiE+Fp7pPQUyBDosp eAyYbqNn6OZV8LtX3boc6dlQBkggXqqsI6IHbjxcjOvfNL1aON8apKTI37U6RsbczmKE s+MA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m3wlV6ahadnLGkh3ue4VGqG9oB6QPUyN93iBhUUqQyo=; b=KyTl/h+AAl1Xo1PzVrrX0pyxQVadBA5FBFYFLKpgF5lb7oIg99SDgNiMaJk+3eIM4t bFS+NkAWoIWxV0I1kA9Z9LSd8ZS6Gt+dHE8WALMd7aquA4EytL9r5y69NSpLgjyq4ZQ4 OAfqLOdYJ6Gh7ol2QEA5W1gwUtBA1/0RwdubXUCOnyoaa7x+wdtEUCpIwVrSk58LUFYe yoZrUGRSEC71NutHHQ7rcvUi+W7FyGbnVOntXNIHF3H9ADOrgzT6Fk0rxX+Q7aixu6ry cr1L0kynQM0xCsJ958OziAT2vTx9Es+5yLUVe7sn+lHx2GNQqavqowzmjVi8NGl8TF6I EIag==
X-Gm-Message-State: AKwxyteD9jKHc5sjRK6XAX/OXa5jOdu9ZWaVD9jm+XVR/WHfRf7A+Q/n OSlEYbYuKgBR/FEU8j5HYoPt6Wi+ZjB6wlM/8mRV4Q==
X-Google-Smtp-Source: AH8x225JmQtvqO6l+rIwSfFEaAzAB2Gshd9SJtAWm30yHTLGQL517uC9DlsBIn/hiYzKW5wlH9UequxesDap4K4bYMY=
X-Received: by 10.80.217.202 with SMTP id x10mr66923030edj.118.1517715121888; Sat, 03 Feb 2018 19:32:01 -0800 (PST)
MIME-Version: 1.0
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> <01C3E853-A14F-4D1B-865D-5B74C9F1F999@isc.org>
In-Reply-To: <01C3E853-A14F-4D1B-865D-5B74C9F1F999@isc.org>
From: Lanlan Pan <abbypan@gmail.com>
Date: Sun, 04 Feb 2018 03:31:51 +0000
Message-ID: <CANLjSvUJ17pLEhpboEJfhum6gv-2-Ls5prKYUH0rumqSpkcpqw@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="089e08222b4cb5e1df05645a9682"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Mlx-V81e73RtHTjIBHFee85uVBY>
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: Sun, 04 Feb 2018 03:32:07 -0000

Mark Andrews <marka@isc.org>于2018年2月3日周六 上午4:11写道:

> 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.
>

If only consider about http: http://seclists.org/bugtraq/2008/Jan/270
Web browser can also ban this "localhost.example".
CA Single Sign-On might help to solve the "same site" cookie expose problem.


> 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan