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

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 08 July 2021 16:15 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 0DD1E3A274F; Thu, 8 Jul 2021 09:15:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 tdpgtjHah-Lw; Thu, 8 Jul 2021 09:15:54 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 E62B33A274E; Thu, 8 Jul 2021 09:15:53 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id u25so3297402ljj.11; Thu, 08 Jul 2021 09:15:53 -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=U7RCCk3UQX/yV16m7dfXAIe5U36/JxmzlOhtOZ/lbkg=; b=r9pDdR9VPZq6UtHlsRRQuqrj/93R9duMIVD++OPxfPT30R9RJpHJXIkEkOTA8bQR1V 2QLnrsTQIOmXoGSr3mdmrWDraMllTV1joQi2C2g4QqAc5FeGTordfQ/P/kTkfcD/CKyg AUyQKOoskup7YFTiFD+CtdrilYCW/up09fcRnzpxGBkTO6P3g9AtdSkLkAhQjYg+M/0W sH04fUf3GxortE6qxQ/vLBAd5cqi6A9uFGUE8vkaE3vKuk+RXCz7AAecbngoBYlrGOxf HB24uho09qvXUfMz+31kUWIwdbkxPAYnc8r9+6zGPfuW1cKl6Ce5Lfxn8aaQSfc9W8PR czCA==
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=U7RCCk3UQX/yV16m7dfXAIe5U36/JxmzlOhtOZ/lbkg=; b=LXOSsJYBz1kClgRt0+EDLbiqRopfKXy6b6HE+siu5lMz7Q5T6A6RDq6V8YRYP0Ic48 aEJ1fr+Dqt2go6GHTvIr7+0TidqLxVmNj/TokYzgEUQy+d1cUj8lHvdBYL7Do+Y2ToXE DUdRzjSdFFVD6zUFtrZUSp4PFSMZXGG5dTlMPN0k67lWujiL/o8mI4QV77H8+AWS86rh gEB+OpdAJwlrvK0CAslx8GSqFBn3yyFhNU+g9L2XVtbof5jwayV7u4ioyW4Ga8dY5shU NexnQTgPz0qtfqKhB+P+FzNl1FD3QO/u3t6M7JSkjz3nME9Iw9AfD/i44Ly8bvO+RSB3 KS1A==
X-Gm-Message-State: AOAM531ZvtO2OrebjBF/yRi/cnx8ljeccsknSKT9/yaRi0ky4dVu8mZi jWn0CDuZLf7FuR9O+iFiadViKjBrmNVuf8DQcFw=
X-Google-Smtp-Source: ABdhPJzD/Fr0X/lnqsdDDvtPmRbj3MUEe6kbV+TzAy/1nf2qZpk5uUpfdJdObGCU2q9bdY4msYrUyMDw1frUtbg2v0U=
X-Received: by 2002:a2e:9c84:: with SMTP id x4mr20235273lji.161.1625760951323; Thu, 08 Jul 2021 09:15:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAHw9_iKhvHwUfJMOp-YhJkimmnN0f3DLbh+JWYxhCiZ9CjEEQQ@mail.gmail.com> <0ed6efa6-c981-fa64-472c-eef0c5453f4a@isc.org>
In-Reply-To: <0ed6efa6-c981-fa64-472c-eef0c5453f4a@isc.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 8 Jul 2021 09:15:39 -0700
Message-ID: <CAH1iCipP2C0fPgFYBGeR3Esvzf4eMxVv+EJKgKkfSiVX3MCqnA@mail.gmail.com>
To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <pspacek@isc.org>
Cc: Warren Kumari <warren@kumari.net>, dnsop <dnsop@ietf.org>, DNSOP-Chairs <dnsop-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fe50d305c69ef779"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RSOulc2a3B_DJenKsQ8u1ddts64>
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: Thu, 08 Jul 2021 16:15:59 -0000

On Thu, Jul 8, 2021 at 7:29 AM Petr Špaček <pspacek@isc.org> wrote:

> On 07. 07. 21 19:54, Warren Kumari 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?
> >
> > Should the advice above be strengthened to SHOULD / RECOMMENDED?
>
> With my implementer hat on, I say "no", I don't see a compelling reason
> to "mandate" it.


Did you actually read what Viktor wrote?

It is a known fact that there ARE implementations where ENT handling (on
the authoritative side) are broken.
Given that the vast majority of the first underscore queries would be
hitting ENTs, this would seem to me, at least, to be compelling.

Why would you not strongly suggest to other implementers to avoid this
problem (by stopping the QNAME minimization)?
Even if you, as an implementer, choose to ignore the problem?
(Also, does your resolver code actually handle the situation during QNAME
minimization of broken ENT handling by authoritative servers?)

Respectfully,
Brian Dickson


> Keep it at MAY/optional level and leave it to
> implementers to decide what's best for their implementation and use-cases.
>
> Thanks.
> Petr Spacek  @  ISC
>
>
> >
> > 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.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>