Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost

Warren Kumari <warren@kumari.net> Mon, 11 September 2017 14:08 UTC

Return-Path: <warren@kumari.net>
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 65A621326ED for <dnsop@ietfa.amsl.com>; Mon, 11 Sep 2017 07:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 E_ENtrSO5mhh for <dnsop@ietfa.amsl.com>; Mon, 11 Sep 2017 07:07:55 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 6EE61132192 for <dnsop@ietf.org>; Mon, 11 Sep 2017 07:07:55 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id f199so40731695wme.0 for <dnsop@ietf.org>; Mon, 11 Sep 2017 07:07:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eGuWjT9B3LfSznxhp/orsoCgMdhzNhfBS8aAAPaUmhY=; b=UNVd7n9bkygVM5h3dRXreaXRV3hAsYgKDaQsQsTizJnIDxlMjOmBwAUy1lM7pLHk14 Umlh5+hnlHjEFn1dTuN4rRTLbw6ad2KPSi9OQJDHsna72EBGjO9o08EiqBdcLldHuV7r bXdgHqQz2mR7J8WS8l7+MFCbOtgSDu8Fmb4xaiJDDxCULbpJakz3vTwJt+hSW9Ju8AZC 4mRfo7svbw1b3COfg4QFbFMFessH4xXBaqUM2aQGwPR0lcpL3DynkKdi7rZ2Ju49DbFS HnBMZdKq6J1MxJGYce/HYy3t943k+EtZU9Wq06YcqHIIXj1ngeYk2SeNhlrUWgCFCy9h yUnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eGuWjT9B3LfSznxhp/orsoCgMdhzNhfBS8aAAPaUmhY=; b=bs7JFZLauGojXgt4P391hySfFONXHJHVA2UpLqQpDK0rJXzie//fBsO7CDisvrCZ0U uRiDKv/lZCYHpbY9vKuc7Qekip5RckRPURAMxf95+2SenOF6x7ZWZ0U6JEIWt5RxAMCZ GwHoBgYE/gocDUtVi/iQP5YliyVVpPcYxw8V7I1yDuLfV7zOG8HfWSycCyWeW1QKuix6 F07K0DLCW7tnWxs9T9dSRAv5x/pCq63AzYBalhgHXpBMXdX7mfSc+HG8Cv1t5+KzGtQA XMl2ngkYG613pJGZj6yFPGWikurZbxDJR643RbTR+Zv4t9B7IJE+BB624A5rcohkNTBz K54Q==
X-Gm-Message-State: AHPjjUjUiCCMXV0uEu70eMx0M2MR0/ThsCAp9c3faMkXM4PY71GgQS6N m3phEkKUwXgXePJzMr6YeDXfP6nXVSp0vJvoBhdz/g==
X-Google-Smtp-Source: AOwi7QAI7IzSnSnSwoKHuIAf6yUtcG6u7i82r3G/y6XQTPYlkmcwCp97s7UENIsNRIkVQMTjSdNDs/plhU4iw4GMHOY=
X-Received: by 10.28.211.66 with SMTP id k63mr1622234wmg.85.1505138873436; Mon, 11 Sep 2017 07:07:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.141 with HTTP; Mon, 11 Sep 2017 07:07:12 -0700 (PDT)
In-Reply-To: <CAPt1N1kKNRU+mF-JVti_CKS25+7g5BFH8Yko53-VKgZqVreZuQ@mail.gmail.com>
References: <CADyWQ+EZQY9i5-4Ce-NZykwC+sS6iY868Wg0crW6KAZTGQxFQg@mail.gmail.com> <24CD1C88-58C5-4D6C-9F00-E3A2CD8C657C@fugue.com> <CADyWQ+Ex23QVef3AegWB4Jgd-sjG-G4z7XmXL9guN8PeWtsssw@mail.gmail.com> <93C3A47F-07C4-443F-AB87-B5C29F6B6774@fugue.com> <CAHw9_iKBDY9hNThOY3GDeG7BbCkc8Ncy1T=rjpcQ=h5qdB7=UQ@mail.gmail.com> <20170907041659.ED0BB8482BFF@rock.dv.isc.org> <CAPt1N1kXeF0zj_VHuv00taZ+39hR6Nw19uZ5rdxJr3aUeS5RvQ@mail.gmail.com> <20170907045934.C194B848328B@rock.dv.isc.org> <BFAECDAF-8F4B-4C8D-AB7E-1615BD54EF93@fugue.com> <20170908000559.DDBD7849CFAC@rock.dv.isc.org> <CAPt1N1kKNRU+mF-JVti_CKS25+7g5BFH8Yko53-VKgZqVreZuQ@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 11 Sep 2017 10:07:12 -0400
Message-ID: <CAHw9_iJL-Lc84GnMtOERM2oupVrMxKjoYGeumE9K77RwOE4uqQ@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Mark Andrews <marka@isc.org>, dnsop WG <dnsop@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/507aWMPcqgSYnAl-Y0MNQYGNVIg>
Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost
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, 11 Sep 2017 14:08:00 -0000

