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

[Warren Kumari <[e-mail]>]

On Tue, Nov 5, 2019 at 2:40 PM Paul Wouters <[e-mail]> wrote:
>
> On Tue, 5 Nov 2019, Warren Kumari wrote:
>
> > Because then I need to probe them on 853 and wait N before trying on port 53, or I will
> > only get any sort of protection for name-servers which I’ve spoken to recently enough that
> > I have them in cache — that works for e.g: ns1.google.com, but not ns0.nohats.ca
>
> Well, that's how we do things when remembering per-server
> characteristics, which we need to do anyway in case of outages.
>
> Like EDNS0 support and DNS COOKIES support is remembered and cached,
> why wouldn't resolvers do the same for this property. We didn't put
> "ns-edns" out there in name hacks either. Why start now?

For things like COOKIES I don't need knowledge of the server *before*
I contact it -- when I want to lookup www.nothat.ca, and get back a
cookie, I've learnt something useful for future connections.

For privacy, I really don't want to have to leak the fact that I'm
looking up secret.nohats.ca because I happen to be the first user who
is (recently) asking for a name on ns0.nohats.ca.
a.ns.facebook.com is popular and so in basically all caches, all the
time - and so users looking that up would get privacy most of the
time.
ns01.kumari.net is (obviously) less popular, and so basically never in
caches -- and so anyone looking up kink.kumari.net will be exposed.

Now, I really don't think it is fair and right that people looking up
Facebook (or Google) get privacy simply because those sites are
popular, and people reaching my personal site don't.
I could get privacy back by moving my DNS to a large commercial DNS
hoster (ns59.domaincontrol.com is in many caches, much of the time),
but this seems like an even worse push.

I'd like some system where I can signal that I support DoT:
1: without my parent having to do anything (like be upgraded to support DoT)

2:  without having people to probe and wait for a timeout

3: with my users first connection protected, so they don't have to
lookup safe.kumari.net (to make sure that the resolver knows that
ns01.kumari.net supports DoT), or something like _dot.kumari.net
before looking up secret.kumari.net.

4: without expecting everyone to support DNSSEC.

I'd like to see something less stupid than ns01-dot.kumari.net, but I
don't really see what else the child controls at the parent (without
having a separate set of info / RR type / encoding stuff in DS, etc)

W



>
> Paul



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