On Jun 3, 2014, at 10:26 AM, Phillip Hallam-Baker <[email protected]> wrote:
> On Tue, May 20, 2014 at 12:06 AM, joel jaeggli <[email protected]> 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. If we required those extensions to be implemented, what's the problem? -d > > > 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. > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
