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

"Black, David" <David.Black@dell.com> Thu, 30 November 2017 14:55 UTC

Return-Path: <David.Black@dell.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 6F9191242F7 for <tcpinc@ietfa.amsl.com>; Thu, 30 Nov 2017 06:55:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=Hgi1NXWt; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=RNdIcSVX
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 WhISzCruMaHD for <tcpinc@ietfa.amsl.com>; Thu, 30 Nov 2017 06:55:45 -0800 (PST)
Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 1C800120724 for <tcpinc@ietf.org>; Thu, 30 Nov 2017 06:55:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1512053745; x=1543589745; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BSip0j6YNyBPqFDjey2dwjDAK2R/z+AqiTIYQlw5QmM=; b=Hgi1NXWt2o4k9Fu1U65bI+586+oJMp+T8HZ4WjLIkUP6r9xKTGAUtTFd HdQAcJed2iTDwO/yCisrEZk5tjVUppU22Cc/55IeuEXIm7SfSU7KDkAQC s6ypqLu2HQ98D6CYSBdA6dLAijezFp/ERSm28888E/pQThaV7+QXoMh0L c=;
IronPort-PHdr: =?us-ascii?q?9a23=3AJ/FxYhcXlwIgZn6yH/U2XupmlGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxcW7YB7h7PlgxGXEQZ/co6odzbGH4+a4ASQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9GiTe5Yr5+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYe?= =?us-ascii?q?RWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZ?= =?us-ascii?q?TAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v9LlgRgP2hy?= =?us-ascii?q?gbNj456GDXhdJ2jKJHuxKquhhzz5fJbI2JKPZye6XQds4YS2VcRMZcTyxPDJ2h?= =?us-ascii?q?YYsTAeQPPuhYoIv8p1QSohSzHhOjCP/rxzJSmnP6wa833uI8Gg/GxgwgGNcOvW?= =?us-ascii?q?zaoNjoMKcdS/y6zKrQwT7eYf1Zwyn96InVfRwvvPqBWrx+ftDPyUkuCgzJlEid?= =?us-ascii?q?qYj/MDyJ1eQAqHWU4PRkVeKrkWIotwZxoj22y8oql4LHiIUVylXe+iV4xoY4Pd?= =?us-ascii?q?y4R1BnYd6qCpdQsDuaN4RwT8g/QG9ooD43x7wFtJKhYiQHxoorywTCZ/GHfIWE?= =?us-ascii?q?+BbuWeWJLTtlmH5pYqyzihix/ES6xeDxWdO43EtEoydGitXMuG4C2h/P5sWCT/?= =?us-ascii?q?Zw/Uis1DKB1w3W6uxLPFo7mbTeJpI837I/jZ8evEvNEyL1mEj7irKdeF8+9eiy?= =?us-ascii?q?8evnZ63rppqbN4BplA7zKr8umsmjAeQgNQgOQnSb9fy81LL9+U35R61HgeMtkq?= =?us-ascii?q?bDv53WP9kUqbC9Aw9Ry4oj7Au/Dyu939QfgHkHKk9KdAydg4joI1HOIPX4DPil?= =?us-ascii?q?j1uwlzdrwujKPrznAprTMnjOiLbscLVn50JCxgc/08pT649UB7wOOv7+Xkz8uM?= =?us-ascii?q?TdDhAjMgy0x+jnCM961oMbQW+BDLWWML3TsVCV/O4iPu2Ma5UJtzb+MPUq+uDh?= =?us-ascii?q?jXs9mVMHYaap2p4XZGiiHvt6O0WZfWbsgtAZHGcWogU+VO3qiFueXjNIZna9Qb?= =?us-ascii?q?485j8hBIKhF4fDSdPlvLvU/za/E9VsYXtLQgSPC3Dzeq2HQfAXZWSVOMA31nQY?= =?us-ascii?q?XqCgTYRpgQ2lrA78wJJmI/bavCoCusSw+sJy4riZvxU7/j8wR+iUzWCBBSkgsm?= =?us-ascii?q?oWRjNw9qR2qk9VxlqH1e5zhPkORo8b3O9ATgpvbc2U9Od9Ed2nH1uZJto=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2F1AABrGyBah2Ka6ERcGwEBAQEDAQEBC?= =?us-ascii?q?QEBAYJKIoEmEG4nB4N4mRKBfZZ2EIE+QwojhElPAhqFB0EWAQEBAQEBAQEBAQI?= =?us-ascii?q?QAQEBCA0JCCgvgjgkAQ5IIQUGAQEBAQEBJgEBAQEBAQEBAQEBAQEBAQEBARcCP?= =?us-ascii?q?QESAhgBAQEDASMKEx8aAQQLAgEIDgMEAQELGQQDAgICMBQJCAIEAQ0FCIk2XAg?= =?us-ascii?q?BD6ZKgieDEIdWAQEBAQEBAQEBAQEBAQEBAQEBAQEBFQMFg0GBNjEigVeBaIMrg?= =?us-ascii?q?zKBOwERAgEIAgQSKwmCXzGCMotJlxEGApclhg+LLpYYAgQCBAUCGoE6JgGBE3B?= =?us-ascii?q?vT4IpCYJZJYFOeAGHPIEygRQBAQE?=
X-IPAS-Result: =?us-ascii?q?A2F1AABrGyBah2Ka6ERcGwEBAQEDAQEBCQEBAYJKIoEmEG4?= =?us-ascii?q?nB4N4mRKBfZZ2EIE+QwojhElPAhqFB0EWAQEBAQEBAQEBAQIQAQEBCA0JCCgvg?= =?us-ascii?q?jgkAQ5IIQUGAQEBAQEBJgEBAQEBAQEBAQEBAQEBAQEBARcCPQESAhgBAQEDASM?= =?us-ascii?q?KEx8aAQQLAgEIDgMEAQELGQQDAgICMBQJCAIEAQ0FCIk2XAgBD6ZKgieDEIdWA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBFQMFg0GBNjEigVeBaIMrgzKBOwERAgEIAgQ?= =?us-ascii?q?SKwmCXzGCMotJlxEGApclhg+LLpYYAgQCBAUCGoE6JgGBE3BvT4IpCYJZJYFOe?= =?us-ascii?q?AGHPIEygRQBAQE?=
Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2017 08:55:43 -0600
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2017 20:55:42 +0600
Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vAUEtcoB013335 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Nov 2017 09:55:41 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com vAUEtcoB013335
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1512053742; bh=N3WWjkmXunvsHTSakfVXPv5d4CU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=RNdIcSVXnCDOyD8GzhaQr0qDGHX4/WUk29wlFxYpGr5UE06hK/fnZPaXvryiQAAc4 hPNR+BE2/RyfdHjBfYuuBQSyLZIsmxnccD2ut6rpxVaxbmK4optzjmalvnBUQoAgVj V2FBOeMPkFmeJy6zuqWGGxsqGemtruhWR1gF3Mp0=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com vAUEtcoB013335
Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd04.lss.emc.com (RSA Interceptor); Thu, 30 Nov 2017 09:55:19 -0500
Received: from MXHUB317.corp.emc.com (MXHUB317.corp.emc.com [10.146.3.95]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vAUEtSWu021821 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 30 Nov 2017 09:55:28 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB317.corp.emc.com ([10.146.3.95]) with mapi id 14.03.0352.000; Thu, 30 Nov 2017 09:55:27 -0500
To: Kyle Rose <krose@krose.org>, tcpinc <tcpinc@ietf.org>
CC: Eric Rescorla <ekr@rtfm.com>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Thread-Topic: [tcpinc] Resumption safety (was "Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)")
Thread-Index: AQHTaWeKaqBgAqiJTU6Vp2CkSB85m6Ms+8NA
Date: Thu, 30 Nov 2017 14:55:27 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362FD96B0D@MX307CL04.corp.emc.com>
References: <CAJU8_nUUHbmFcPA2obo6q3dLqL1MGE2iKen-0EQ82re=+gtTfw@mail.gmail.com>
In-Reply-To: <CAJU8_nUUHbmFcPA2obo6q3dLqL1MGE2iKen-0EQ82re=+gtTfw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.44.138]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FD96B0DMX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com
X-RSA-Classifications: public, GIS Solicitation
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/0ZPllLIxweY5DXEVV9tfzfiWQxs>
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: Thu, 30 Nov 2017 14:55:52 -0000

