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

[Kyle Rose <[e-mail]>]

On Fri, Dec 1, 2017 at 9:48 AM, Black, David <[e-mail]> 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