Re: [dns-privacy] Opportunistic encryption between recursive and authoritative servers

[Paul Wouters <[e-mail]>]

On Fri, 11 Sep 2020, Paul Hoffman wrote:

> Greetings. The discussion of encrypting the recursive to authoritative traffic keeps getting bogged down due to lack of use cases. Puneet and I would like to propose a specific use case (the desire to encrypt much more traffic, even if there could be an active attacker in the middle). With that in mind, we wrote up <https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic>. The abstract says:
>  This document describes a method for a DNS recursive resolver to use
>  opportunistic encryption when communicating with authoritative
>  servers.  The method here is optional for both the recursive resolver
>  and the authoritative server.  A motivating use case for this method
>  is that more encryption on the Internet is better, and opportunistic
>  encryption is better than no encryption at all.  Nothing in this
>  method prevents use cases that require better encryption.
>
> We would like DPRIVE to adopt this, and we are open to suggestions on how to improve the protocol.

And as I've told you before, your use case of "opportunistic encryption"
makes no sense here. The DNS allows for publication of public keys without
any further infrastructure. You need your TLS certificate for encryption
anyway. Why not just stuff that public key into DNS via a TLSA record?

This is not rocket science. We already do TLSA for email at large scale
now. To do it for DNS is the same except it's even simpler because the
protocol we are protecting is the protocol used for authentication of
the encryption.

As the document already indicates, there is NO difference in setup for
the authoritative server. It needs a TLS certificate. It can use humans
of shell scripts to set this up once using self-signed certificates,
or it can just run an ACME client to automate this.  That is, it is
easier to get a public valid TLS certificate for your DNS server, than
it is to install a self-signed one.

On the client, it is doing TLS authentication as part of the protocol
anyway, and just "throwing away the results". So nothing is saved there
from code complexity other than not looking if the CA cert used is in
its local (system) store of trusted certificates.

Opportunistic encryption to authoritative servers is just too silly.

I am strongly opposed to doing this work.

Paul