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

Matthew Kerwin <matthew@kerwin.net.au> Mon, 05 February 2018 08:28 UTC

Return-Path: <phluid61@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 CBA75129C59 for <dnsop@ietfa.amsl.com>; Mon, 5 Feb 2018 00:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 PucKtHHBAK1j for <dnsop@ietfa.amsl.com>; Mon, 5 Feb 2018 00:28:16 -0800 (PST)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 C0D77129C56 for <dnsop@ietf.org>; Mon, 5 Feb 2018 00:28:15 -0800 (PST)
Received: by mail-it0-x231.google.com with SMTP id i144so8792029ita.3 for <dnsop@ietf.org>; Mon, 05 Feb 2018 00:28:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UJZtEbA6PqVPwA5+r7zHNvG3fZjFt2IKL1bO3AEo7Fs=; b=A1F6QBOomEUNcCocJlMrKzlllrdikHImNZkXuNBTelCd95CcmA5PJQ4RahLBFbkFm4 Oah0yLUIpH4hR92jGggqWOrjufK/IQh3vTh4GSgh9LGI0tv7zaLv14Or7KCjPaPFWCI7 +18++RX/NgHxSUZAlcD0bGxeg/vVpqwJG4kg6tBi14XoEjykmmieMR1Iy036ToB0aWIM 7W1L+Hr0/hJUvPdEQST97l99vHkn6wl82pnmdScQIbCkImPD5wcVHDtqThwvC43DXjD1 /46Iu6IdpTMzfgr4R1NPxkwiGHwYr2OHwmsBJUaLqiuQ3luLrAFyYwhhNtMBsxj9NgKn efYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UJZtEbA6PqVPwA5+r7zHNvG3fZjFt2IKL1bO3AEo7Fs=; b=UbXpnONs1AMD/9b9kk4BuTwvi6vBCp/7S8KhSDRNRnhosUQhVDIoPWNd9q9RTmJ7pW /szTKVcJS6V0n+3BvpSEPDmeV7i8kdTDWf2d4NRDTpgc9jJaT2IBZlU7kcTqnLqdExPp boOr9j4NpsejoMTHxQUHxJqId0k2kgrSUFDu+DuwbMy9UAhA8SRB0Sj7oeQEP4aXi5Aj srQ3OtFO+6B6Z/kEaI9hsXnz4FTyuZHkSKqMYd/7+2hflFfQcBGb3otSsFp1CNz3QG12 BFSRnrtMD7kvLyZNpIYyCfAf0K8XPN4EJbDRKeJ+P4N9WKi70Eq+AHuaWhEj5wTvklOG AlBg==
X-Gm-Message-State: AKwxytfeiK1FEFk7cYDgxZqIp7j5x9WX9v5G6jvM1omQNajUfDz3qZUZ LFIbHTc+uw64PPxhGGFUJpD6dT4KNTdHuadvRnU=
X-Google-Smtp-Source: AH8x227lRBd5Nrau5VurK4uWULTUqHNCmu0WwX0DzFTDj4HtC1hWx5U3uTqFqcE8BLpQmaT+iGh7naN8Pwqumn7j55M=
X-Received: by 10.36.98.8 with SMTP id d8mr54794388itc.79.1517819295082; Mon, 05 Feb 2018 00:28:15 -0800 (PST)
MIME-Version: 1.0
Sender: phluid61@gmail.com
Received: by 10.107.82.3 with HTTP; Mon, 5 Feb 2018 00:28:14 -0800 (PST)
Received: by 10.107.82.3 with HTTP; Mon, 5 Feb 2018 00:28:14 -0800 (PST)
In-Reply-To: <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> <40992CF7-5740-43ED-8B78-8D8A9B50A15C@isc.org>
From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Mon, 5 Feb 2018 18:28:14 +1000
X-Google-Sender-Auth: OWB6ZmjgXDHbwV_oz_haKnR3p64
Message-ID: <CACweHND4xX0=LAdXq81AOxA5vQ_n7kRbWj66vPgaBY3qU+RhhA@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: Ted Lemon <mellon@fugue.com>, Lanlan Pan <abbypan@gmail.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f75b2eaad54056472d73e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TOzO-Xht0S5I-UoxM3_riHLYmC4>
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 08:28:19 -0000

On 5 Feb. 2018 16:52, "Mark Andrews" <marka@isc.org> wrote:


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


In fact it is specified that they may not be DNS names at all.  However...

RFC 3986, on which HTTP relies for the 'host' part of its URIs, says to use
"http://localhost./" for an absolute FQDN.  So it's actually the users'
problem.

But catching it somewhere convenient seems a hell of a lot less problematic
than trying to fix the users.  And catching it in DNS seems a lot less
problematic than rewriting RFC 3986 (or rewriting HTTP to not use that part
of 3986).


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


And if it's broken, it currently fails open. This proposal makes it fail
closed.


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.


It can be handy, though. "http://dev01/" or "http://dev02/" is much easier
to type.


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


What about the name I type in the address bar?

Cheers
-- 
Matthew Kerwin