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

From: "Black, David" <[email-masked]>
Date: Fri, 1 Dec 2017 14:48:45 +0000

> > > 2)      Copying a running virtual machine, including memory, which creates a
> > > copy of the session secrets.  Such copies are routinely stored on non-volatile
> > > storage, from which the VM can be resumed.
> 
> [...]
> 
> > > An additional reason for concern is that the encryption provided by the mandatory
> >> AEAD algorithm for tcpcrypt, AEAD_AES_128_GCM, is a stream cipher (AES GCM),
> >> for which reuse of a <nonce, key> pair is catastrophic - XOR-ing the two
> ciphertexts removes encryption.
> 
> 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.

Thanks, --David (still as an individual, not WG chair)

---

From: Kyle Rose <[email-masked]>
Date: Fri, 1 Dec 2017 14:56:23 -0500

> the current tcpcrypt design does not.  If a restart happens, both protocols (obviously)

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Dec 2017 16:08:40 -0800

On Thu, Nov 30, 2017 at 10:54 PM, Valery Smyslov <[email-masked]> wrote:

> Hi,
> > Black, David writes:
> >> for which reuse of a <nonce, key> pair is catastrophic - XOR-ing the
> two ciphertexts removes encryption.
>

Actually, the problem here is unique to tcpcrypt because it doesn't use a
nonce during resumption, so
reuse of the resumption key causes failure. That does not happen in TLS or
(I believe) IKE.

-Ekr

> Regards,
> Valery Smyslov.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Dec 2017 16:09:37 -0800

> 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

---

From: "Valery Smyslov" <[email-masked]>
Date: Sun, 3 Dec 2017 16:42:41 +0300

Hi Eric,

> Actually, the problem here is unique to tcpcrypt because it doesn't use a nonce during resumption, so
> reuse of the resumption key causes failure. That does not happen in TLS or (I believe) IKE.
> 
> -Ekr

Thanks for clarification, I can see that tcpcrypt behaves less secure in resumption than TLS
or IKE (and you are right, IKE does use a nonce during resumption). 

But I was reffering to a slightly different situation. If you freeze running VM, clone it, then
resume for a while, then stop it and resume the clone, then internal state of your cloned VM
will be exactly the same as it was in the first reincarnation of VM. If you implement cipher in software,
then all counters, used for couner-based encryption mode will repeat, that will break
security regardless of the security protocol in use. Of course, if the event of VM resumption is somehow 
detected by implementation inside VM, then the implementation can immediately delete old session
and create a new one, adding (hopefully) fresh nonces. I'm not sure that software inside 
VM can always detect that the VM is resumed.

Regards,
Valery.

---

From: "Black, David" <[email-masked]>
Date: Mon, 4 Dec 2017 20:29:02 +0000

Hi Valery,

Thanks for contributing to the discussion.

> But I was referring to a slightly different situation. If you freeze running VM, clone it, then
> will be exactly the same as it was in the first reincarnation of VM.

That assumes that the VM has no external interactions.  While that's possible in a completely controlled environment (e.g., running two VMs in near-lockstep for fault-tolerance), it's rather atypical in practice, as VMs are exposed to differences in events such as, interrupt timing, inbound network I/O contents and actual wall-clock time.

> Of course, if the event of VM resumption is somehow

I agree that one cannot rely on a VM detecting that it has been resumed, however...

There are interesting (at least to me) situations that are part of the way there - the VM has been stopped/frozen for long enough that the TCP connections drop when the VM is resumed.  TCP connection drop is clearly visible to implementations, although it's not specific to VM resumption, but it does yield common (IMHO) scenarios where an expected response to VM suspend/resume is protocol resumption.  Independent of why a TCP connection dropped, tcpcrypt resumption from there would be more robust if it injected fresh nonces and new entropy.  My rationale for "new entropy" in addition to "fresh nonces" is to try to obtain divergence in nonce generation between the original VM and its clone.

>> with (b), the client would have to have both a bad PRNG and a broken

That "one failure" might be a subtle code bug.  Continuing...

>> clone problem as the server is completely hopeless.)

I differ somewhat on "completely hopeless" - see discussion of "divergence in nonce generation" above - if the VM and its clone are unlikely to send the same nonce, then the situation is better.  Cloning of both client and server can happen if both are part of a larger multi-VM aggregation (e.g., application) that gets cloned for testing purposes, or just to be able to get back to a known good state if something goes sour.

