Re: [DNSOP] [Ext] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 12 July 2021 22:17 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 617123A12B1 for <dnsop@ietfa.amsl.com>; Mon, 12 Jul 2021 15:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Ns3CvFzd5dN1 for <dnsop@ietfa.amsl.com>; Mon, 12 Jul 2021 15:17:35 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C673A12E2 for <dnsop@ietf.org>; Mon, 12 Jul 2021 15:16:55 -0700 (PDT)
Received: from smtpclient.apple (mobile-107-107-57-27.mycingular.net [107.107.57.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id C97D8D8F6A for <dnsop@ietf.org>; Mon, 12 Jul 2021 18:16:54 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <B32C60D6-B4C7-4419-A3D7-57DBB9BBEFBA@icann.org>
Date: Mon, 12 Jul 2021 18:16:53 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: dnsop@ietf.org
Message-Id: <CA25A87C-9DB7-49FE-A249-04AF801A82B4@dukhovni.org>
References: <CAHw9_iKhvHwUfJMOp-YhJkimmnN0f3DLbh+JWYxhCiZ9CjEEQQ@mail.gmail.com> <B32C60D6-B4C7-4419-A3D7-57DBB9BBEFBA@icann.org>
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/w7JBD4czpGKr46v-DlycGbOv9zs>
Subject: Re: [DNSOP] [Ext] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
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: Mon, 12 Jul 2021 22:17:48 -0000

[ Resending complete message, previous draft was incomplete... ]

> On 12 Jul 2021, at 11:18 am, Paul Hoffman <paul.hoffman@icann.org> wrote:
> 
> The current text is sufficient to tell resolver developers, and resolver operators, why they should even think about underscore labels when they create a QNAME minimisation strategy. Elevating such a strategy to a SHOULD as a work-around for broken middleboxes that might (hopefully!) be fixed in the future seems like a very wrong direction for the WG. 

If this were just a work-around for breakage, I'd be more inclined
to agree, but it is also a solid opportunity to improve performance,
because privacy-relevant changes of administrative control across
special-use labels should be very rare to non-existent.

So short-circuiting qname minimisation when a special-use label is
encountered seems like a win-win.

Measuring qname minimisation for TLSA RRs I see that today breakage
of qname minimisation is rare.  An example is:

	https://dnsviz.net/d/_tcp.u24.altospam.com/YOx4nQ/dnssec/
	https://dnsviz.net/d/_25._tcp.u24.altospam.com/YOx4IA/dnssec/

In which many (but not all) of the nameservers return NXDOMAIN for the
ENT.  Out of 150k RRsets, O(10) have ENT-related issues.

So one might reasonably neglect the breakage, but it is not clear that
we need to go looking for it, just to "punish" the operators in question.
There's an opportunity here to make qname minimisation more performant for
SRV, TLSA, ... lookups, speeding up Domain Control and LDAP server lookups,
email delivery, ...

Of course if the WG cannot come to consensus on "SHOULD"/"RECOMMENDED", I'll
gratefully settle for the current "MAY" (thanks for the document update)...

-- 
	Viktor.