On Fri, Dec 1, 2017 at 11:56 AM, Kyle Rose <kr...@krose.org> wrote: > On Fri, Dec 1, 2017 at 9:48 AM, Black, David <david.bl...@dell.com> wrote: > >> 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. > > I'm not sure what you're trying to argue here. Assuming correct client > behavior, ss[i] will never be used twice, so we are necessarily > dealing with a situation in which the client is acting incorrectly. >
Or an on-path attacker captures the sessionid and replays it to the server. -Ekr
_______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
