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. Preventing fragility means ensuring we are not in a hazardous state, i.e., that we are two or more uncorrelated failures away from breakage. The server VM clone situation pushes this mitigation entirely to the client because a resumed VM may very well have a PRNG in the same state, and so produce the same nonce for the same connection on every subsequent resumption. I think what we're relying on here is for the *client* not to both (a) request ss[i] twice and (b) send the same nonce twice. Without (b), we're only one failure away from breakage; with (b), the client would have to have both a bad PRNG and a broken resumption stack. (Note that the situation in which a client suffers from the same VM clone problem as the server is completely hopeless.) Kyle _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
