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

Ted Lemon <mellon@fugue.com> Mon, 05 February 2018 06:10 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 05535126DED for <dnsop@ietfa.amsl.com>; Sun, 4 Feb 2018 22:10:18 -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 i9Nc2EStr7yR for <dnsop@ietfa.amsl.com>; Sun, 4 Feb 2018 22:10:16 -0800 (PST)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 CA998126D74 for <dnsop@ietf.org>; Sun, 4 Feb 2018 22:10:15 -0800 (PST)
Received: by mail-qk0-x22c.google.com with SMTP id c128so114568qkb.4 for <dnsop@ietf.org>; Sun, 04 Feb 2018 22:10:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lONpL499kj8AUukpiX/4eFrlB315SqEsMzaP3v0TEug=; b=ICN6D313ZR/SWvyXYoP/ReDwdMGmhkqehwOM4xifn4781xgVi4N87Mhi2g4PbKjntE jSPBRCgFIzUGecp5/U8pm6GXvbox4nzmQrWRF4NSM3359b2mxQHdLm+5+NqOLYZk0D59 19WXuKa+Rq+JIYkPJ2iyUmbxFCa78fxzekf/7EZ4VtRyh78ITF2+Hu+gXk/Lxx9JzpZc 4PrJdkHIJ3tKOb3qHHFQzoGXS8q3WfC5LhLj0QdVwPHFIpnltTkTRsR/ukWM1L5ifkeu p6PHBwFOqgtmGhkO6xpK7iGgr+5R1KkOKhu6Y63L9lNALGGEdl/D8ypuLXgQIMlp7MXS OB0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lONpL499kj8AUukpiX/4eFrlB315SqEsMzaP3v0TEug=; b=D1xgXB7MvQZqZkAcA7gKymNfZ/Fxgy/n9o9sRxXJkX8W/WT/RafYr3FqK/GPS8HoF0 D/TwCFMHrTSL1OyHeDaOCPHZrd8/dAHOfNW2mML81ew5P0WbOTCrctLcDYL4VZfkdFsl 8S38IBJl8nMltkdvBK1CnppehnHPl31IX3QrVoeoSo5VI78Bs+IXRvMD9+5JXCh0AkwG pmHGcttCKYeeqhjcRF9AHlUKO5987xZ4Sdxo5QbAaCMpBC1q4T5SInW6azM4usXG4vHK Wfj2ddf8nAVOG1GT8rbSiAJRsDxkSBiKQaL85xGn76M/RYf62RLF9f2+y/1Gy4zOxLwX zkGg==
X-Gm-Message-State: AKwxytcHwMy8+V38TgjVncBXd5NmnObepr3QRnSntModvUVwMYghcbNL avNTu3P2FPglZOG1bdyQgECYCLjW9v0=
X-Google-Smtp-Source: AH8x227eft4mXAuXyn1en7OjfLJYCNFZ78SUe9QkiDDH1kgVcgAI4NM4KFo7t01Ys1uuWNRz6IYGug==
X-Received: by 10.55.128.135 with SMTP id b129mr48493359qkd.187.1517811014824; Sun, 04 Feb 2018 22:10:14 -0800 (PST)
Received: from [10.0.30.153] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id e5sm4759199qkj.64.2018.02.04.22.10.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Feb 2018 22:10:13 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <618D31E1-8EC7-4F75-BD97-31D42CB1E681@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_185104E0-7C2C-4D53-9A16-A2E8536D8215"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 5 Feb 2018 01:10:10 -0500
In-Reply-To: <E4C5AA7E-E9C1-4E53-ABE0-676A9B7B3269@isc.org>
Cc: Lanlan Pan <abbypan@gmail.com>, dnsop <dnsop@ietf.org>
To: Mark Andrews <marka@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>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7b7j6dYIVQ5X26bx9Xv28y58MGU>
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:10:18 -0000

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

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

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.