> > > 2) Copying a running virtual machine, including memory, which > > > creates a > > > copy of the session secrets. Such copies are routinely stored on > > > non-volatile > > > storage, from which the VM can be resumed. > > [...] > > > > An additional reason for concern is that the encryption provided by the > > > mandatory > >> AEAD algorithm for tcpcrypt, AEAD_AES_128_GCM, is a stream cipher (AES > >> GCM), > >> for which reuse of a <nonce, key> pair is catastrophic - XOR-ing the two > ciphertexts removes encryption. > > This is not tcpcrypt problem. The same problem applies to any > security protocol (IPsec, TLS, etc.) that uses counter based cipher modes > (GCM, CCM, etc.). > Switch to nonce-misuse resistant modes.
The actual situation is more subtle than that. The VM is likely to be stored for long enough that TCP connections drop - if not, e.g., the VM is cloned and the clone runs immediately, that new VM likely has to be assigned a new IP address in order to not conflict with the existing VM, and that also drops TCP connections. In both cases, the security protocol resumes or restarts with a new TCP connection, providing an opportunity to inject entropy. TLS injects entropy when it resumes, but the current tcpcrypt design does not. If a restart happens, both protocols (obviously) use new entropy. Thanks, --David (still as an individual, not WG chair) _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
