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
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
