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

Mark Andrews <marka@isc.org> Mon, 05 February 2018 06:51 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 66AF6126BF0 for <dnsop@ietfa.amsl.com>; Sun, 4 Feb 2018 22:51:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kIjBXsemhjlB for <dnsop@ietfa.amsl.com>; Sun, 4 Feb 2018 22:51:37 -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 BE9DA120727 for <dnsop@ietf.org>; Sun, 4 Feb 2018 22:51:37 -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 DFC0B3AB03E; Mon, 5 Feb 2018 06:51:34 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id AC236160054; Mon, 5 Feb 2018 06:51:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9015F16005B; Mon, 5 Feb 2018 06:51:34 +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 WU8ED2wcz91e; Mon, 5 Feb 2018 06:51:34 +0000 (UTC)
Received: from [172.30.42.91] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 31437160054; Mon, 5 Feb 2018 06:51:33 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <618D31E1-8EC7-4F75-BD97-31D42CB1E681@fugue.com>
Date: Mon, 5 Feb 2018 17:51:30 +1100
Cc: Lanlan Pan <abbypan@gmail.com>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <40992CF7-5740-43ED-8B78-8D8A9B50A15C@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> <01C3E853-A14F-4D1B-865D-5B74C9F1F999@isc.org> <CANLjSvUJ17pLEhpboEJfhum6gv-2-Ls5prKYUH0rumqSpkcpqw@mail.gmail.com> <2B1DC084-C6EA-41DA-9029-5E230874FCBE@isc.org> <29F25C57-31D1-4A07-875D-16E7612DB993@fugue.com> <E4C5AA7E-E9C1-4E53-ABE0-676A9B7B3269@isc.org> <618D31E1-8EC7-4F75-BD97-31D42CB1E681@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/imJiIexbIOFRlcHHJhA7-OPstN4>
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: Mon, 05 Feb 2018 06:51:39 -0000

> On 5 Feb 2018, at 5:10 pm, Ted Lemon <mellon@fugue.com> wrote:
> 
> On Feb 5, 2018, at 12:18 AM, Mark Andrews <marka@isc.org> wrote:
>> The original problem is that HTTP doesn’t specify that names learn across the
>> wire, including from on disk html files, need to be treated as absolute names.
>> This is HTTP’s mess due to allowing relative names in what is transmitted over
>> the wire.  This should be sent back to HTTP say FIX YOUR INSECURE PROTOCOL.
> 
> That's totally orthogonal to the question we are considering.

No it is not! The browser knows where the name came from.

If HTTP treated ALL NAMES AS ABSOLUTE then href="http://localhost/" would result
in EXACTLY ONE possible lookup in the DNS, /etc/hosts, NIS(YP), LDAP etc.  Similarly href=“http://some.partially.complete.name/“ won’t resolve to
some.partially.complete.name.example.com when run by a employee of example.com.

HTTP is a security nightmare because it is specified that those names may not be
absolute.  Fix that security hole and there is no need to touch this draft for
the reason it was brought up.

>   It's also nonsense.   How does HTTP, a protocol, know the source of an IP address that it's been given by the name resolution API?   Does the API even give you a way to tell?   What you mean is that the implementation should know the difference.  This is what the document is doing.   It's saying that the API should never look this name up in the DNS.

SMTP all names are absolute. You call the name API’s with searching disabled.
The implementation is broken is search is enabled.

HTTP names may be relative. You don’t call the name API’s with searching disabled
and you get a security mess as a result.

STOP SEARCHING!!!!  IT IS NOT NEEDED.

>> The second bugtraq issue is also HTTP’s insecure security model that doesn’t
>> take into account that addresses have scopes.  Again that is for HTTP to fix.
> 
> HTTP should certainly be smart about scopes, and I would argue that "machine scope" is not a scope in which connections should be assumed to be trustworthy, so indeed in a sense that you are right.
> 
> But the reason for wanting the DNS to not return answers for localhost is that implementations may get this wrong, and if they do we want it to fail safe.   So again, your premise is valid, but doesn't apply.

Just fix the browsers.  IT IS NOT THE DNS’S JOB TO FIX UP HTTP’S MESS
and in doing so BREAK OTHER THINGS!!!!!!!!!!!!

> As for search lists, I think it's reasonable to say that search lists, which are not part of the DNS protocol, should not be applied to the bare label 'localhost.'   If the document said that DNS servers should treat FQDNs containing the label 'localhost' specially other than when it is the top-level label, that would be wrong.   But it doesn't say that.   It just specifies the handling of localhost with respect to searchlists, and what it says is correct and important.   If I can supply you a search list and use that to trick you into connecting to a remote service rather than a local one, that's a significant attack surface.

Search lists should not be applied to any name learnt over the wire.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org