Re: [dns-privacy] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Wed, 26 May 2021 18:21 UTC

Return-Path: <vladimir.cunat+ietf@nic.cz>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D113A0CD5 for <dns-privacy@ietfa.amsl.com>; Wed, 26 May 2021 11:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 5vdlFps5KZ-8 for <dns-privacy@ietfa.amsl.com>; Wed, 26 May 2021 11:21:07 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 396923A0CCE for <dns-privacy@ietf.org>; Wed, 26 May 2021 11:21:06 -0700 (PDT)
Received: from [IPv6:2a02:768:2d1c:226::a2e] (unknown [IPv6:2a02:768:2d1c:226::a2e]) by mail.nic.cz (Postfix) with ESMTPSA id 9702F140963 for <dns-privacy@ietf.org>; Wed, 26 May 2021 20:21:01 +0200 (CEST)
To: dns-privacy@ietf.org
References: <B27C4F2E-D5AF-428B-BBD1-A57E7D676BD5@icann.org> <CADyWQ+E9jpV0BwMsaS8=vNbs7x87d4qqGbKQevj8MVGCLGyv5w@mail.gmail.com>
From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
Message-ID: <5714de37-baae-9f72-3f02-e2765a6d4e2c@nic.cz>
Date: Wed, 26 May 2021 20:21:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <CADyWQ+E9jpV0BwMsaS8=vNbs7x87d4qqGbKQevj8MVGCLGyv5w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------FEEDC4D9CC94E3FB08CF2746"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/S_XBmUPSj40bMs9z6pFiRkrZmDA>
Subject: Re: [dns-privacy] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2021 18:21:12 -0000

I like it in principle, so I say adopt.

I already see a significant problem, though I expect we can fix it 
somehow after adoption:

> After sending out all requests for SVCB records [...]

My understanding of section 3 implies that an implementing resolver MUST 
NOT ask any of the nameservers until *all* their SVCBs have been 
attempted, in the most common case where no encryption is supported by 
the nameserver-set.  That would *not* scale at all.  Even with 13 NSs 
it's a rather bad amplification factor, and it reminds me of the recent 
NXNS attack.

On the whole, if a NS set has (many?) names without encryption support, 
I'm afraid the corresponding zones may have to do without a guarantee of 
getting encryption, though glue might help.


On 26/05/2021 15.21, Stephen Farrell wrote:
> SVCB in the parent zone will take years to happen

The SVCB glue is just a slight optimization.  I don't think it can even 
save latency, just a packet per NS (and only in cases where the SVCB 
exists).


--Vladimir