Re: [dns-privacy] TLSA for secure resolver-auth transport

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Wed, 12 August 2020 23:50 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 22B8E3A0D65 for <dns-privacy@ietfa.amsl.com>; Wed, 12 Aug 2020 16:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.844
X-Spam-Level:
X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 GY_GTtQtdkNP for <dns-privacy@ietfa.amsl.com>; Wed, 12 Aug 2020 16:50:14 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 284713A07F0 for <dprive@ietf.org>; Wed, 12 Aug 2020 16:50:11 -0700 (PDT)
Received: from [192.168.6.18] (nat-45.starnet.cz [178.255.168.45]) by mail.nic.cz (Postfix) with ESMTPSA id 2EE5B140A5C; Thu, 13 Aug 2020 01:50:08 +0200 (CEST)
To: Paul Wouters <paul@nohats.ca>
Cc: dprive@ietf.org
References: <3BA75997-3DE4-4DF5-B1F5-C57DBC423288@icann.org> <CAHbrMsAEUFT7GOTm5Dbq9PCMEA+4maJQ32t_R-SbYVyztqVBDA@mail.gmail.com> <alpine.LRH.2.23.451.2008062244030.618007@bofh.nohats.ca> <94c6f6d2bcd2c4c2bd2d08ed6cf9cd271059ec1b.camel@powerdns.com> <alpine.LRH.2.23.451.2008112144100.99493@bofh.nohats.ca> <421070a4cea9c0f8d20d06921dae202fc4ebc273.camel@powerdns.com> <alpine.LRH.2.23.451.2008121149370.115623@bofh.nohats.ca>
From: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
Message-ID: <f36e5a4d-ba6a-39cb-a12f-e3c7713505a0@nic.cz>
Date: Thu, 13 Aug 2020 01:50:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.1.1
MIME-Version: 1.0
In-Reply-To: <alpine.LRH.2.23.451.2008121149370.115623@bofh.nohats.ca>
Content-Type: multipart/alternative; boundary="------------80C9404E01926728CA0C88B2"
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/tP86bMyEpkD0djRj0_JUnBvBI4E>
Subject: Re: [dns-privacy] TLSA for secure resolver-auth transport
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, 12 Aug 2020 23:50:16 -0000

On 8/12/20 9:50 PM, Paul Wouters wrote:
>> Delegation NS records are not signed, so do we stick -those- (or a hash
>> of the NSset perhaps?) into DS?
>
> I don't think so. The DS is signed, and following that path, it hardly
> matters where the NS records point to. Do you fear that you will receive
> bad NS records from the parent, who will than MITM you by relaying
> DNSSEC payloads from the real authoritative server, and thus losing
> privacy
> that way?  [...]

That parent may not be using a secure transport (e.g. root isn't
expected to), in which case anyone on path may be a MITM.  I suppose in
that case we could use the NS to obtain DNSSEC proof for itself, but
adding this half-secure phase would seem to complicate stuff, and you
probably don't want to ask deeper than the apex until MITM is disproven
(leaking additional labels and allowing the MITM to deepen the attack).