Re: [dns-privacy] [Ext] Threat Model

On Mon, Nov 4, 2019 at 1:56 PM Paul Wouters <paul@nohats.ca> wrote:

> On Mon, 4 Nov 2019, Brian Dickson wrote:
>
> > The names of the servers (and certificate management) would be
> orthogonal to the signaling of DoT support. I would expect the TLSA records
> would
> > be per-server and orthogonal to the per-zone signaling of DoT support.
>
> Again, that would be russian roulette. If I get an NS RRset with 3
> nameservers, and only one of these has a TLSA record, what should I
> do ?
>
> 1) Pick the TLSA one
> 2) Pick a random one
>
> For 1) if this protocol is widely deployed, all clients will pick 1) so
> you just shot your redundancy in the foot.
>
> For 2) the clients get reduced privacy for no good reason, so why would a
> client do this?
>
> It is really a per-zone property, not a per-nameserver property.
>

This is a good point, and seems like an argument against all of the
opportunistic versions as well, even those with HSTS-style mechanisms.

Suppose I look up a.example.com and get ns1.nameservers.example and
ns2.nameservers.example, and I have talked to ns1 and know it does Dot but
I don't know about ns2. What then? Or say I can't connect to ns1....

-Ekr

Paul
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>