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
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
