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

[Kyle Rose <[e-mail]>]

Apologies for the radio silence: I was completely hosed by Akamai's
annual tech summit last week. To resume the discussion:

On Mon, Dec 4, 2017 at 3:29 PM, Black, David <[e-mail]> wrote:
>> But I was referring to a slightly different situation. If you freeze running VM, clone it, then
>> resume for a while, then stop it and resume the clone, then internal state of your cloned VM
>> will be exactly the same as it was in the first reincarnation of VM.
>
> That assumes that the VM has no external interactions.  While that's possible in a completely controlled environment (e.g., running two VMs in near-lockstep for fault-tolerance), it's rather atypical in practice, as VMs are exposed to differences in events such as, interrupt timing, inbound network I/O contents and actual wall-clock time.

It's not clear that this will make its way into the entropy pool
before use unless the hypervisor and guest kernel have some explicit
interaction to re-seed the entropy pool before resumption. I think
Valery and I agree on the danger here, and on the hopelessness of the
case in which both endpoints are VM clones without such explicit
support.

> I agree that one cannot rely on a VM detecting that it has been resumed, however...
>
> There are interesting (at least to me) situations that are part of the way there - the VM has been stopped/frozen for long enough that the TCP connections drop when the VM is resumed.

In the absence of on-path state (e.g., connection-tracking NATs), all
state related to a TCP connection exists on the endpoints. Thus, you
still end up in this scenario unless the kernel times out the
connection preemptively upon resumption after a sufficient delay,
something I am fairly confident would *not* always happen based upon
my experience resuming keepalive-free connections after a half hour or
more.

> Independent of why a TCP connection dropped, tcpcrypt resumption from there would be more robust if it injected fresh nonces and new entropy.

Fresh nonces are a function of many things, implementation-defined.
Timestamp would presumably be sufficient to avoid most problems here.
Better still (avoiding clock-handling and time synchronization errors)
would be fresh entropy injected prior to VM resumption. Both are
really outside the scope of the guest's control: I can always
construct a situation in which a system would send different data with
the same key and nonce. That said, I think the discussion here is
about making the protocol *able* to take advantage of newly-injected
entropy, which currently it is not. And on that point, I agree with
Ekr. Fresh nonces from both the client and server, along with support
from the VM infrastructure to make sure those nonces are generated
from fresh entropy, eliminates all but the most contrived scenarios.

Kyle