Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
Peter Thomassen <peter@desec.io> Wed, 07 July 2021 18:46 UTC
Return-Path: <peter@desec.io>
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 C154B3A244A for <dnsop@ietfa.amsl.com>; Wed, 7 Jul 2021 11:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.236
X-Spam-Level:
X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=a4a.de
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 2LEt0h5aNAgY for <dnsop@ietfa.amsl.com>; Wed, 7 Jul 2021 11:46:20 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 B52003A2449 for <dnsop@ietf.org>; Wed, 7 Jul 2021 11:46:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=suz8qlAHyInlMr7nCVOlIgpe+sLew1qiHethSzt2bfA=; b=CHXH+X1yT309z6ZiYbkc4jj0iu lV8OruBo4wFCyyS6ZAJHkySdCm2PgxUwOSO9IacM1Rez4T2MBlqRJFTH9rGZeW4Xtb/HZVQcpUxWe S9t0EDB7O7af6XDMOCnNxnkmnd4fI4fL92gIix5sXzILF/fc7Dysmu10MXqRw1QCJYygJ4JibpucK h8kiW+WdzKvvxK1CV+PlhBtNkoNss5jkuxCQKyiu9sdMyy4R6TiIBuBjnuf37frhdSryBUIqvkd2l fP0YJHdbPTd2Ky6QBUSmNdROn2D904SZI67t1oUA67MHjnjMFgF6wa0xldP9lcvqb6c4F+/XjVT3o lLkh4Jgw==;
Received: from ip5f5aea57.dynamic.kabel-deutschland.de ([95.90.234.87] helo=[192.168.1.171]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <peter@desec.io>) id 1m1CYs-0006lO-9P for dnsop@ietf.org; Wed, 07 Jul 2021 20:46:18 +0200
To: dnsop@ietf.org
References: <CAHw9_iKhvHwUfJMOp-YhJkimmnN0f3DLbh+JWYxhCiZ9CjEEQQ@mail.gmail.com>
From: Peter Thomassen <peter@desec.io>
Message-ID: <4e0e68d4-1e1c-1769-66e7-3c52e00fb263@desec.io>
Date: Wed, 07 Jul 2021 20:46:17 +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: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="mX67vuH9Wcow4QwTn9j69P9xULGWtAY9o"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yWuL6siCStvvgmmkJPcxd1Utl48>
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:46:26 -0000
On 7/7/21 7:54 PM, Warren Kumari wrote: > 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. There are deployments with delegations at _openpgpkey, such as _openpgpkey.posteo.de. This is how I would do such a deployment myself. As there are only hashes exposed, I don't see a privacy issue if no QNAME Minimization is done. (The point is that I would argue that such a delegation points is not unlikely.) Another example is _acme-challenge. About 0.1% of zones hosted at desec.io have a delegation point there. (Ok, that's not very frequent.) The draft for authenticated bootstrapping of DNSSEC delegations (https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/) does suggest a zone cut at an underscore name. However, that's not to say it would be a privacy-relevant one, so it seems fine to me when QNAME Minimization is not done in this case. It is unclear whether the future will bring underscore labels under which privacy-sensitive owner names may reside. > Should the advice above be strengthened to SHOULD / RECOMMENDED? Especially because of the last reason above, I tend towards MAY. However, I would endorse SHOULD / RECOMMENDED if the wording is changed such that "skipping a split" is done "up to the lowest-level" underscore label. In other words, jumping from example.com to _25._tcp.example.com would be RECOMMENDED, but jumping from example.com to foobar._openpgpkey.example.com would not, because "foobar" is no an underscore label. Generally, if there are N consecutive underscore labels, minimization SHOULD be skipped for the N-1 of them which are closest to the root. Cheers, Peter -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525
- [DNSOP] Consensus check on underscore names and d… Warren Kumari
- Re: [DNSOP] Consensus check on underscore names a… Paul Vixie
- Re: [DNSOP] Consensus check on underscore names a… Viktor Dukhovni
- Re: [DNSOP] Consensus check on underscore names a… Brian Dickson
- Re: [DNSOP] Consensus check on underscore names a… Tim Wicinski
- Re: [DNSOP] Consensus check on underscore names a… Peter Thomassen
- Re: [DNSOP] Consensus check on underscore names a… Viktor Dukhovni
- Re: [DNSOP] Consensus check on underscore names a… Paul Wouters
- Re: [DNSOP] Consensus check on underscore names a… Tony Finch
- Re: [DNSOP] Consensus check on underscore names a… Petr Špaček
- Re: [DNSOP] Consensus check on underscore names a… Viktor Dukhovni
- Re: [DNSOP] Consensus check on underscore names a… Brian Dickson
- Re: [DNSOP] Consensus check on underscore names a… Wes Hardaker
- Re: [DNSOP] Consensus check on underscore names a… Peter van Dijk
- Re: [DNSOP] Consensus check on underscore names a… Petr Špaček
- Re: [DNSOP] Consensus check on underscore names a… Petr Špaček
- Re: [DNSOP] [Ext] Consensus check on underscore n… Paul Hoffman
- Re: [DNSOP] [Ext] Consensus check on underscore n… Petr Špaček
- Re: [DNSOP] [Ext] Consensus check on underscore n… Viktor Dukhovni
- Re: [DNSOP] Consensus check on underscore names a… Brian Dickson
- Re: [DNSOP] [Ext] Consensus check on underscore n… Viktor Dukhovni
- Re: [DNSOP] [Ext] Consensus check on underscore n… Warren Kumari
- Re: [DNSOP] [Ext] Consensus check on underscore n… Petr Špaček
- Re: [DNSOP] Consensus check on underscore names a… Petr Špaček
- Re: [DNSOP] Consensus check on underscore names a… Viktor Dukhovni
- Re: [DNSOP] Consensus check on underscore names a… Brian Dickson
- Re: [DNSOP] Consensus check on underscore names a… Viktor Dukhovni
- Re: [DNSOP] Consensus check on underscore names a… Petr Špaček
- Re: [DNSOP] Consensus check on underscore names a… Warren Kumari