Re: [DNSOP] Accounting for Special Use Names in Application Protocols

Mark Nottingham <mnot@mnot.net> Tue, 05 February 2019 01:46 UTC

Return-Path: <mnot@mnot.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 4621D130F34 for <dnsop@ietfa.amsl.com>; Mon, 4 Feb 2019 17:46:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=kTFFrPp4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Iu68MzlH
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 cnPnnp6Ntaht for <dnsop@ietfa.amsl.com>; Mon, 4 Feb 2019 17:46:35 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDB7130F33 for <dnsop@ietf.org>; Mon, 4 Feb 2019 17:46:35 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 66D9C2217D; Mon, 4 Feb 2019 20:46:34 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 04 Feb 2019 20:46:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=1 PzOo6l6YMQ+3yN6LKXKTmRzEnI9UeSzis2RoPRCfD8=; b=kTFFrPp4cVRsqkJFV qK3JmZetATl0CUWdN/A0MmFG6vzGCgqAfaaO+e+rr2fO3LjCH2ATfRess0/QUO7Z RsbWK3boGD2lvDZVx1lwlSQ9M9+resAoVVtaQdR4tVMhZ012W2Qga4xomnsowSiw B9zyZBTcPNaE18yKqe13YgcTPMHiob69UuEipmc9l2e8g/ZvAU6a1lGu9guBVlxl KCZWF8AK4k2vCr05eaTDAe6SqjYORdQU2E9MRq6qAWXR8dtZjHpuUVYSvHa8usMD OKEm08EpUBJmx0AiZg5X9kRMexzm2f7WavEgRRjlFrsZFQtqSGd/qpMaXL6bkhoJ acs1w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=1PzOo6l6YMQ+3yN6LKXKTmRzEnI9UeSzis2RoPRCf D8=; b=Iu68MzlHL7/EUYAf0aJRzKOOPO9NLng0WL4y7aMk7HfikLMiTbIYWHMkg 1Am794cA25C3im0wOC4oSrRaa0mEKd+tcSo5sH47KJC+yhHizl8xv0zBpsGUwMtH M/P47biv33kCGKVgz+lH+ZTlvSsKYLZZBc1Boz84frHDodmE+vTOwg+JWDStlfXs J4szi3FPBA9AJPu50CM9r+5qZGjdS/Mg9cWXT4ezp/OfO2+J/L+hRP97lIZpP03j 1G8aU9g50evYpd70iedZiPyMs1rrLlMCRTD6jXZm+nDoJcTPK8ZdWU4xYd276f6a doah7A/JpMDRxGXlhWweeCZzC5lLA==
X-ME-Sender: <xms:-OpYXLZRC5yNVkXjeDngTI510Y87dRHaCu7nVc7sa7GAuQE_tENQmw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeehgdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffgf fkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcu oehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepmhhnohhtrdhnvghtnecukf hppedugeegrddufeeirddujeehrddvkeenucfrrghrrghmpehmrghilhhfrhhomhepmhhn ohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:-OpYXLIdeSptjEyPdfKJnNzW4MoxvnxmOE4rq55-ANljSuqlf2YiUA> <xmx:-OpYXKGvhzFGVEJ1hyLnU5FUfH9APznIJU7ziD_igA34zXO3wTCgUQ> <xmx:-OpYXCvkBJPtq_YV2OxwrRV8CbR2TPYOHInGVz9_fVUxS2RfwxqQSw> <xmx:-upYXIINgC4F3Zgt3azIA2SIKPqOepCHaN-j_hSfJjdahWTLwRdyAQ>
Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id EF086100BA; Mon, 4 Feb 2019 20:46:30 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <E27B341F-ECC3-4453-BC10-0EB70ED484BB@hopcount.ca>
Date: Tue, 5 Feb 2019 12:46:26 +1100
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, Tony Finch <dot@dotat.at>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <76E8CB4A-47C9-4A66-A90C-379E121F8B9B@mnot.net>
References: <0A018ACB-9958-4202-9263-00EA864E2C5C@mnot.net> <CAH1iCipj0pxP+xD_QSy7CCo4KOPBGKr8Qn4aX5YuJw+E1GV0aA@mail.gmail.com> <alpine.DEB.2.20.1901081213100.3160@grey.csi.cam.ac.uk> <CAH1iCip3C-4YchDLur3AFSmQhzouVdP-VGcbt0F6Sj9dEse3CQ@mail.gmail.com> <057BE2A8-2F36-4458-AE7A-8FC06ACF7C11@mnot.net> <E27B341F-ECC3-4453-BC10-0EB70ED484BB@hopcount.ca>
To: Joe Abley <jabley@hopcount.ca>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/68QElLqGpE_f-mDFq0JMv1-Vl5E>
Subject: Re: [DNSOP] Accounting for Special Use Names in Application Protocols
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 05 Feb 2019 01:46:38 -0000

I like it; will append to the issue. Thanks.

> On 5 Feb 2019, at 11:50 am, Joe Abley <jabley@hopcount.ca> wrote:
> 
> Hi Mark,
> 
> On 4 Feb 2019, at 19:30, Mark Nottingham <mnot@mnot.net> wrote:
> 
>> I've modified that slightly to come up with this proposal:
>> 
>> """
>> HTTP and HTTPS URIs rely on some name resolution mechanism(s) to interpret the authority field and ultimately convert it into an identifier (typically, IPv4 or IPv6 addresses). Often, this is DNS [ref].
>> 
>> When DNS is consulted for resolution of the authority field, this specification requires adherence to the requirements that all registered special use names [RFC6761] place upon applications; if they are not honoured, security, privacy and interoperability issues may be encountered.
>> """
>> 
>> Make sense?
> 
> I confess I have not being following this thread as closely as perhaps I should, but the text above strikes me as odd.
> 
> RFC 6761 describes a registry of special *domain names* -- it's talking about the namespace, not the resolution protocol. In some cases the registry directs applications to use different resolution protocols (protocols other than the DNS) to look things up. The LOCAL and ONION domains are examples. It's the contents of the registry that are important, not that subset of initial registry contents that are specified in RFC 6761, as I think Tony pointed out.
> 
> The text you suggested could suggest that an application should consult the DNS for a name that ends in LOCAL and simultaneously satisfy the requirements implied by LOCAL's presence in the Special-Use Domain Name registry, which include not using the DNS. This doesn't seem particularly clear.
> 
> Since I've been staring out of the window for the rest of the thread thinking vaguely about lunch it seems a bit presumptuous to suggest alternative text, but perhaps something like this would be better:
> 
> ---
> Resolution of the authority field MUST adhere to any special requirements documented in the Special-Use Domain Names registry [ref] which might specify that some protocol other than DNS be used for resolution for names within a particular domain. If those special requirements are not honoured diligently, security, privacy and interoperability problems might well result.
> 
> For example, consider the authority field EXAMPLE.LOCAL, intended to resolve to an address on a local, private network using the Multicast DNS resolution protocol [RFC6762]. If the DNS was used as a resolution protocol, the existence of the local-scope name EXAMPLE.LOCAL and this particular instance of its use might be revealed to third-party DNS servers; there is also a risk that attacks on the DNS system outside the local network could cause the EXAMPLE.LOCAL name to be resolved to an external, third-party address with attendant risks to privacy and security for higher-layer protocols and the application itself. Such risks are avoided by ensuring that resolution of names in the LOCAL domain are only attempted by the application using the Multicast DNS protocol.
> ---
> 
> 
> Joe
> 

--
Mark Nottingham   https://www.mnot.net/