On Tue, Nov 5, 2019 at 3:14 PM Warren Kumari <[email protected]> wrote:
> On Tue, Nov 5, 2019 at 2:40 PM Paul Wouters <[email protected]> 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
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
