On Tue, May 20, 2014 at 12:06 AM, joel jaeggli <joe...@bogus.com> wrote: > On 5/19/14, 1:09 PM, John Heidemann wrote: >> >> Folks, >> >> I believe consensus was that dnsop needs a problem statement about DNS >> privacy before we explore possible solutions. > > If I were to speculate on the basis of the dicussion here and in the > DNSE bof the solution space involves signficant if maybe not dramatic > architecture changes.
Absolutely not. I can't see any possibility of a change to the communicating parties or the DNS record formats. My proposal is 17 pages and that is with some pretty extensive examples from the code: http://tools.ietf.org/html/draft-hallambaker-privatedns-00 > I would be happy to support exploration of the problem here and > documents of an according nature, but I imagine us chartering it as a > standalone activity. It is definitely not operations so it has to be a separate activity. Looking at the alternatives on offer I see three approaches: 1) Build on an existing framework e.g. DTLS. 2) Build on a new framework, e.g. SXS-Connect +UYFM that is very similar to DTLS 3) Design a new crypto protocol, e.g. DNS Curve. Now I did start on this three years ago so I have gone through the search space. The reason I chose option 2 is that I didn't find working on top of DTLS saved any time but it introduced a lot of problems. One of the biggest mistakes in TLS and DTLS is that they are built around the assumption that there is a public key handshake at the start of each connection and efficient restart is an afterthought. We have managed to add in Kerberos ticket like options to TLS over the years but they are extensions rather than the core. That said, my current proposal is intended as a starting point, not a definitive edition. SXS-Connect is built on TLS which I believe is the right approach for the client-resolver connection which I see as a one time device initialization step. If we decide that label minimization is not sufficient for the resolver-authoritative step then it would be logical to anchor the trust chain for that exchange in DNSSEC authenticated keys. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
