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

[Brian Dickson <[e-mail]>]

On Tue, Nov 5, 2019 at 3:14 PM Warren Kumari <[e-mail]> wrote:

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

So, I'm going to rephrase some stuff, in an attempt to capture what I
believe are either (a) requirements, or (b) changes to DNS, in what you
describe.

Then, I'll ask some leading questions, and make some assertions, and see
where that goes. :-)

So, currently, there is no recursive-to-authoritative privacy standardized,
per se, even if there might be some early implementations (DoT in OTE at
godaddy for example).

The first question is, since no standard yet exists, why NOT include a
requirement for DNSSEC in order to do privacy to the authoritative, even if
only in the secure bootstrap process?
It's all green-field, right? I.e. excluding DNSSEC a priori seems overly
restrictive. (But let's leave that for now. But please answer this
question, it's something I'm interested in.)

Second, there seems to be an inherent leakage of information caused by an
association between the NS name of your domain and the domain and its
children.

Suppose the name server name, was decoupled from the domain you care about,
and all the information about that name server were in a different domain,
where the name of the name server was served from another name server whose
name was an in-bailiwick name for that other domain, and the query for the
name server for the domain you care about was only ever done over an
encrypted connection. (Whew.)

E.g.
kumari.net NS ns-ku.secret-nameserver-12345.net
secret-nameserver-12345.net NS ns1.secret-nameserver-12345.net
ns1.secret-nameserver-12345.net A <ipv4>
ns1.secret-nameserver-12345.net AAAA <ipv6>

Then have records for the DOT bits for both ns-ku and ns1 inside the
secret-nameserver-12345.net zone.
(Pick your poison on what those records would look like, anything from TLSA
records to A/AAAA records to some new RR type, or even SRV records.)

The privacy stuff would be a two-phase privacy bootstrap.
First, do the query to get the needed privacy stuff for
ns1.secret-nameserver-12345.net over a non-private connection.
Then, do the query to get the needed privacy stuff for
ns-ku.secret-nameserver-12345.net over a newly-established DoT connection
based on the previous step.
Third, do the query toward ns-ku.secret-nameserver-12345.net over another
DoT connection based on the previous step, to obtain any records within
kumari.net in a private fashion.

To know that any given query towards secret-nameserver-12345.net was
intended to get the stuff for kumari.net, would require more deductive
reasoning than in your original examples.

Also important is that the only information that would need to be stored on
secret-nameserver-12345.net would be an (arbitrary) nameserver name, plus
A/AAAA glue data, plus whatever other parameters are needed for DoT
signaling.

Thus, it would be very feasible for someone to offer a privacy-enabling
service like secret-nameserver-12345.net, that would provide a
stegonographic cover for all its clients, and those clients would not need
to identify their domains per se, and would eliminate the information
leakage of using a single domain with in-bailiwick name for the name server.

I.e. you would not need to operate secret-nameserver-12345 yourself (but
you could), and if you didn't, you would get a lot more privacy than is
otherwise possible (I think).

Additionally, the bigger and more popular secret-nameserver-12345 is, the
more likely it is in cache, allowing very private bootstrapping of the
privacy-protected DNS for kink.kumari.net.

I think this does #1 and #2, probably does #3, and #4 is open for
discussion.

Thoughts?
Answers?

Brian