my point was: if VM systems are designed in such a way, that they can
force the inside software to reset existing cipher states in case of VM
resumption
IN ALL cases, then we are on the safe side. Your examples below bring
me to a conclusion, that IN SOME (or even in most) cases these tricks work.
Still not sure they work always.
Yep. They do not work always, but if we design tcpinc in same way than
TLS, i.e., resumption always guarantees that we have new keying
material, then solutions which work for TLS (i.e. forces TCP sessions
to be reset, and new TCP connections to be created) will work for
tcpinc too.
I agree that tcpinc resumption could (should?) have been designed better.
No disagreement here.
My point was more generic. If internal cipher state of any protocol
using counter mode has a chance to survive VM resumption
and continue to work (even for a short time), then a counter re-use
(and thus a catastrophic lose of security) could happen.
Nonce-misuse resistant modes (like GCM-SIV) would help in this case.
_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
