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

Joe Abley <jabley@hopcount.ca> Tue, 05 February 2019 00:50 UTC

Return-Path: <jabley@hopcount.ca>
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 80D63130EE7 for <dnsop@ietfa.amsl.com>; Mon, 4 Feb 2019 16:50:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 I0Sd56aa7T9C for <dnsop@ietfa.amsl.com>; Mon, 4 Feb 2019 16:50:23 -0800 (PST)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 8D374130DF1 for <dnsop@ietf.org>; Mon, 4 Feb 2019 16:50:23 -0800 (PST)
Received: by mail-qt1-x82f.google.com with SMTP id t33so2153692qtt.4 for <dnsop@ietf.org>; Mon, 04 Feb 2019 16:50:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vCZU26g2yoLqH2i/dIyMUbjTLfYl1zPrfslBlkKdPvQ=; b=fw2n3wd33FOxKgICROZs3fnWjBUDUAh9bBB9tUntzqS1PEfHsYUvH+mxA92gIEoOP6 mZiNSiB5uwik9y9WTyEfIYVfOqYbCloMS471NCNBzxoEx5GGAGssTyt6zdsR2Laf0I5h ASymnOp3JOHi8vASPQXGpcMoVTqhgfCuFuP8s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vCZU26g2yoLqH2i/dIyMUbjTLfYl1zPrfslBlkKdPvQ=; b=XsHpDkml329aTCRsXkGLuPTox90f4dNLDQCFVeYEFIw54AFazW4QBdEVG0ThppkPJi dE+5SRbRI8hMoQCgUXVGodjIWUzg280g7qJhgUUbh8VPZLxl31efRtPPBCiUgpg3X+jL KcsbOzpLyK34zStkTTPNVNnMhe/Mphtq2TBYsF8ipMQ/18UlSICUChQlVeGHBUufQEWu zO9t9vmZWA7/B+zXi6EkM8bwSZDJ06H97XkRyZYRB84RKL/tbj4lgwhPwREe5TFM2krz 0oJzqlVkgypWlqEL3FKHjDZvW97xMJAEJX3TuSa0K8g6dC7gY9nXa8HFLSMd5foyp1aH 8rhA==
X-Gm-Message-State: AHQUAuZ/jNUipDRJEJY3URbyAvP5znUkpAed37YZ/v4lT0q+R1oLAGJJ 5qvL5IuO3teRXP2ikhrh8VsyHA==
X-Google-Smtp-Source: AHgI3Ia/HsqOQA9su1qAhhM8nvg88POX0QERWtpooDmyqgRVYR3VOmqyht7Xuc5ojqLxMMbgOIUlbQ==
X-Received: by 2002:ac8:7096:: with SMTP id y22mr283743qto.334.1549327822617; Mon, 04 Feb 2019 16:50:22 -0800 (PST)
Received: from [199.212.90.100] (198-84-215-70.cpe.teksavvy.com. [198.84.215.70]) by smtp.gmail.com with ESMTPSA id q53sm2553766qte.22.2019.02.04.16.50.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Feb 2019 16:50:21 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <057BE2A8-2F36-4458-AE7A-8FC06ACF7C11@mnot.net>
Date: Mon, 4 Feb 2019 19:50:19 -0500
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: <E27B341F-ECC3-4453-BC10-0EB70ED484BB@hopcount.ca>
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>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/h5nOgGxYR0p3zWobm6caL88AFWk>
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 00:50:26 -0000

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