Subject: [tcpinc] Review of tcpcrypt

From: Yoav Nir <[email-masked]>
Date: Tue, 29 Mar 2016 10:19:18 +0300

Hi

I’ve reviewed the tcpcrypt draft. Usual caveat: IANAC, so I won’t comment on the strength of the algorithms used.

In general, the draft looks OK. There should be clarity improvements, but I think if I had a TCP stack, this draft and the ENO draft, I could probably implement this (assuming I have a library with the algorithms, of course).

A few things stood out:

- Section 3.4 argues that HKDF could not be used directly because "tcpcrypt requires multiple expand steps with different keys”. TLS 1.3 and IKEv2 use HKDF (or something similar) directly. I’m not arguing that what the tcpcrypt draft is doing is wrong. It looks fine, but you could use HKDF directly, generate session keys plus a “next” key, and then when rekeying you could generate the next set of keys from the “next” key and then discard all previous keys including the “next” key.  Again, the current key management seems fine, I’m just not sure the argument is correct

- Section 3.9 gives the justification for sending keep-alives as "for applications to ensure that the other end of a TCP connection still exists even when there is no data to be sent." That may be true, but another big reason for sending keep-alives is to keep sessions alive in middleboxes, especially NAT boxes and to a lesser degree firewalls. These middleboxes have been known to lose state after as little as 30 seconds ("behave" WG admonitions notwithstanding) and to block or mangle subsequent "out-of-state” packets.

- Security Considerations: "implementations MUST disable tcpcrypt after rebooting until the pseudo-random generator has been reseeded". I think we should add: "or alternatively block the initiation of the TCP connections until such time." Reasoning: while tcpcrypt is vulnerable to active attackers and we can't guarantee security, we can (and should!) guarantee to at least try. Also, in most systems (PCs, phones, servers) the PRNG will be properly seeded eventually, and "eventually" here is a few seconds. Losing a few seconds at boot-up is IMO worth it for saying that we always try to use tcpcrypt. So don't make it a MUST, but leave the option open.

So to summarize, the protocol in this draft looks fine to me.

HTH

Yoav