Expanding on this:

> There is language in the draft prohibiting reuse of ss[i]:
>
>   q( A session secret may not be used to secure more than one TCP
>   connection.  To prevent this, a host MUST NOT resume with a session
>   secret if it has ever enabled encryption in the past with the same
>   secret, in either role. )
>
> but there is concern that this language is not strong enough: first, that it does
> not explain the reason for the prohibition; and second, because the prohibition
> refers only to "a host" and does not directly address the threat posed by sharing
> of resumption state across machines.

Here are a few ways in which this can go wrong in practice:


1)      State extraction, including session secrets, to resume on a different physical or virtual host, possibly as part of failover.

a.       This is the server cluster case in Ekr’s original review of this draft.

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.

a.       The text in the draft that says “Hosts SHOULD NOT write any session secrets to non-volatile storage” seems unlikely to affect this sort of data center operational practice.

3)      Implementation bug that reuses session secrets.

a.       Such reuse violates the MUST NOT requirement quoted above, but that’s not an absolute bar to code bugs.

My take as an individual is that while it’s plausible to write “MUST NOT” text for state extraction (1), the other two situations are much more difficult to avoid/prevent.

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.

Thanks, --David

From: Tcpinc [mailto:tcpinc-bounces@ietf.org] On Behalf Of Kyle Rose
Sent: Wednesday, November 29, 2017 6:12 PM
To: tcpinc <tcpinc@ietf.org>;
Cc: Eric Rescorla <ekr@rtfm.com>;; Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>;
Subject: [tcpinc] Resumption safety (was "Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)")

