Subject: [dns-privacy] TCP? Re: tcpinc ?

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Mar 2015 14:11:35 -0500

On Mon, Mar 2, 2015 at 12:16 PM, Ilari Liusvaara <
[email-masked]> wrote:

> On Mon, Mar 02, 2015 at 11:28:54AM -0500, Phillip Hallam-Baker wrote:
> > On Mon, Mar 2, 2015 at 9:00 AM, Ilari Liusvaara <
> [email-masked]
> > > wrote:
> >
> > >
> > > I would see the point of using UDP (which means increased complexity):
> >
> >
> > No it does not.
> >
> > UDP is a lot simpler than any of the TCP proposals.
> >
> > * Fewer states
> > * Smaller library
> > * Fewer options
>
> - TCP orders the packets
>

Not very important. Most DNS query transactions can be fit into a single
request/response message.

I am proposing to keep the 'single request packet' and only loosen the
'single response packet' to permit up to 16 packets.

If people think that multiple response packets are too much burden on the
client then we could make this part an option even.

> - TCP retransmits

Irrelevant, we already do this in DNS over UDP. If you don't get a response
you ask the question again.

> - TCP does error correction.
>

Irrelevant. First of all the error correction is not at all good. It is a
short checksum without any crypto strength behind it.

> - TCP deals with reflection.
>

Again, the weak protections in TCP are irrelevant because we are doing
crypto and we should be looking for strong authentication of requests and
responses.

> Sure, one can do all the above with UDP-based protocols, but that means
> extra code.
>

A lot less code than futzing about with the PKIX stack or the TLS stack.

> DNS requires TCP already (as fallback for when packet limits get busted).

I think that was always a horrid hack and it has never really worked at all
well, has it?

If people were happy doing DNS over TCP then most of the objections raised
against DNSSEC would have gone away.

> > TLS is a big complicated specification and the open source libraries are
> in
> > a woeful state. Take a look at the date the tutorial on the OpenSSL API
> was
> > written.
>
> There is UDP counterpart to TLS called DTLS. It is more complicated than
> TLS (due to above factors).

I don't recommend DTLS because it is designed to provide security for
applications like VOIP where people really are reinventing TCP in UDP.

> The expeditious approach to setting up a client-service binding is to
> > leverage TLS. But that is separate from the DNS session transport
> question
> > and something that can be revisited later.
>
> I think (D)TLS is too complicated for stub<->recursive protocol (even if
> profiled down).
>

Agree.

That is not what I am proposing.

> Also, can't deal with fast session startup until TLS 1.3 (which is still
> quite complex and doesn't look even near finished, let alone DTLS 1.3).
> Plus the scope of present challenge looks much smaller than TLS (e.g. no
> client authentication, server recon is feasible, etc...).
>

TLS is a big, complicated stack. I want to limit exposure to it as much as
possible. Just leverage it during a one time device binding operation and
then not use it again

> Of course, designing a new crypto protocol is pretty scary prospect
> (I have seen one that has even simpler scope and looks totally messed
> up).
>

If people don't think we can do crypto protocols then we should shut down
DPRIV now. We are doing a new crypto protocol whatever we do. The question
is how we put the parts together.

The hard parts are key management and exchange and we don't need to
reinvent that. Just reuse TLS for that part.

The only parts we would be doing new are to write a new framing scheme
which is a very well understood problem at this stage and optionally write
a perfect forward secrecy option.

On the PFS thing, the TLS exchange is botched anyway. adding in a PFS key
should not downgrade security. Which is what happens if you use a WF 128
ephemeral after a WF256 master exchange.