> -----Original Message-----
> From: Valery Smyslov [mailto:[email-masked]]
> Sent: Sunday, December 3, 2017 8:43 AM
> To: Eric Rescorla <[email-masked]>
> Cc: Black, David <[email-masked]>; tcpinc <[email-masked]>; Kyle
> Rose <[email-masked]>; Mirja Kuehlewind (IETF) <[email-masked]>
> Subject: Re: [tcpinc] Resumption safety (was "Eric Rescorla's Discuss on draft-
> ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)")
> 
> Hi Eric,
>

---

From: Kyle Rose <[email-masked]>
Date: Mon, 11 Dec 2017 14:01:48 -0500

Apologies for the radio silence: I was completely hosed by Akamai's
annual tech summit last week. To resume the discussion:

> That assumes that the VM has no external interactions.  While that's possible in a completely controlled environment (e.g., running two VMs in near-lockstep for fault-tolerance), it's rather atypic…

It's not clear that this will make its way into the entropy pool
before use unless the hypervisor and guest kernel have some explicit
interaction to re-seed the entropy pool before resumption. I think
Valery and I agree on the danger here, and on the hopelessness of the
case in which both endpoints are VM clones without such explicit
support.

> There are interesting (at least to me) situations that are part of the way there - the VM has been stopped/frozen for long enough that the TCP connections drop when the VM is resumed.

In the absence of on-path state (e.g., connection-tracking NATs), all
state related to a TCP connection exists on the endpoints. Thus, you
still end up in this scenario unless the kernel times out the
connection preemptively upon resumption after a sufficient delay,
something I am fairly confident would *not* always happen based upon
my experience resuming keepalive-free connections after a half hour or
more.

> Independent of why a TCP connection dropped, tcpcrypt resumption from there would be more robust if it injected fresh nonces and new entropy.

Fresh nonces are a function of many things, implementation-defined.
Timestamp would presumably be sufficient to avoid most problems here.
Better still (avoiding clock-handling and time synchronization errors)
would be fresh entropy injected prior to VM resumption. Both are
really outside the scope of the guest's control: I can always
construct a situation in which a system would send different data with
the same key and nonce. That said, I think the discussion here is
about making the protocol *able* to take advantage of newly-injected
entropy, which currently it is not. And on that point, I agree with
Ekr. Fresh nonces from both the client and server, along with support
from the VM infrastructure to make sure those nonces are generated
from fresh entropy, eliminates all but the most contrived scenarios.

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Mon, 11 Dec 2017 14:29:03 -0500

I want to add:

On Mon, Dec 11, 2017 at 2:01 PM, Kyle Rose <[email-masked]> wrote:
> interaction to re-seed the entropy pool before resumption.

...and unless applications pull new entropy from this pool for every
single PRNG iteration, something I think is not done by userspace
PRNGs more complicated than "read directly from /dev/urandom". The
application would need to be aware of the resumption, or add
expected-distinct input to the PRNG as a matter of course (e.g.,
timestamp). And even then, there's still a race condition depending on
the order of operations.

The more I look into this, the more convinced I am that SIV-like
constructions are the only way to entirely avoid catastrophic loss of
security. To otherwise deal completely with the problem of VM cloning
involves the invasive complexity of layer violation. That said, I
don't think we want to take that step at this late date, but we should
recognize the benefits and limitations of adding nonces and look into
adding GCM-SIV (and related) cipher modes as future TEPs.

Kyle

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 12 Dec 2017 09:50:57 +0300

Hi Kyle,

> security. 

That was exactly my point.

To otherwise deal completely with the problem of VM cloning
> adding GCM-SIV (and related) cipher modes as future TEPs.

The issue is not tcpcrypt specific. TLS, IPsec and other
security protocols that use counter-based cipher modes 
are likely to be vulnerable to VM cloning/resumption problem as well.

That's why I agree that we shouldn't take any steps now (in a hurry and for 
tcpcrypt only). The problem should be recognized and addressed 
in a more generic way.

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Dec 2017 19:27:20 +0200

> are likely to be vulnerable to VM cloning/resumption problem as well.

Note, that VM cloning/resumption operations are most likely trying to
indicate the changing status to the operating system.

Even without any security if you clone a VM, allow the both of them to
run, the TCP sessions connected from those two devices to servers are
going to be messed up. 

This means that when you clone the VM, VM system might change the MAC
address of the virtual network card, so that you will not have
duplicate MAC addresses in the same virtual network. To do that they
most likely use some kind of plug and play virtual network interface
and remove that interface and then reinstall new interface with new
MAC. This also of course triggers DHCP and they will get new
IP-addresses, thus all TCP state will get destroyed (btw, does this
remove ability to use tcpinc resumption, i.e., can you do tcpinc
resumption using different IP?).

