Subject: [tcpinc] My analysis of the slides

From: Watson Ladd <[email-masked]>
Date: Sat, 15 Nov 2014 07:52:01 -0800

Dear all,

I've looked at draft-bittau-tcp-crypt, and I'm not sure I understand
some parts. There are several possible ways to encode P-256 public
keys in SEC1: it's not clear which have to be supported, and if we
decide to include any new curves, something extra may need to be said.
The key size for RSA is underspecified: the paper uses 2048 bytes, but
the draft doesn't mention it.

The citation for PRF based MACs doesn't work in the case of
Poly1305-AES-128 xored AES-128, as Poly1305 isn't a PRF. I'm sure the
necessary result is true enough, but I'd have to do some work to show
it.

The DTLS and TLS proposals look very similar: why is one better than
the other? There is no word on what features have to be supported, or
guidance on what the kernel vs. the underlying application will do.

The TCP-AO variant as it currently stands uses a 16 byte DH exchange.
That's going to be very weak, even with elliptic curves. 32 bytes
minimum works. SEC1 is not a network byte order encoding, it's a fixed
length with a prefix. There is a lot missing from the draft: cipher
choices, how negotiation works.

If I had to implement one of these in the kernel, it would be the
bittau draft. It's much simpler then alternatives, has running code,
and comes with measurements of deployment effects. It explains how
application layer can use the TCP connection for authentication and
encryption by checking socket options.

Sincerely,
Watson Ladd