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

[Peter van Dijk <[e-mail]>]

On Tue, 2020-11-17 at 01:21 +0000, Tony Finch wrote:
> Thanks for reading and providing feedback!
> 
> Peter van Dijk <[e-mail]> 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
> https://tools.ietf.org/html/draft-ietf-dprive-phase2-requirements-02

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.

Yes!

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

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