On Thu, 6 Aug 2020, Ben Schwartz wrote:
I think opportunistic or unauthenticated encryption is worth pursuing.
In general, yes. but ...
On Thu, Aug 6, 2020 at 10:59 AM Paul Hoffman <[email protected]> wrote:
Use case: Opportunistic encryption for recursive to
authoritative
In this use case, a resolver operator says “I’m happy to use
encryption with the authoritative servers if it doesn’t slow
down getting answers by much”, and an authoritative server says
“I’m happy to use encryption with the recursive resolvers if it
doesn’t cost me much”.
Opportunistic encryption is defined in RFC 7535.
Poorly and confusingly and not as how people have used the term in the
past. So that document has just ruined the term. [I was asked to
co-author and refused]
The "opportunistic" part really means, "we will try encryption, but if
for whatever reason it does not work, we will fallback to
unauthenticated or even cleartext".
That is different from "Hmm, I'm busy, I'll just do cleartext for now".
Email is good example of where TLS is used alot with bogus certs, and
thus basically doing unauthenticated encryption. It's useful as it helps
against passive attacks.
In this case though, for auth servers, I see no reason to do
unauthenticated encryption. There are usually two reasons for
unauthenticated encryption. The first is that the party wants to
remain anonymous (eg most HTTPS clients). The second is that it is
too hard for entities to get a veriable ID in a trustworth PKI.
In the case of encrypted DNS to authoritative servers, those servers
obviously can have an cryptographic ID based on FQDN. And
"opportunistic" then really means "you should do it and hardfail if
there is an issue".
The assumptions behind the use case are:
• More encryption is good for the Internet
Sure.
• Resolver vendors are smart and motivated
Some are, and a lot are not.
• Most resolvers don’t validate with DNSSEC and may never want
to
This is not true anymore. And even if it were, we should encourage those
to upgrade. At the IETF, we have done a REALLY bad job at keeping secure
DNS as an optional feature. The more we treat it that way, the more
others will treat it that way. We should really do the opposite. DNS
without DNSSEC is legacy. It's irresponsible. It's vulnerable. It's
being actively abused. Upgrade your DNS.
Then, you automatically get to AUTH servers having a DNSSEC based PKI.
You can give them a public key record type like TLSA, and do encryption.
You allow plaintext, and in 10-20 years we turn off plaintext.
• Authoritative operators don’t care much about encryption
I don't think that is true either. If they could install an ACME like
client and get fully automated optional encryption, I bet most would
just turn it on.
• Other use cases for authentication stronger than opportunistic
may appear and would co-exist with this one
Opportunistic for _this case_ is just too weak. We have a PKI system
with DNSSEC that is core to these DNS servers already. We basically
get the PKI for free, so just do it authenticated.
Another item that keeps coming up is people fearing an extra RTT on a
DNS connection to an AUTH servers to pull the public key. DNS already
has caching and for DNS encryption to yield anonimity, it has to be done
with nameservers hosting thousands or millions of zones anyway. Or else
encryption doesn't buy you anything. You can take that 1 RTT for
ns0.dreamhost.com or ns1.godaddy.com to get encryption for a few
thousand domains. No need back DS hacking of public keys.
The other slides had thoughts about possible solutions that
implement this use case, but before we go there, I wanted to
find out if more than a handful of people here are interested in
this use case. If so, I could turn the above into a draft with
some possible solutions for us to bang on.
We should work on adding encryption and moving towards an encryption
only solution. Not wishy-washy opportunistic with fallbacks. Not for
DNS.
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
