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

Warren Kumari <warren@kumari.net> Wed, 07 July 2021 17:55 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 926B63A209A for <dnsop@ietfa.amsl.com>; Wed, 7 Jul 2021 10:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id iGj3zDWlK_xf for <dnsop@ietfa.amsl.com>; Wed, 7 Jul 2021 10:55:16 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 3F3733A2099 for <dnsop@ietf.org>; Wed, 7 Jul 2021 10:55:16 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id n14so6073921lfu.8 for <dnsop@ietf.org>; Wed, 07 Jul 2021 10:55:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=TDXZkIzFd1ZJ2lFiQ7hDGCZvvFiquWcfgVLx27pEeNk=; b=ipeo+OEGyAwyDnJ99tGNlkLPSF1Otms29F0cIOJdTvH/2EEovH7IYcP5RAC4IR5frI NEBg3U+J1glPpQ2oEn4D6L8YGFDOPOjSSkeOCh7rltWl5jfZitnVX9U9bw7riE932PWU BIA6mx1bpYUPUX5wDUPyvghDWv61Tt7xrocFgYY8xPvaVG/GWUBymGCcD5Ek4X5lheuM +VY6+kICVxSmQKKXz/iiW+lwl8yH8Mw1QnY51/Oq48/y9rvMuhyIIHgTKOSTwhBpXMDk aJpAk4/0iWfG3SawnWPQz0i+6QEcjR3V1eklHanRQy4ApZLazyKgdCjG7XJ1lLWJodCZ 0AFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TDXZkIzFd1ZJ2lFiQ7hDGCZvvFiquWcfgVLx27pEeNk=; b=mjg8M+sD0IpjFTThb5t+s/qZYaY391SvtOALjHBCIkRu/7g0l9ZrRZd/7R1DlvcIHb ErD232YCyTT2wPGVW2JV+mUJ6EW8sd9Fnju3cIgqdOGxs9bneU39Gag3zHovTOgcK0vF dq+tQfjMrygxKl1HxqF6jj75Gop7SUTqMTcyFz/Zau3doSTeX/pSLumjTPnZfb6EycMR hIn/VC+0TI9veVT8w1/FS5Yy1qMtIA5Cf2GqPAUAQgPmSh8L3RtRFNMAy1aoOIebNGby qwU9CIsbYvd5S7wanhCzeuILIS3C3+GwWpge3ZGzMxYPcslAQ3scGPC57UdwrzzD/6z9 VFng==
X-Gm-Message-State: AOAM533Xe9SBCW0rlqwxuzw6ASEi1S9NOGj47naeQsB8o55hmyLfIHVQ qXusV3AJMnJFCSp2p+FTAnawK8ZKRBIln1HDZf/F1U9BdsYk/g==
X-Google-Smtp-Source: ABdhPJy0uj56o89oEBjT2XZtI/qIihn18JAT7pqjiKz7p1oPZ2foZZuNxHXG81Xe4qb+Xls5LGTSC/xKciZf5hQxD+Q=
X-Received: by 2002:a19:dc03:: with SMTP id t3mr8744798lfg.464.1625680512698; Wed, 07 Jul 2021 10:55:12 -0700 (PDT)
MIME-Version: 1.0
From: Warren Kumari <warren@kumari.net>
Date: Wed, 07 Jul 2021 13:54:37 -0400
Message-ID: <CAHw9_iKhvHwUfJMOp-YhJkimmnN0f3DLbh+JWYxhCiZ9CjEEQQ@mail.gmail.com>
To: dnsop <dnsop@ietf.org>, DNSOP-Chairs <dnsop-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6P6MS881ZdHnbtnwP7q8Q74_pw8>
Subject: [DNSOP] 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: Wed, 07 Jul 2021 17:55:21 -0000

Hi there all,

I wanted to check the consensus on a point brought up during IETF LC /
OpsDir review of draft-ietf-dnsop-rfc7816bis.

Please see:

If resolving " _ldap._tcp.ad.example.com", once you hit the _tcp label
you are quite likely in ENT territory, and some implementations
(especially those behind firewalls / middleboxes) are still broken.
There is also a performance hit.

Version 10 of the document added:
"Another potential, optional mechanism for limiting the number of
queries is to assume that labels that begin with an underscore (_)
character do not represent privacy-relevant administrative
boundaries. For example, if the QNAME is "_25._tcp.mail.example.org"
and the algorithm has already searched for "mail.example.org", the
next query can be for all the underscore-prefixed names together,
namely "_25._tcp.mail.example.org"."

(unsurprisingly the document does a much better job of explaining the
issue than I did :-))

Viktor is suggesting that QNAME Minimization should be stopped when
you run into an underscore ("_") label, instead of this being worded
as a potential, optional mechanism.

Obviously there is a tradeoff here -- privacy vs deployment.
1: while it's **possible** that there is a delegation point at the
underscore label, (IMO) it is unlikely. If there is no delegation, you
will simply be coming back to the same server again and again, and so
you are not leaking privacy sensitive information.

2: some recursives are less likely to enable QNAME minimization
because of the non-zero ENT and slight performance issues.

What does the WG think? Does the privacy win of getting this deployed
and enabled sooner outweigh the potential small leak if there *is* a
delegation inside the _ territory of the name?

Should the advice above be strengthened to SHOULD / RECOMMENDED?

This is after IETF LC, but as the question was raised during LC, I
think it needs to be discussed and addressed.

I'd like a **clear** input, on this question only, by Tuesday August 13th.

Much thanks!

Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky