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

Paul Wouters <paul@nohats.ca> Thu, 13 August 2020 01:58 UTC

Return-Path: <paul@nohats.ca>
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 932A53A157D for <dns-privacy@ietfa.amsl.com>; Wed, 12 Aug 2020 18:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 b8IxjLAeKnye for <dns-privacy@ietfa.amsl.com>; Wed, 12 Aug 2020 18:58:24 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 E4D7E3A1578 for <dprive@ietf.org>; Wed, 12 Aug 2020 18:58:23 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BRqV55k6dz31C; Thu, 13 Aug 2020 03:58:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1597283901; bh=Eta+jYjHNaanNveK92zGyHWSUEyLi0aK1sxbDaRPKZw=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=gwiOX/m5/oG1FOAVUKDfVecXCo6G6xXtpNFckdE04MThyRG2YXVDNcw3nQzziFgiI d+GCD8g/2DbCeks1rH+WCZCcrsZZ0crFUXcGR5BIbiwuswKXazHwsBv6lCCX/cL9DL o1ZnsZqPOhvVdBE57NCpda5CDB6u9yJE2LOSPqj0=
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 Y4MUw8pGHZjq; Thu, 13 Aug 2020 03:58:20 +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; Thu, 13 Aug 2020 03:58:19 +0200 (CEST)
Received: from [193.110.157.209] (unknown [193.110.157.209]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 71FB76029BA4; Wed, 12 Aug 2020 21:58:18 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-DAB73512-42FE-4299-9AD8-F3FFDF72D6B9"
Content-Transfer-Encoding: 7bit
From: Paul Wouters <paul@nohats.ca>
Mime-Version: 1.0 (1.0)
Date: Wed, 12 Aug 2020 21:58:15 -0400
Message-Id: <C24BCF26-6D28-4B12-816E-D6B4AB092FDB@nohats.ca>
References: <f36e5a4d-ba6a-39cb-a12f-e3c7713505a0@nic.cz>
Cc: dprive@ietf.org
In-Reply-To: <f36e5a4d-ba6a-39cb-a12f-e3c7713505a0@nic.cz>
To: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
X-Mailer: iPhone Mail (17G68)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/bFwXhG-4OHMQTJ-WJQTZe8leXbs>
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: Thu, 13 Aug 2020 01:58:26 -0000

On Aug 12, 2020, at 19:50, Vladimír Čunát <vladimir.cunat+ietf@nic.cz> wrote:
> 
> 
>> 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)
> 

Query minimalisation and unbound’s hardening options for infrastructure records would do this already with today’s software configuration.

Paul