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

Ted Lemon <mellon@fugue.com> Fri, 26 January 2018 20:24 UTC

Return-Path: <mellon@fugue.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 DBBB812DA68 for <dnsop@ietfa.amsl.com>; Fri, 26 Jan 2018 12:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-com.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 ZRVHFEqVnrcH for <dnsop@ietfa.amsl.com>; Fri, 26 Jan 2018 12:24:36 -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 EEDED124B17 for <dnsop@ietf.org>; Fri, 26 Jan 2018 12:24:35 -0800 (PST)
Received: by mail-it0-x231.google.com with SMTP id 196so3030041iti.5 for <dnsop@ietf.org>; Fri, 26 Jan 2018 12:24:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=Y4B8hYxS15qL5qqMpANqifXIBWWpNRIMqQHHTcGbBX0=; b=SlkJhhaOrd+AUpmFOwaKlcVh5Z0QRRMaNgtBUQ/kYNJ0gEouAIyjIeSy1qaqe71rL8 M++6Xd2bmankJJcEChcNf9zKg4SGoSVOoX8NJeqf0j/XCnbGPgwdHuWbLL0FUah/yKk7 QJ081UQu59sSfgIk3ZrmD+UmQ6yr3Fo4DqMnuH3hjUv6Pvsmf81yWjf0Qj+ZhgeVLUTF kpeH14/dPaxeRU2SSKKOShfQtCAkdGW0LDCWy51Q69MWztDwesYrMI+kWxGuxTsKumLh v7S2zbuL0Wc1+ehQMx74dRYlMGiaCy2//+12NB2zkzzScbXfPRPbnme8Zhhwd5ztklZo LOjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=Y4B8hYxS15qL5qqMpANqifXIBWWpNRIMqQHHTcGbBX0=; b=VQX5q9fnPgDFOh/H9wCfw8wccAkswSGRTU4KbgDqg4DcWNqpYPQGvSlUDt2F6E2xeN s+0WJkkXOAO5Hux/5QnnpZYMQd7b4m8RBLxRCET68I6nKm8B0HCUgP27iqq7bPAW9e3s W5+vcbxmk6Fmo423SCaw0qmj8jxmqGLL5cvUIUmPaGy41lON2nDBvExED8wy5lJAYiI4 whA2JHn4mONAqL+xHGkLE/M8OMdNEzXcfxzg6/cgdKsMs1EhqHIZv6Bbb/75dj9Wim/0 KWXy+G/mIumSZiJefM/8j9NW953fJqRqUpgjAlAsxUiH9Xyh5jLnj8qpFM8O6b2INxaR UjGg==
X-Gm-Message-State: AKwxytfwRcMzlDMw31Qk95ql4vD+GbIjBm1Ydweniuo8cysbNTS6eron 9115N7sYbyBDs83w9sWJI7GL+a4hJgI=
X-Google-Smtp-Source: AH8x225xV9nJBCYucJ0pk4lRrUVjE1dkefv7KhkUfxd75lhJTOzt81z9RAf7WA+GhmkNGfUI65EYvQ==
X-Received: by 10.36.13.5 with SMTP id 5mr18106394itx.68.1516998275158; Fri, 26 Jan 2018 12:24:35 -0800 (PST)
Received: from [172.19.131.146] ([12.130.117.63]) by smtp.gmail.com with ESMTPSA id m145sm376287itg.22.2018.01.26.12.24.33 for <dnsop@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jan 2018 12:24:34 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1C30179E-6B8A-49FA-9F21-8A4F6F536DE9"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Fri, 26 Jan 2018 14:24:26 -0600
References: <CANV=THh6bOxd_UW=TuLonWzz0KyGapkGWpMiNuu54W=45gFAvg@mail.gmail.com> <20180124205620.GZ3322@mournblade.imrryr.org> <alpine.DEB.2.11.1801251558440.5022@grey.csi.cam.ac.uk> <CAJE_bqf+GqYGFRAsXbBPymQLXoJRs_AxvVHhtcMJF1LEvTL7sQ@mail.gmail.com> <77B805CC-E8FE-4B09-A261-C5CB13707EE4@dotat.at> <CAJE_bqdCZ_vj2nncvEVpYunVmE=xxAiXqrzhu8BGxnSsLjy+3Q@mail.gmail.com> <37A9F504-A8BE-4F47-AAE9-AF2458206F03@fugue.com> <20180126201613.GK3322@mournblade.imrryr.org>
To: dnsop@ietf.org
In-Reply-To: <20180126201613.GK3322@mournblade.imrryr.org>
Message-Id: <B17E9259-BC28-4861-8102-B716685C75B3@fugue.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1jnjwuxFc6MU3z29nhSnRBMw14s>
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, 26 Jan 2018 20:24:38 -0000

On Jan 26, 2018, at 2:16 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> Disagreed, with respect to recursive resolvers, because the
> requirement is neither necessary nor sufficient to achieve the
> stated security goals, is not required for interoperability, and
> is in conflict with existing uses of local data for localhost.

The point of the requirement is that it breaks stacks that use DNS to look up localhost.   If you think there's no risk to applications that rely on this, obviously it's not worth doing.   The reason I'm being such a stickler about this is that we have beaucoup experience over the past two decades that if there is an attack surface, somebody will come up with an attack.   It's better to fail safe than fail unsafe.   If apps are breaking all over the place because they use DNS to look up localhost, then we all win in the long run.

That said, I absolutely do not want to deprive you of the ability to do your hack.   I just don't think that the current text does that.   If the way the stack accomplishes the MUST is to have some code in nsswitch.conf that does the right thing, I think that follows the MUST.   If it were really true that that were not the case, I would agree with you.  (And as an aside, you are correct to point out the error of my statement about localhost versus home.arpa.)

The reason I drilled down into your use case is that I don't think there's ever going to be a time when Christos disables this behavior.   So I don't think this text is going to actually create an inconvenience for you.   That's not the point of writing that MUST.

Is there a way we can change what the text says so that it's sufficiently emphatic to make me happy, and sufficiently open to make you unhappy?