Re: [tcpinc] Resumption safety (was "Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)")

["Black, David" <[e-mail]>]

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