On other case where you take snapshot of VM, run it forward for a
moment, and then stop it and resume back to previous snapshot, the
situation is similar, i.e., the resumed VM will have different TCP
session state anyways, thus VM should not even try to keep that
intact. This means that on resumption VM system most likely also fakes
a network link status change, i.e., just like you had disconnected the
ethernet cable and put it back in. This usually triggers operating
system to rerun the DHCP, which might get new IP address etc, but in
case of resumption they might actually get the same IP back, but some
operating systems immediately tear down all TCP connections when the
link is broken, thus TLS (and tcpinc) TCP connections would get
broken, and they would fall back to resumption etc.

All of these are trying to indicate the operating system that
something has changed. For example IPsec SAs are quite commonly tied
to the specific interface, meaning that when you remove the interface
those get teared down and new SAs are created (perhaps using IKE
resumption). Or if only IP-address changes, then IKE will run mobike
to move the SAs to new IP-address, and if mobike is not available it
will tear down the SAs and recreate them. They might also send
operating system indications that machine is resuming from the sleep,
which might again do some kind of cleaning up operations.

I.e., the VM system vendors are trying to make things work, meaning
they will try to do tricks that will trigger proper response in the
operating systems.

This might also include things like virtual true random number
generator device (which would require support from the operating
system) to solve the issue with the random numbers in the VMs.

So if VMs can solve this issue by forcing resumption they will try to
do that as that makes things just work better. With TLS, IKEv2 etc
this will work as we have fresh nonces that get used in those cases.
I think tcpinc should also try to work for those cases, i.e., the
resumption should include something that make sure that it is using
fresh keys. 

> tcpcrypt only). The problem should be recognized and addressed 

I disagree on that. I do not think the issue is with the existing
traffic keys, it is what you do when traffic keys are already gone
(i.e., VM resume operations done by the operating system cleaned
them), but you want to do resumption to recreate them.

Current VM systems are tuned for working with protocols like TCP,
IPsec and TLS, and they try to do things that makes them work. If same
mechanism work also for tcpinc, then tcpinc will get those for free.
If not, then we need to wait for VM and operating system vendors to
find out a way to get things working with tcpinc.
-- 
[email-masked]

---

From: Kyle Rose <[email-masked]>
Date: Tue, 12 Dec 2017 12:33:03 -0500

On Tue, Dec 12, 2017 at 1:50 AM, Valery Smyslov <[email-masked]> wrote:
> tcpcrypt only).

Just to clarify, (speaking as member, not chair) I am in favor of
adding nonces on each connection, but (as chair) not in favor of
changing MTI TEPs to SIV.

> The problem should be recognized and addressed
> in a more generic way.

Agreed.

Kyle

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 12 Dec 2017 20:46:08 +0300

> changing MTI TEPs to SIV.

Yes, that's what I meant. We are in agreement here.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 12 Dec 2017 21:17:02 +0300

Hi Tero,

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.

Regards,
Valery.

-----Original Message----- 
From: Tero Kivinen
Date: 12 декабря 2017 г. 20:27
To: Valery Smyslov
Cc: 'Kyle Rose' ; 'Black, David' ; 'Eric Rescorla' ; 'Mirja Kuehlewind (IETF)' ; 'tcpinc'
Subject: Re: [tcpinc] Resumption safety (was "Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS 
and COMMENT)")

---

From: "Black, David" <[email-masked]>
Date: Tue, 12 Dec 2017 18:53:09 +0000

+1, also as an individual (not as WG chair).

Thanks, --David

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Dec 2017 21:34:42 +0200

> 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 do not think it is good idea to create new requirements for VMs,
i.e., that in addition to just resetting TCP connections, they need to
do something else to force tcpinc to generate new keys (for example
perhaps changing the IP-address, which might cause other issues).

I.e., if we make sure both tcpinc and TLS behave similarly in this
regard, then we are on the safer side and there is no nasty suprises
for the VM users.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 12 Dec 2017 23:05:35 +0300

> to be reset, and new TCP connections to be created) will work for

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.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Dec 2017 02:13:48 +0200

> I agree that tcpinc resumption could (should?) have been designed better.

Good. And this was the discussion point here, I think. The original
question was whether the resumption should have nonce or not, i.e.,
resumption safety.

> Nonce-misuse resistant modes (like GCM-SIV) would help in this case.

I agree on that, but I think it is outside the scope of this
discussion (subject line says "Resumption safety").
-- 
[email-masked]