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

Viktor Dukhovni <> Wed, 07 July 2021 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E36C33A2532 for <>; Wed, 7 Jul 2021 12:01:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z6Z31SpIaZoJ for <>; Wed, 7 Jul 2021 12:00:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 388013A255F for <>; Wed, 7 Jul 2021 12:00:49 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 3212BD5374; Wed, 7 Jul 2021 15:00:48 -0400 (EDT)
Date: Wed, 07 Jul 2021 15:00:48 -0400
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Jul 2021 19:01:11 -0000

On Wed, Jul 07, 2021 at 08:46:17PM +0200, Peter Thomassen wrote:

> Especially because of the last reason above, I tend towards MAY.
> However, I would endorse SHOULD / RECOMMENDED if the wording is
> changed such that "skipping a split" is done "up to the lowest-level"
> underscore label. In other words, jumping from to
> would be RECOMMENDED, but jumping from
> to would not, because
> "foobar" is no an underscore label. Generally, if there are N
> consecutive underscore labels, minimization SHOULD be skipped for the
> N-1 of them which are closest to the root.

I appreciate the caution, but resuming qname minimisation after skipping
a few labels does look rather complex, it also defeats the main goal of
avoiding known issues with likely ENTs at a name that is rarely a zone
cut, and even if a zone cut, likely not privacy relevant.

There are upcoming drafts on DANE client auth where the leaf label will
not be an "_" special-use label, but its parent is.

For the same reason that asking for " IN A" is
likely to run into trouble or at least impose excessive latency when the
leaf label is "_25", I'd like to *recommend* that qname minimisation
will do more harm than good even if the leaf label is "some-client-id".

I'd like to the see the tradeoff lean heavily towards "practical"
privacy enhancement.