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

[Eric Rescorla <[e-mail]>]

On Fri, Dec 1, 2017 at 11:56 AM, Kyle Rose <[e-mail]> wrote:

> 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.
>

Or an on-path attacker captures the sessionid and replays it to the server.

-Ekr