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

Paul Wouters <paul@nohats.ca> Wed, 07 July 2021 20:54 UTC

Return-Path: <paul@nohats.ca>
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 EB2A03A27CB; Wed, 7 Jul 2021 13:54:31 -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, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca
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 Jw9SKzzRO4TV; Wed, 7 Jul 2021 13:54:26 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 219123A27C4; Wed, 7 Jul 2021 13:54:26 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GKs9V3QQdz5C2; Wed, 7 Jul 2021 22:54:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1625691262; bh=w//vGsTuBb+qZRU88HaGkf99yVr941pjmlRQEJDt+kk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=chDwQ/EiKttD4xW3NM20XjdgR7o253YXiDJ6FSPVjSbc07OE6+8JKIjkcHi+JnR2o /S6qxWJEJOkNNvVDPtmCrPjaXyuYe/nPTDh2zoWPdDW5f8HLMeyfweyL7/cex3tvYC P9kiK2Re72ve9G7QVSbnsJjWs43FJ+3KL+F8xkrM=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BSuWWx69dPYl; Wed, 7 Jul 2021 22:54:21 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 7 Jul 2021 22:54:21 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 56789C4510; Wed, 7 Jul 2021 16:54:19 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 53724C450F; Wed, 7 Jul 2021 16:54:19 -0400 (EDT)
Date: Wed, 7 Jul 2021 16:54:19 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Warren Kumari <warren@kumari.net>
cc: dnsop <dnsop@ietf.org>, DNSOP-Chairs <dnsop-chairs@ietf.org>
In-Reply-To: <CAHw9_iKhvHwUfJMOp-YhJkimmnN0f3DLbh+JWYxhCiZ9CjEEQQ@mail.gmail.com>
Message-ID: <8263fbf5-aa2a-1b91-bf17-9c53e0994afa@nohats.ca>
References: <CAHw9_iKhvHwUfJMOp-YhJkimmnN0f3DLbh+JWYxhCiZ9CjEEQQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/M-4o6Dwhk7oRnQf8GxFbw9uAh0s>
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 20:54:32 -0000

On Wed, 7 Jul 2021, Warren Kumari wrote:

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

The description is correct....

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

I agree. The _underscore directly conveys information about the qname
parts up to that label. There is no distinct privacy realm here, and
query minimalization SHOULD stop, and the entire QNAME should be
requested.

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

It is possible there is a delegation. For example, at Fedora we ran
into an issue that _openpgp reocrds got quite big, and a delegation
to a separate name server would have been nice. And while this may
be under a different IT branch, from a privacy point of view, it is
still within the same privacy realm.

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

I doubt that, but sure. auth servers could stuff it in the Additional
section too :)

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

I don't think there realistically is a "potential small leak".

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

Yes.

Paul