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