In the IETF LC thread referenced in the thread subject (CC'ed to the tcpinc list), Ekr (acting as security AD) raised an issue on which we need to seek rough consensus from the WG: that of the key-reuse risk potential in the resumption key schedule.

Please see that thread for more details (especially Ekr's email from Nov 18, in the archives at https://www.ietf.org/mail-archive/web/tcpinc/current/msg01471.html), but a brief summary is that, with the catastrophic loss of security inherent in AEAD modes like GCM when the same key and nonce are used to encrypt multiple blocks, the construction of ss[i] (see section 3.3 of draft-ietf-tcpinc-tcpcrypt-10) depending only on ss[i-1] and some constants, and in particular *not* depending on fresh randomness from each party, will inevitably break confidentiality and authentication should an implementation not strictly prevent the reuse of ss[i] on multiple connections.

There is language in the draft prohibiting reuse of ss[i]:

q( A session secret may not be used to secure more than one TCP
connection.  To prevent this, a host MUST NOT resume with a session
secret if it has ever enabled encryption in the past with the same
secret, in either role. )

but there is concern that this language is not strong enough: first, that it does not explain the reason for the prohibition; and second, because the prohibition refers only to "a host" and does not directly address the threat posed by sharing of resumption state across machines.

Given the absence of a mechanism for stateless resumption in tcpcrypt (such as that provided by TLS session tickets), this prohibition essentially precludes resumption across a server pool via periodic state sharing, as there would be a race condition between use of ss[i] on one server and invalidation of that value throughout the rest of the pool.

The chairs are looking for direction from the WG on how to proceed. From the discussion in the other thread, I see a number of basic options, ranging from least- to most-invasive:

(1) Strengthening the language around this prohibition.
(2) Adding a 0-RT mechanism for adding fresh randomness to the resumption key schedule.
(3) Adding a 1-RT mechanism for adding fresh randomness to the resumption key schedule (that also provides a measure of replay protection at the cost of an additional round trip).
(4) Switching to a stateless resumption mechanism, which would necessarily involve fresh randomness (but at the cost of requiring an additional round trip for resumption owing to insufficient option space for encoding state).

I would like the WG to discuss the risks and benefits of each option and decide how to proceed. I believe we already have rough consensus on sticking with a stateful resumption scheme given the latency costs of stateless resumption under the constraints of TCP, but the WG can always reopen that question if there is rough consensus to do so.

Thanks,
Kyle