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

Petr Špaček <pspacek@isc.org> Tue, 13 July 2021 10:15 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 11B083A11B9 for <dnsop@ietfa.amsl.com>; Tue, 13 Jul 2021 03:15:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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.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=qAEeHcgj; dkim=pass (1024-bit key) header.d=isc.org header.b=Vxkg6ePh
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 JyRrRnBZGJwv for <dnsop@ietfa.amsl.com>; Tue, 13 Jul 2021 03:15:53 -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 D92AE3A11C2 for <dnsop@ietf.org>; Tue, 13 Jul 2021 03:15:53 -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 7F8153AB023 for <dnsop@ietf.org>; Tue, 13 Jul 2021 10:15:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1626171351; bh=IevhixTIjBr5g15EDM5Q+2P0RUaHLViZOVlj3IfjPYs=; h=To:References:From:Subject:Date:In-Reply-To; b=qAEeHcgj/Eio58RECHj+NC05160M8AeCm+BQ4AyhJ9Cbafjc/kxC3+Titq+YmZNv8 5jcRbnatBIUWD0MxQffy/g1c7TXrZtTCRwXq50WlMmsnTPe/h5JMigpvBTmGKdkYHv LE69f/VaApLotaSnntkBkp3BDGH4WETC5Z2eWgkg=
Received: from zmx1.isc.org (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6FAE1160075 for <dnsop@ietf.org>; Tue, 13 Jul 2021 10:15:51 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2AB1D16006D for <dnsop@ietf.org>; Tue, 13 Jul 2021 10:15:51 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 zmx1.isc.org 2AB1D16006D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1626171351; bh=dZj0PJ41f0DQzzOSJMUAk6xtF9x0FDiS7IwaM4Yx5QU=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Vxkg6ePh875EX526f08qqIS340y6P8DLPa49v91N9Lixg6aUolHBRaToxneY40649 Es4ojJcK07Ea9nXLo/3mnsbvymLXmQn6rB52IAcUlNfTmZPiq/ocY4AHr67XUZAk4A leaP4M4zVFkmvYbOs/5EbK0n4Lp9k7Mr6st0uF7w=
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 bWhKyqVDoeSY for <dnsop@ietf.org>; Tue, 13 Jul 2021 10:15:51 +0000 (UTC)
Received: from [192.168.1.86] (ip-94-113-163-223.net.upcbroadband.cz [94.113.163.223]) by zmx1.isc.org (Postfix) with ESMTPSA id 6B5E0160046 for <dnsop@ietf.org>; Tue, 13 Jul 2021 10:15:50 +0000 (UTC)
To: dnsop@ietf.org
References: <CAHw9_iKhvHwUfJMOp-YhJkimmnN0f3DLbh+JWYxhCiZ9CjEEQQ@mail.gmail.com> <B32C60D6-B4C7-4419-A3D7-57DBB9BBEFBA@icann.org> <CA25A87C-9DB7-49FE-A249-04AF801A82B4@dukhovni.org> <CAHw9_iJ2_NgWrPnciZVLkRfxZWfmkQ92hoAm-bwP63osd1vP=g@mail.gmail.com>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <pspacek@isc.org>
Message-ID: <0a09e94c-a764-3dd5-2c79-69b31573e5c1@isc.org>
Date: Tue, 13 Jul 2021 12:15:46 +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_iJ2_NgWrPnciZVLkRfxZWfmkQ92hoAm-bwP63osd1vP=g@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/h9BlBI0hQ0MtDAQAK_s8Tmj2bUc>
Subject: Re: [DNSOP] [Ext] 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: Tue, 13 Jul 2021 10:15:59 -0000

On 13. 07. 21 0:28, Warren Kumari wrote:
> On Mon, Jul 12, 2021 at 6:18 PM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>>
>> [ Resending complete message, previous draft was incomplete... ]
>>
>>> On 12 Jul 2021, at 11:18 am, Paul Hoffman <paul.hoffman@icann.org> wrote:
>>>
>>> The current text is sufficient to tell resolver developers, and resolver operators, why they should even think about underscore labels when they create a QNAME minimisation strategy. Elevating such a strategy to a SHOULD as a work-around for broken middleboxes that might (hopefully!) be fixed in the future seems like a very wrong direction for the WG.
>>
>> If this were just a work-around for breakage, I'd be more inclined
>> to agree, but it is also a solid opportunity to improve performance,
>> because privacy-relevant changes of administrative control across
>> special-use labels should be very rare to non-existent.

I hear you Viktor, but I fail to see why performance optimization cannot 
be optional. Why this specific optimization is so important that it 
cannot be left to vendors to decide?

>>
>> So short-circuiting qname minimisation when a special-use label is
>> encountered seems like a win-win.
>>
>> Measuring qname minimisation for TLSA RRs I see that today breakage
>> of qname minimisation is rare.  An example is:
>>
>>          https://dnsviz.net/d/_tcp.u24.altospam.com/YOx4nQ/dnssec/
>>          https://dnsviz.net/d/_25._tcp.u24.altospam.com/YOx4IA/dnssec/
>>
>> In which many (but not all) of the nameservers return NXDOMAIN for the
>> ENT.  Out of 150k RRsets, O(10) have ENT-related issues.
>>
>> So one might reasonably neglect the breakage, but it is not clear that
>> we need to go looking for it, just to "punish" the operators in question.
>> There's an opportunity here to make qname minimisation more performant for
>> SRV, TLSA, ... lookups, speeding up Domain Control and LDAP server lookups,
>> email delivery, ...

Please note I do not object to the method by itself - I agree it might 
be useful. My disagreement is limited to using stronger requirement than 
MAY. Let vendors have some leeway, please.

Petr Špaček


>>
>> Of course if the WG cannot come to consensus on "SHOULD"/"RECOMMENDED", I'll
>> gratefully settle for the current "MAY" (thanks for the document update)...
> 
> Another option would be to keep the current text, and simply add
> another sentence describing why implementations may want to do this;
> the current paragraph starts off with:
> " 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." - the context around this is mainly around limiting the
> many labels attack, but it could also mention the ENT / other
> performance gain.
> 
> Whatever the case, this conversation is still ongoing, so I'd like to
> keep it open for a few more days...
> 
> W