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

Petr Špaček <pspacek@isc.org> Thu, 08 July 2021 14:28 UTC

Return-Path: <pspacek@isc.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 E31BA3A1F18; Thu, 8 Jul 2021 07:28:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level:
X-Spam-Status: No, score=-2.436 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, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=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 (1024-bit key) header.d=isc.org header.b=V+97EwNE; dkim=pass (1024-bit key) header.d=isc.org header.b=cWu5gwLB
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 Tqq1G8FLQVJO; Thu, 8 Jul 2021 07:28:35 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 5DEA33A1F1B; Thu, 8 Jul 2021 07:28:35 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id D06683AB020; Thu, 8 Jul 2021 14:28:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1625754513; bh=VjNVx46q+rQnms30QCLYiocHJ9uwbuKaZYtXkoCiO3Q=; h=To:References:From:Subject:Date:In-Reply-To; b=V+97EwNEMqvQAZ56JY/Pappaw5GseT0VIXn3eF4nxXECoy2kIdyfyL0b/3CTLqRVi acx73Ou0jlxgpIXJ0HC29pSzIp5ot2CUFHaZDI2HVOy8gjAmLQH0jiWSTbL1oK7+Lv 0H+IZJ0EJ2KqHaN14Fut89/StWnm0s+wysSkXVtY=
Received: from zmx1.isc.org (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7E10016007E; Thu, 8 Jul 2021 14:28:33 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 15036160081; Thu, 8 Jul 2021 14:28:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 zmx1.isc.org 15036160081
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1625754513; bh=v85sKtg+TV1rsnXTHQ7zJGtkzzNBtzpVwANY0mFjS1c=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=cWu5gwLBtdyTedVA+AmwyXOLD4AV7TqKfRjFuX19xTpQ6CCjlABWDHysL+OZdKZ/X br4e5I87AMjnQ7BrnPWSrrdVGDCl1sG5rowkEsKql/akOt3HmkO8QO8alpIpeBTWHm tOAaNL+DJcfwRscfnZ7k1iUP6P2jpyQKBcbwqNPE=
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id el2sl8Wp4sKV; Thu, 8 Jul 2021 14:28:33 +0000 (UTC)
Received: from [192.168.0.116] (ip-86-49-248-1.net.upcbroadband.cz [86.49.248.1]) by zmx1.isc.org (Postfix) with ESMTPSA id 2C7CE16007E; Thu, 8 Jul 2021 14:28:32 +0000 (UTC)
To: Warren Kumari <warren@kumari.net>, dnsop <dnsop@ietf.org>, DNSOP-Chairs <dnsop-chairs@ietf.org>
References: <CAHw9_iKhvHwUfJMOp-YhJkimmnN0f3DLbh+JWYxhCiZ9CjEEQQ@mail.gmail.com>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <pspacek@isc.org>
Message-ID: <0ed6efa6-c981-fa64-472c-eef0c5453f4a@isc.org>
Date: Thu, 8 Jul 2021 16:28:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CAHw9_iKhvHwUfJMOp-YhJkimmnN0f3DLbh+JWYxhCiZ9CjEEQQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/25P168J_hv9UxhXPqdgYqoGcap4>
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 14:28:40 -0000

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. 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.