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

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 07 July 2021 18:33 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 E67E83A23E5; Wed, 7 Jul 2021 11:33:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.com
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 Br-Zl3d7ooVs; Wed, 7 Jul 2021 11:32:56 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 F1B913A23DB; Wed, 7 Jul 2021 11:32:55 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id p1so6396292lfr.12; Wed, 07 Jul 2021 11:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2r5TluebV5VbdJQMMjaoRVZJIQVqmBvcKcOGfDzlE6s=; b=isxCog3PxWfL6YwuSSYAy/3xx8zQnzd88XNy5XpqoeZx2mYHAjRErIzZfusdsTsscM IeqAdnzLhkQpIod+/9jUwLaAkqVOkEsX6xLOk3yzjnoVmuW9b7O3yrxu6TBSw3i+pd5R 1RfpyBZU2kEyvUvYw+IZhpGYCBA7PHbwXiQRvTujcflv16KHgLs5LshLaNESQJ84omST Rl0djyuA4qELw+Z1gp1hYK3prMbZyfjw9odt4wwhHm+B5WpIewJzw+MvtBcSv/HROZ6q RL/Osu6zDD5UaXAzl2VS8P71ItYqzniQSlXiOU+/BzY0Z9cr96yAeOTJZLOyW/HFZnsd DyNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2r5TluebV5VbdJQMMjaoRVZJIQVqmBvcKcOGfDzlE6s=; b=TFiX7r5ihaDTa1XDTEVkuwpMFo0PN3PBKeFsctjXEiIsu4QpQ5V4yMpoMRplyVG3F/ F4tkPW3XckuECUJ3Ry6jQFUmRaKkE0U3XIKSUs4Z00TGcm6tRqwToTn3WyX9XTPS4Li+ 38BYHNYkn58uARvztS9uxXeYnx4pF/aJeKmpjyRjFji9tg2Y5uv72R7egHmZHCHwV2ZB xUuy/e5m3dHrfORiTwWYUcdeSxIy/b8ppyiLwe3kUb3/4DoUoUFMm3Dx5M9dLoL5xwjT vIAFx56NqhxjHiXvw4z3xCMOUZDsrktp5oF+wUp41uynLUVnp9Lg5t9q0PCKwnC5rxn4 68yw==
X-Gm-Message-State: AOAM533bNGWgVO4W0WU3i+sOBH7yQEjqs1qXrBzzUS0WdxlgTlYHhoze cqmmivU9udOrjAlUx3XzPMHbf28fwaaU6BtAjsy9LXSx
X-Google-Smtp-Source: ABdhPJznED1BT3iAKyJmIkketM5Wmt35NoCmKFbHvbiduzgLfAJR3pCC+7u6AEaI90j/6BcmGXC3zgYVRo+RErT66Ew=
X-Received: by 2002:a2e:9e8e:: with SMTP id f14mr20305735ljk.468.1625682768791; Wed, 07 Jul 2021 11:32:48 -0700 (PDT)
MIME-Version: 1.0
References: <CAHw9_iKhvHwUfJMOp-YhJkimmnN0f3DLbh+JWYxhCiZ9CjEEQQ@mail.gmail.com>
In-Reply-To: <CAHw9_iKhvHwUfJMOp-YhJkimmnN0f3DLbh+JWYxhCiZ9CjEEQQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 07 Jul 2021 11:32:37 -0700
Message-ID: <CAH1iCiqbcc+PmnTKOJzoEMYG+tvOa4HsfKt2tRq3y8R7OQSNFg@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: dnsop <dnsop@ietf.org>, DNSOP-Chairs <dnsop-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f38b5a05c68cc32d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/z0uRS12XAbL3gkOjvkXWU_DFr-Y>
Subject: Re: [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 18:33:02 -0000

On Wed, Jul 7, 2021 at 10:55 AM Warren Kumari <warren@kumari.net> wrote:

> 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:
>
> https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/
> and
> https://mailarchive.ietf.org/arch/msg/dnsop/_H4aM5AquCSRlz0Pz3ncwl7Plpk/
>
> 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?
>

Yes.


>
> Should the advice above be strengthened to SHOULD / RECOMMENDED?
>

Yes.

Brian


>
> 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!
> W
>
>
> --
> 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>