Re: [dns-privacy] how can we ADoT?

Peter van Dijk <> Wed, 18 November 2020 20:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E8DA3A0B56 for <>; Wed, 18 Nov 2020 12:04:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, 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 yKE0uiyL_S0p for <>; Wed, 18 Nov 2020 12:04:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0055E3A0858 for <>; Wed, 18 Nov 2020 12:04:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPS id AB87C6A256; Wed, 18 Nov 2020 21:04:38 +0100 (CET)
Received: from plato ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 8BEE63C002F; Wed, 18 Nov 2020 21:04:38 +0100 (CET)
Message-ID: <>
From: Peter van Dijk <>
Date: Wed, 18 Nov 2020 21:04:35 +0100
In-Reply-To: <>
References: <> <> <>
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: <>
Subject: Re: [dns-privacy] how can we ADoT?
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, 18 Nov 2020 20:04:44 -0000

On Tue, 2020-11-17 at 01:21 +0000, Tony Finch wrote:
> Thanks for reading and providing feedback!
> Peter van Dijk <> wrote:
> > On Wed, 2020-11-11 at 19:07 +0000, Tony Finch wrote:
> > >   * Encryption would apply to the server as a whole, whereas the
> > >     working group consensus is that it should be possible for
> > >     different zones on the same server to use encrypted and
> > >     unencrypted transports.
> > 
> > (plus, in another email, Tony wrote: "A nice thing about TLSA records
> > is they also tell the client what name to look for in the server's
> > cert.")
> > 
> > This looks like a mistake to me, or at least, a choice that would have
> > to be made very deliberately.
> My point above mostly relates to section 5.1 points 7 and 9 of

I strongly believe point 9 should be removed, for reasons articulated
in my previous email briefly quoted above :)

> It also seems that any 'split' between which zones on a certain IP
> > support encryption and which zones do not, would make any opportunistic
> > proposal obsolete immediately.
> I'm not sure what you mean here because "opportunistic" has multiple
> meanings, and they have different implications for how a client might
> authenticate a server.

Opportunistic is, perhaps deliberately, vaguely defined. What I think I
mean to say there is 'if an auth NS responds on port 853, it had better
offer me all the data it also has to offer on 53'.

> ... and now the text below ...
> ## TLS certificate authentication
>   * Authenticate the server by `subjectAltName` `iPAddress`. Unfortunately
>     IP address certificates are hard to obtain (though this is likely to
>     become easier after [RFC 8738] is deployed). This is only an advantage
>     when there is no signal associated with the nameserver's name (such as
>     TLSA records) indicating support for encrypted transports, because if
>     there is such a signal the client knows what name to expect in the
>     certificate.

For DOTPIN, Ralph Dolmans had the bright insight to suggest not sending
a server name at all (which matches what I said earlier - name servers
have IPs, not really names).

>   * Ignore certificate name mismatches, and authenticate just the public
>     key. This raises the question of how the client can find out the right
>     public key: if it can find out the right key why can't it also
>     find out the right name? It has the disadvantage that public key
>     pinning has a poor operational track record.

As above. (Not saying that it is the only way, but 'a name server has
no name' has a lot of convenient properties.)

>   * Use the presence of a DNS record associated with the nameserver name
>     to indicate that the server's certificate will match the name. For
>     example, TLSA records alongside the nameserver's address records;
>     other possible kinds of records for doing this job are discussed in
>     the following subsections.

First thought: yes. Second thought: what if the owner of the 'vanity
name' 'aliased' to the NS just copies the TLSAs? At sufficient
deployment, the failure mode is immediate and clear, of course.

>   * A nameserver's official name, which is used in the vast majority of NS
>     records pointing at this server. The presence or absence of a TLSA
>     record associated with this name controls whether transport encryption
>     is used for the owners of these NS records.

Makes sense, that's what puts the NS owner in control of transport,
instead of (or together with) the zone owner.

>   * Alternative names that advertise different encrypted transports than
>     the official name. A nameserver operator can use different names for
>     the same nameserver to support encryption for a subset of zones. This
>     might be useful for testing or phased rollout.

This is neat.

> A nameserver should
> serve the same zones over encrypted transports that it serves over the
> corresponding UDP and TCP transports.


> [This slightly weird phrasing is to avoid ruling out features like views
> or split horizons.]

Cleverly boxed.
Kind regards,
Peter van Dijk