On Thu, Sep 7, 2017 at 10:17 PM, Ted Lemon <mellon@fugue.com> wrote:
> The discussion had covered the failure mode problem. There is substantial
> agreement that it's better for a stub that issues a query for localhost to
> fail than to succeed. You seem to disagree.
>

I wonder if this is simply people talking past each other, and a lack
of agreement on what the behavior we actually want is.
When I first read the document, and at the beginning of this thread I
firmly believed that we would want an insecure delegation from the
root, but after more discussion on what we want the behavior of
'localhost' to be I've been convinced otherwise.

I think that this boils down to: It is an error to send a query for
localhost (or anything under localhost) to the DNS. The main reason
for this (at least from my reading of the thread) is a security
argument -- you want to be completely sure that 'localhost' will
always be 127.0.0.1 / ::1 / some local equivalent, and this is not a
guarantee we can expect from the DNS[0]. Because of this it is better
the have queries that accidentally *do* leak into the DNS get a
failure (NXDOMAIN) - this avoids having (security important) cases
work fine until there is an attacker.

Is this a reasonable summary? Perhaps once we agree if *is* the
behavior we want we'll have an easier time deciding exactly how...

W
[0]: Without at least DNSSEC, everyone validating, and a trusted
entity running a localhost zone.

> You haven't stated a reason for disagreeing—instead you've vigorously
> asserted that this is true. It's fine for you to do this, but if you were to
> get your way, that would be exactly the bad outcome I want to avoid.
>
> So if there really is a problem here, it would be good for you to make it
> clear. Your stated desire to preserve flexibility makes sense to me, but it
> doesn't contradict the reason already given for not providing that
> flexibility.
>
> Is there some other reason why this is important to you, or is that it?
>
> On Sep 7, 2017 8:06 PM, "Mark Andrews" <marka@isc.org> wrote:
>>
>>
>> In message <BFAECDAF-8F4B-4C8D-AB7E-1615BD54EF93@fugue.com>om>, Ted Lemon
>> writes:
>> >
>> > On Sep 7, 2017, at 12:59 AM, Mark Andrews <marka@isc.org> wrote:
>> > > I shouldn't BE FORCED to hard code special LOCALHOST rules into DNS
>> > > tools.  Lookups should "just work" like they did before the root
>> > > zone was signed.
>> >
>> > Because...?
>>
>> Because there are things you can do with localhost as a DNS zone
>> that you can't do with /etc/hosts, NIS, etc. as they are limited
>> to addresses only.
>>
>> Localhost should work just like home.arpa.  The tools we use shouldn't
>> need special knowledge.  Special knowledge means EVERYTHING needs
>> to be tested to see if it works with localhost as well and regular
>> names.  That testing will get missed.  If it doesn't get missed it
>> costs more money.  Workarounds for different behavior increases the
>> probability of bugs being introduced as there will be seperate code
>> paths.
>>
>> If I want to add a local trust anchor for localhost I will then
>> need additional code to disable the workaround for the fact the
>> root doesn't have a insecure delegation.
>>
>> Mark
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf