[dns-privacy] TLSA for secure resolver-auth transport (was: Possible use case: Opportunistic encryption for recursive to authoritative)

Peter van Dijk <peter.van.dijk@powerdns.com> Wed, 12 August 2020 10:51 UTC

Return-Path: <peter.van.dijk@powerdns.com>
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 7A2A63A1214 for <dns-privacy@ietfa.amsl.com>; Wed, 12 Aug 2020 03:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.685
X-Spam-Level:
X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.212, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 RL-0U-QzqdDO for <dns-privacy@ietfa.amsl.com>; Wed, 12 Aug 2020 03:51:38 -0700 (PDT)
Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 B6A9E3A1213 for <dprive@ietf.org>; Wed, 12 Aug 2020 03:51:38 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 9BC776A30D; Wed, 12 Aug 2020 12:51:35 +0200 (CEST)
Received: from plato (e82143.upc-e.chello.nl [213.93.82.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 789043C0385; Wed, 12 Aug 2020 12:51:35 +0200 (CEST)
Message-ID: <421070a4cea9c0f8d20d06921dae202fc4ebc273.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dprive@ietf.org
Date: Wed, 12 Aug 2020 12:51:34 +0200
In-Reply-To: <alpine.LRH.2.23.451.2008112144100.99493@bofh.nohats.ca>
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>
Organization: PowerDNS.COM B.V.
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/OSlRxGZ7wdGap6KcK0zXc-P9CAA>
Subject: [dns-privacy] TLSA for secure resolver-auth transport (was: Possible use case: Opportunistic encryption for recursive to authoritative)
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 10:51:41 -0000

(I changed the subject because this has turned into a solution
conversation, instead of a use case conversation)

On Tue, 2020-08-11 at 21:49 -0400, Paul Wouters wrote:
> On Mon, 10 Aug 2020, Peter van Dijk wrote:
> 
> > On Thu, 2020-08-06 at 23:04 -0400, Paul Wouters wrote:
> > > In the case of encrypted DNS to authoritative servers, those servers
> > > obviously can have an cryptographic ID based on FQDN.
> > 
> > This is not obvious. It would be great if it was; but it isn't.
> 
> Sorry, I did not realise it was not obvious to everyone, so let me
> clarify:
> 
> _853._dot.ns0.nohats.ca. IN TLSA <blob>
> _443._doh.ns0.nohats.ca. IN TLSA <blob>

Yes, that part seems obvious (if we assume the records live with the
child, which I guess is obvious from your 'national MITM' argument in
other threads). Many other aspects are not obvious. Some examples
follow.

Delegation NS records are not signed, so do we stick -those- (or a hash
of the NSset perhaps?) into DS?

Can we find those TLSA records without leaking the names of the name
servers we are looking for, or do we decide that name server names are
not a privacy leak?

Do we move delegation-revalidation from 'possibly later' to 'always do
that first', so that we get signed NS records before we look for TLSA?

Do we expect resolvers to issue a couple of TLSA queries per NS before
getting to the actual end user's question?

'Put TLSA records in your zone' is not a protocol. I'm sure we can
define a protocol that revolves around TLSA, but your description is
not yet it. That is what I mean by 'this is not obvious'.

> This uses the unique FQDN of each nameserver's name. You can have
> multiple TLSA records if you use different keys on some of your
> nameservers (eg some outsourced to an ANYcloud provider)

Assuming you use vanity names in the outsourcing (i.e. ns5.nohats.ca is
actually a CloudFlare name server). If you don't use vanity names, the
scaling mentioned just below comes for free because the outsourced
operator would own the TLSA records (i.e. nohats.ca IN NS
paul.cloudflare.com).

> Note that this scales with the nameserver. For example by publishing the
> above, the libreswan.org domain would also have dot/doh published as it
> is using the same nameservers.

This, to me, is the main selling point of tying key publication to NS
names instead of zone names.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/