I do agree that given the structure of the DNS and the existing mechanisms in place - Paul W mentioned the DNS is a PKI - the WG should authenticate the DNS server.
It is unclear to me what advantages opportunistic security provides as well as how it presents a starting point to a fully secured solution. Resolvers are already providing part of the privacy and the remaining privacy is not provided - as mentioned by Eric. The level of confidence provided by opportunistic security seems even lower given that the DNS server is point of convergence as opposed to a random node for example. It seems to me, that more thoughts are need to evaluate how a more robust solution could leverage from an opportunistic solution. I would propose the other way around: the WG first focuses on a full solution, and then see if any intermediary steps may be helpful to reach its deployment. Something - as suggested by Paul W - based on the DNS service "_dns" seems a good starting point. Yours, Daniel On Mon, Feb 15, 2021 at 6:40 PM Eric Rescorla <[email protected]> wrote: > > > On Mon, Feb 15, 2021 at 3:23 PM Paul Wouters <[email protected]> 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 > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy > -- Daniel Migault Ericsson
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
