Hi Eric,
> 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.
Actually, the problem here is unique to tcpcrypt because it doesn't use a nonce
during resumption, so
reuse of the resumption key causes failure. That does not happen in TLS or (I
believe) IKE.
-Ekr
Thanks for clarification, I can see that tcpcrypt behaves less secure in
resumption than TLS
or IKE (and you are right, IKE does use a nonce during resumption).
But I was reffering 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. If you
implement cipher in software,
then all counters, used for couner-based encryption mode will repeat, that will
break
security regardless of the security protocol in use. Of course, if the event of VM resumption is somehow
detected by implementation inside VM, then the implementation can immediately delete old session
and create a new one, adding (hopefully) fresh nonces. I'm not sure that software inside
VM can always detect that the VM is resumed.
Regards,
Valery.
_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
