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

Ilari Liusvaara <> Wed, 12 August 2020 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2452A3A113E for <>; Wed, 12 Aug 2020 10:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.685
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QGRjykkndQHT for <>; Wed, 12 Aug 2020 10:11:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 348B53A116B for <>; Wed, 12 Aug 2020 10:11:17 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82551D00EF; Wed, 12 Aug 2020 20:11:15 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id JQtK-hc86E_n; Wed, 12 Aug 2020 20:11:15 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 27E632316; Wed, 12 Aug 2020 20:11:13 +0300 (EEST)
Date: Wed, 12 Aug 2020 20:11:12 +0300
From: Ilari Liusvaara <>
To: Peter van Dijk <>
Message-ID: <20200812171112.GA915533@LK-Perkele-VII>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [dns-privacy] TLSA for secure resolver-auth transport (was: Possible use case: Opportunistic encryption for recursive to authoritative)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Aug 2020 17:11:20 -0000

On Wed, Aug 12, 2020 at 12:51:34PM +0200, Peter van Dijk wrote:
> (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:
> > 
> > IN TLSA <blob>
> > 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?

Note that DNS does not guarantee coherence between record types, so
that would presumably need to be individual NSnames.

> 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?

I think that the destination IP mostly gives away the name server name.

It is zone name that should be treated as sensitive if at all possible,
and should not be disclosed to unauthenticated servers.

> 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?

I don't see obvious connection between this and delegation-revalidation.
> Do we expect resolvers to issue a couple of TLSA queries per NS before
> getting to the actual end user's question?

Issuing the TLSA queries can be problematic if the nameserver is
in-zone. Things get even worse if nameserver is located in child zone
of zone it serves (thankfully, I do not think the latter happens much).

And thinking about it, one would also need to use dedicated connection
(or unencrypted UDP) for the queries, because otherwise leaks information
about the zone if the nsname is inside one of the zones it is serving.
Reusing the connection would also need post-hoc authentication, which is
nontrivial to implement correctly.

Getting around these would need stapling.

Also, if nameserver already has authenticated connection to the same
nameserver, there is no need to open another one to issue queries for
different zone.

> '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'.

And presumably the records would have to have usage 2 or 3, as there
are no built-in trust anchors (or at least I hope so!).

> > 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. 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. IN NS
> > Note that this scales with the nameserver. For example by publishing the
> > above, the 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.

In general it is useful to consider who should control a piece of data
and how to give that party actual control of it.

In this case, nameserver operators should control their authentication