Subject: Re: [perpass] [DNSOP] draft-bortzmeyer-dnsop-dns-privacy (was: DNS privacy : now at least two drafts)

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jun 2014 13:26:04 -0400

On Tue, May 20, 2014 at 12:06 AM, joel jaeggli <[email-masked]> 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.

---

From: Dan Wing <[email-masked]>
Date: Fri, 6 Jun 2014 17:38:11 -0700

> years but they are extensions rather than the core.

If we required those extensions to be implemented, what's the problem?

-d

> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Jun 2014 08:28:21 -0400

> If we required those extensions to be implemented, what's the problem?

Well first off only IETF folk think that we are in charge of the
Internet. The first law of the Internet is "you are so not in charge
(for all values of you)"

We have tried requiring many things like IPV6 and DNSSEC and it didn't
work. And even when it works, it is sloooooooooow.

But the second problem is that the ticket approach in TLS is only
there as an extension that provides a small performance gain. Which
isn't very interesting or valuable.

The value of the ticket approach isn't efficiency, its simplicity.
Build on the ticket approach from the ground up and build it into
everything and I can cut out 80% of the TLS spec AND 90% of IPSEC and
support the same functionality.

It is possible to buy a turntable for vinyl records with a USB plug on
the end to connect to a computer. That provides digital output but the
result is nothing like CD which is all digital end to end. Adding
tickets to TLS is like sticking a USB plug on an analog device: it
provides impedance matching but nothing more.