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

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 <ekr@rtfm.com> wrote:

>
>
> On Mon, Feb 15, 2021 at 3:23 PM Paul Wouters <paul@nohats.ca> 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
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

-- 
Daniel Migault
Ericsson