Subject: Re: [tcpinc] Review of tcpcrypt

From: Daniel B Giffin <[email-masked]>
Date: Thu, 14 Jul 2016 17:18:29 -0700

Hi Yoav,

Thanks for your review (some months ago).  Now that we've
posted a new draft of tcpcrypt, I wanted to let you know how
we've addressed the points you brought up.

> - 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

Yes, I agree the argument there was spurious.  I've removed
it in the new draft.

We could indeed use the full (two-stage) HKDF everywhere we
use Expand (`CPRF` in our document).  But then, RFC 5869
explicitly permits the omission of Extract when the input is
already pseudo-random (see Introduction):

  In some applications, the input may already be a good
  pseudorandom key; in these cases, the "extract" stage is
  not necessary, and the "expand" part can be used alone.

So I think that RFC makes it clear what we are doing, and we
get the minor performance gain (and perhaps code-complexity
gain) of avoiding an HMAC operation.

> - 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.

Good point -- I've added this consideration to the new
"Design notes" section.

> - 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.

That makes sense.  ENO currently uses this language:

  Implementations MUST NOT send ENO options unless they have
  access to an adequate source of randomness [RFC4086].
  Without secret unpredictable data at both ends of a
  connection, it is impossible for encryption specs to achieve
  confidentiality and forward secrecy.  Because systems
  typically have very little entropy on bootup,
  implementations might need to disable TCP-ENO until after
  system initialization.

That language (Do not send ENO without a random source) is
more precise, and permits implementations to delay instead
of disable.  So I've echoed it in the new tcpcrypt draft.

daniel

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Jul 2016 10:17:14 -0700

FWIW, keepalives are also used to help use TCP as a "reachability
detector" for routing protocols as well.

Joe