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

On Mon, Nov 4, 2019 at 5:13 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> 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....

$ dig ns a.example.com
;; ANSWER SECTION:
a.example.com. 42923 IN NS ns1-dot.nameservers.example.
a.example.com. 42923 IN NS ns2.nameservers.example.

Now, if you cannot reach ns1-dot.nameservers.example, whether you fall
back to ns2.nameservers.example is a matter of client policy /
paranoia. As this is an *opportunistic* / better than nothing solution
I'd think that falling back makes sense. This really really isn't a
replacement for a more secure, downgrade resistant solution (like
Paul's), but it *is* an incrementally deployable, opportunistic
convention based solution. We could do it while figuring out a better,
more secure system...

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

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf