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).
- [dns-privacy] Possible use case: Opportunistic en… Paul Hoffman
- Re: [dns-privacy] Possible use case: Opportunisti… Ben Schwartz
- Re: [dns-privacy] [Ext] Possible use case: Opport… Paul Hoffman
- Re: [dns-privacy] Possible use case: Opportunisti… John R. Levine
- Re: [dns-privacy] Possible use case: Opportunisti… Tim Wicinski
- Re: [dns-privacy] Possible use case: Opportunisti… Puneet Sood
- Re: [dns-privacy] Possible use case: Opportunisti… Rob Sayre
- Re: [dns-privacy] Possible use case: Opportunisti… Puneet Sood
- Re: [dns-privacy] Possible use case: Opportunisti… Rob Sayre
- Re: [dns-privacy] Possible use case: Opportunisti… Manu Bretelle
- Re: [dns-privacy] Possible use case: Opportunisti… John Levine
- Re: [dns-privacy] Possible use case: Opportunisti… Rob Sayre
- Re: [dns-privacy] Possible use case: Opportunisti… Paul Wouters
- Re: [dns-privacy] Possible use case: Opportunisti… Brian Haberman
- Re: [dns-privacy] Possible use case: Opportunisti… Ask Bjørn Hansen
- Re: [dns-privacy] Possible use case: Opportunisti… Paul Ebersman
- Re: [dns-privacy] [Ext] Possible use case: Opport… Paul Hoffman
- Re: [dns-privacy] Possible use case: Opportunisti… Peter van Dijk
- Re: [dns-privacy] Possible use case: Opportunisti… Peter van Dijk
- Re: [dns-privacy] [Ext] Possible use case: Opport… Brian Haberman
- Re: [dns-privacy] Possible use case: Opportunisti… Tony Finch
- Re: [dns-privacy] Possible use case: Opportunisti… Paul Wouters
- [dns-privacy] TLSA for secure resolver-auth trans… Peter van Dijk
- Re: [dns-privacy] Possible use case: Opportunisti… Vladimír Čunát
- Re: [dns-privacy] [Ext] Possible use case: Opport… Paul Hoffman
- Re: [dns-privacy] TLSA for secure resolver-auth t… Ilari Liusvaara
- Re: [dns-privacy] TLSA for secure resolver-auth t… Paul Wouters
- Re: [dns-privacy] [Ext] TLSA for secure resolver-… Paul Hoffman
- Re: [dns-privacy] TLSA for secure resolver-auth t… Vladimír Čunát
- Re: [dns-privacy] TLSA for secure resolver-auth t… Paul Wouters
- Re: [dns-privacy] Possible use case: Opportunisti… Viktor Dukhovni
- Re: [dns-privacy] TLSA for secure resolver-auth t… Peter van Dijk