Hi Francis, > >From discussions with Stephane Bortzmeyer and Mark Andrews... > > First I come back to the fact there are two different problems (aka divide and > conquer): > * stubs <-> resolver > * resolver <-> auth servers > > I consider the first one to be already solved, cf. the Microsoft deployed > solution which puts clients, local networks, the resolver (also the Microsoft > Domain Server :-), in the same area and uses IPsec to protect it. You can do > other ways but IMHO we can assume you don't need confidentiality with far > or untrusted resolvers. > Or with other words you don't need confidentiality with 8.8.8.8
Why don't we need confidentiality with open resolvers like google? One might not like that anybody on his/her network knows what he is browsing. This is a part of privacy. > So we have the second (and *hard*) problem to address. > A thing we can do now is to minimize qnames (Stephane should write a > dedicated draft about this): it doesn't change the protocol, and IMHO to > change referrals by direct queries about name servers should not be a bad > thing. > > The last step is to design an encryption solution. > My requirements are: > > 1- the solution SHOULD NOT add extra round trips > > 2- the solution MUST NOT add per client state on servers > > 3- the solution MUST work without prior arrangements Probably you need a miracle. Because with no arrangement, I do not think it is possible. I would change your sentence to with minimal arrangements. > In details: 1- is about extra delays but for higher level domains a validating > resolver will anyway make other related requests so the extra delays will be > diluted. > 2- is about scalability and anycast, e.g., we want the solution to work with a > common setup where requests are load-balanced between multiple server > instances. Note the keyword is "state", we can accept a state associated with a > TCP connection but a solution relying on even medium key TTL should be > rejected. > 3- is common sense, and includes circular dependencies if for instance the > server public key is itself delivered through the DNS. > > At the other hand we only need a weak (== not very strong) protection > against passive attacks, so it doesn't matter that the standard mutually > authenticated Diffie-Hellman + symmetical A+E cipher doesn't fit. If you use a weak approach, IMHO, it is better to forget encryption since you do not know how powerful an attacker can be and you only bother your computer. Best, Hosnieh _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
