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

[Eric Rescorla <[e-mail]>]

On Mon, Feb 15, 2021 at 3:23 PM Paul Wouters <[e-mail]> wrote:

> 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.
>

I agree that in principle this is true, but ISTM that one could make the
same argument about Web servers, but as a practical matter we've
gotten pretty far with the reference containing the security indicator.
In any case, one could imagine using some HSTS-like mechanism
once you have connected, right?




> 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.
>

Right. This seems like an inherent property, no? I.e., if an authoritative
only serves example.com, then encryption doesn't help much here.
The thing to avoid seems to be where ns.atlanta.example,
ns.biloxi.example, and ns.charlottesville.example all point to the same
server.

-Ekr