Re: [dns-privacy] Authentication in draft-ietf-dprive-opportunistic-adotq

[Paul Wouters <[e-mail]>]

On Mon, 15 Feb 2021, Stephen Farrell wrote:

>>  - We invent some mechanism that allows you to specify in an NS record that
>>  the server takes TLS (as a hacky example, "servers have to be named
>>  <some-sentinel>.example.com").
>
> Wasn't exactly that proposed but shot down already (for
> DNS, not crypto, reasons)? Maybe I'm recalling wrong. I did
> kinda like it mind - the hackiness appeals a bit to me:-)

I think it was shot for many reasons. One of them being that a signal
for encrypted transport is not a per-domain property but a per-ns
property.

Here is a different sentinel:

_53._dns.ns0.example.com. IN TLSA x y z <base64ofCert>

Then do (D)TLS

Now you can choose:

1) Use DNS(SEC) for validation
2) Use WebPKI[*] for validation
3) TOFU
4) Take at face value

Of course, this runs into issues we talked about before. Revealing a
query for ns0.nohats.ca already loses privacy unless you are centralized
at godaddy. But even if you didn't leak anything, doing encrypted "stuff"
to the IP of ns0.nohats.ca itself already gives all of that away too.

Then we also talked about untrustworthy parents, which are an even bigger
concern for unauthenticated connections.

Then we also talked about TTLs needed for verification of parental glue
at the child and facilitating dnssec transparency on the DS record.

The key point I want to make here is that you need to faciliate
authenticated encryption even if you want to say "but since that is
too difficult/hard/slow for now, you could skip the authentication".

This means you _first_ need to specify how to do the authenticated
version before you start specifying the un-authenticated version. If you
don't do this, what you end up with is a resolver with two independent
mechanisms. It is then forced to first initiate the authenticated attempt,
upon some kind of failure, tries to do the unauthenticated (but completely
different) approach. And it cannot even do this in parallel because then
the authenticated method is downgraded from a privacy loss point of view
to the unauthenticated method - since once you send the DNS query
through the channel, you have given away all the information you were
protecting to begin with.

Paul W
[*] well, it's really trusting only LetsEncrypt CA[**]
[**] Which depends on insecure DNS records for authentication, so
      in reality you need DNSSEC or WebPKI is just reduced to TOFU