IETF Logo Mail Archive

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

Tero Kivinen <kivinen@iki.fi> Tue, 12 December 2017 19:34 UTC

Return-Path: <kivinen@iki.fi>
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 3BAE9129541 for <tcpinc@ietfa.amsl.com>; Tue, 12 Dec 2017 11:34:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 Vru0qZfwgVsl for <tcpinc@ietfa.amsl.com>; Tue, 12 Dec 2017 11:34:56 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41C712952E for <tcpinc@ietf.org>; Tue, 12 Dec 2017 11:34:55 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id vBCJYhHl008848 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Dec 2017 21:34:43 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vBCJYgVZ025502; Tue, 12 Dec 2017 21:34:42 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23088.12114.962463.320939@fireball.acr.fi>
Date: Tue, 12 Dec 2017 21:34:42 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Valery Smyslov <svanru@gmail.com>
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>
In-Reply-To: <E7AF7C0A2811484F8C475C00F74FC97D@chichi>
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> <E7AF7C0A2811484F8C475C00F74FC97D@chichi>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 5 min
X-Total-Time: 5 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/AWTuYd5yYvnufI90I5IHv1lLB6Y>
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 19:35:03 -0000

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

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

v2.23.0 | Report a Bug | By Email