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
- [tcpinc] Resumption safety (was "Eric Rescorla's … Kyle Rose
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Black, David
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Tero Kivinen
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Valery Smyslov
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Black, David
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Kyle Rose
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Eric Rescorla
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Eric Rescorla
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Valery Smyslov
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Black, David
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Kyle Rose
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Kyle Rose
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Valery Smyslov
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Tero Kivinen
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Kyle Rose
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Valery Smyslov
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Valery Smyslov
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Black, David
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Tero Kivinen
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Valery Smyslov
- Re: [tcpinc] Resumption safety (was "Eric Rescorl… Tero Kivinen