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

"Valery Smyslov" <svanru@gmail.com> Tue, 12 December 2017 18:17 UTC

Return-Path: <svanru@gmail.com>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD281294FD for <tcpinc@ietfa.amsl.com>; Tue, 12 Dec 2017 10:17:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.26
X-Spam-Level:
X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2b7VEFL7pnY for <tcpinc@ietfa.amsl.com>; Tue, 12 Dec 2017 10:17:10 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905A91294F5 for <tcpinc@ietf.org>; Tue, 12 Dec 2017 10:17:09 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id e137so24227011lfg.5 for <tcpinc@ietf.org>; Tue, 12 Dec 2017 10:17:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=yhhWdDD+KswzZJ9oDtWcYO98hD4YA+xq5FC7GG9o2Bw=; b=jpbRjWQ3lpTCfPnbp2+erNvw48s2v7hgXwtv0Jv4V1Xlwo9Co/wmtAsi08l9rKUbAN 36RIxSds4RvB3GJtW5bYOqt2n4TIy59IuovqZkvdEB625ilcrjBiG3A6JQk5Gk1ms13H ELT4kNnIoNsiTJ48wfEmqkssgzhu/OKhxE+/BC3RSWf6ZZEn8faKI58URoJTISdoqy0C heTj9M2MSuQ6T0X4WUwYsb6gaOF30Q4f4RYc3t7aJH/AvtK2IcN5lD8c+yDIiHSx/ZdQ Tc61TX6ajLTcVhXZL/3Huz8BMlNDfWMA02R5qFCdgbkyWPuI0chbFwH8WUHie22LiBtv NGNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=yhhWdDD+KswzZJ9oDtWcYO98hD4YA+xq5FC7GG9o2Bw=; b=FRBqfV253GHdhOwn6WUjTSy06QZ1/McyS2HwWt3P6RHmgFHKsttZCT7tBdtRPzb7GM fsbZ7RUjLxlGSqzBObv50Ab8WOE6Tip7WMNAsRMyjsRgwf3VdVknk3++56UpjIc0zVBN 4uL2EKuTuL3e5O7XO9n1f4KNm+WyU6luJEIdMUql/fJ8+MacRDLJuFKrvt10BY/NM9yI LFFe/p+B/cGKnKjAzUCYNZXwcu1O4Dw9ss3WAVAHw6kYk66vu9x1WwRbaS40Mo7ZUWd5 fymbjCdovoWrR5ftuWNXlkvMr5d7sSULClcvpbjYqdV+Hd5wL07+N5GCVH14DmxRQ0qL HUjw==
X-Gm-Message-State: AKGB3mIan+lQPy4dKLn1dDH2T6h3JLsnZ9iVMmoimdPm/tmGcqQmB7Eu T+YgzO70ss5WuiDnMJV/VpjW0A==
X-Google-Smtp-Source: ACJfBosujQbQc4XFNIYefD6L55KWoKNrM+62us91vUQ+apISnipqq1wyB9bPKzVn9AtSCEXwdfYWTg==
X-Received: by 10.25.77.68 with SMTP id a65mr2184777lfb.16.1513102627738; Tue, 12 Dec 2017 10:17:07 -0800 (PST)
Received: from chichi (ppp83-237-171-154.pppoe.mtu-net.ru. [83.237.171.154]) by smtp.gmail.com with ESMTPSA id y6sm3289097lfg.38.2017.12.12.10.17.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Dec 2017 10:17:06 -0800 (PST)
Message-ID: <E7AF7C0A2811484F8C475C00F74FC97D@chichi>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Tero Kivinen" <kivinen@iki.fi>
Cc: "'Kyle Rose'" <krose@krose.org>, "'Black, David'" <David.Black@dell.com>, "'Eric Rescorla'" <ekr@rtfm.com>, "'Mirja Kuehlewind \(IETF\)'" <ietf@kuehlewind.net>, "'tcpinc'" <tcpinc@ietf.org>
References: <CAJU8_nUUHbmFcPA2obo6q3dLqL1MGE2iKen-0EQ82re=+gtTfw@mail.gmail.com><CE03DB3D7B45C245BCA0D243277949362FD96B0D@MX307CL04.corp.emc.com><23072.32691.892725.97892@fireball.acr.fi><01bc01d36a71$45957db0$d0c07910$@gmail.com><CABcZeBPN_XQc8np3CWi_-AtDUafW4ZPc8EnRje8yj57Rv-vxyw@mail.gmail.com><B0FB25D40E23475C9259A4C204B327D2@chichi><CE03DB3D7B45C245BCA0D243277949362FDD6E73@MX307CL04.corp.emc.com><CAJU8_nW9fkn9E=NbKFZ3zy5uSY36WFqRcQpBYdyYuLwzAbqFHA@mail.gmail.com><CAJU8_nX7NOSG8hkUYqG_GeqSyPzmhwsyA30Z0riqRmwK8SozpQ@mail.gmail.com><073801d37315$90c89bd0$b259d370$@gmail.com> <23088.4472.814142.142233@fireball.acr.fi>
In-Reply-To: <23088.4472.814142.142233@fireball.acr.fi>
Date: Tue, 12 Dec 2017 21:17:02 +0300
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/z_ofYO4KmGyNWkNzyKz24c2wMh0>
Subject: Re: [tcpinc] Resumption safety (was "Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)")
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Dec 2017 18:17:13 -0000

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)")

Valery Smyslov writes:
> 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.

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.

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

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.
-- 
kivinen@iki.fi