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> Mon, 04 December 2017 20:29 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 64919128B88 for <tcpinc@ietfa.amsl.com>; Mon, 4 Dec 2017 12:29:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=dOv8boVy; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=dnB7VFER
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 mMF0qXgbiEbJ for <tcpinc@ietfa.amsl.com>; Mon, 4 Dec 2017 12:29:16 -0800 (PST)
Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (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 067371267BB for <tcpinc@ietf.org>; Mon, 4 Dec 2017 12:29:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1512418781; x=1543954781; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r1XlEzGiwODKmHobFPFryrdIb1m6KNm+M00KICt1Z1w=; b=dOv8boVy4M9fynQAFhocls4VxQwEN64FFpt0MB7Mtq2h3tmQkGQh8W4z tJyMyfC5jxzK2avfn35mcfTfhmGY5nb+2+s79IO+wKr396E8qhnyoSJ0e NHyRQVvIRcdQ8UlKkYT2LGWtMW/JsnJHAYFjbEbCmCm15LBYxMEAmFlUz k=;
IronPort-PHdr: 9a23:9Z5FWBc+1XUOMDrq8uVOsvAWlGMj4u6mDksu8pMizoh2WeGdxcSzYB7h7PlgxGXEQZ/co6odzbGH4+a4ASQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7Ovr6GpLIj8Swyuu+54Dfbx9GiTe5Yr5+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYeRWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZTAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v9LlgRgP2hygbNj456GDXhdJ2jKJHuxKquhhzz5fJbI2JKPZye6XQds4YS2VcRMZcTyxPDJ2hYYsTAeQPPuhYoIv8p1QSohWxChKhBP/0xTJMmnP6wbE23uYnHArb3AIgBdUOsHHModn7KaoSVfq6w7XLzTnbcvhY1y3y6JbJch88r/2HQLV9f8TLxkkxFgPKk0+cpJHhPzyPyusNsHOW4Pd+WuKrj24rsR1+oj+qxso1jITCm4Ebykjc+Ch4w4s5P8O0RUBlbdK+DZddty+XO5FoTs8+TWxkoDs2xqEctZKmYCQHyI4ryh3FZ/CafYWF4grvVOiPLjp7mH5ofbeyihW9/EWkxO3xU8m530tQoSZbl9TAq20B2AfW58WIRPZw/Ues1DCS3A7J8O5EO1o7la/DJp4kxb4/i4QcvFzYHi/zhEX2lKiWdlg4+uSw6+TofLHmppiEOoBqkQHxKKQjltaiDusmNggOW3GX+eOh1L3/5kL5R6hKjvsrnaXHqpzaJNwbpq68Aw5ayIos9xG/DzK+3NQZm3kIMk5FdQqGgoXqIV3CPv71Aemlj1ixkDpmyerKMqP9DpjDNnTDla3ufbd5605S0gozytVf6opaBL4bPvLzW1L+uMbFAx89KQO73+XnBc5g2YwAXWKPBrWVP7/VsV+N/u4vOfWDZJcJuDbhLPgo/+LugmMhmV8ce6mmwYAaaHGmEfR6LUWVe33sgs0OETRCgg1rcuXuhUeTGQVWdm22WLx0siolAYS8EK/MQ4mshPqK2yLtWtV7fGFNQmqBCnzvbYGNE6MBazi6ONNvl3oPUr33GKE70hT7/iX+wrFkaqL48zMZudirgPR8+ezf0zs2/Dd3J8iQ12XLRGZxyDBbDwQq1bxy9BQugmyI1rJ11rkBTYRe
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2E8AABBryVah8uZ6ERcGgEBAQEBAgEBAQEIAQEBAYJsgiQnB4N4iiCOeoF9iHSODYFSQwqCAYM6AhqFGj8YAQEBAQEBAQEBAQIQAQEBCgsJCCgvgjgkAQ5LIQUyAQEBAQEBAQEBAQEBAQEBAQEBFwI9EwIYAQEBAwEjEQwfGgEEBwQCAQgOAwQBAQMCBhkEAwICAh8RFAEICAIEARIIigIDDQgBqACCJ4MQhCsNgxgBAQEBAQEBAQEBAQEBAQEBAQEBFwiBD4I4gTZUgVeBaIMrgmuCIBiDEzGCMqI0NwYCkBWYUI07iGUCBAIEBQIagTofggdvgniCUhAMGYFOeIdPKoEJgRQBAQE
X-IPAS-Result: A2E8AABBryVah8uZ6ERcGgEBAQEBAgEBAQEIAQEBAYJsgiQnB4N4iiCOeoF9iHSODYFSQwqCAYM6AhqFGj8YAQEBAQEBAQEBAQIQAQEBCgsJCCgvgjgkAQ5LIQUyAQEBAQEBAQEBAQEBAQEBAQEBFwI9EwIYAQEBAwEjEQwfGgEEBwQCAQgOAwQBAQMCBhkEAwICAh8RFAEICAIEARIIigIDDQgBqACCJ4MQhCsNgxgBAQEBAQEBAQEBAQEBAQEBAQEBFwiBD4I4gTZUgVeBaIMrgmuCIBiDEzGCMqI0NwYCkBWYUI07iGUCBAIEBQIagTofggdvgniCUhAMGYFOeIdPKoEJgRQBAQE
Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Dec 2017 14:19:41 -0600
From: "Black, David" <David.Black@dell.com>
Cc: tcpinc <tcpinc@ietf.org>, Kyle Rose <krose@krose.org>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, "Black, David" <David.Black@dell.com>
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2017 02:23:39 +0600
Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vB4KTBij008469 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Dec 2017 15:29:13 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com vB4KTBij008469
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1512419354; bh=2/6HdffGUeU1cEJUJAAChAfcLpU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=dnB7VFERHszgu5Dm7GHhJNp0E8kJirLApRPR/Rka4YdDxcEhqZMK3vR1VPItDimBz sb4gj1RGj3YjzeBMd7dtMpuEAc+rbuGS00nJLehGt6QCIdyI9ZKUr1l0Rtu6wUMdRr ngEpegPm9wc84MufAOs1VBHyLKdNQYzIWmV2hU/o=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com vB4KTBij008469
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd51.lss.emc.com (RSA Interceptor); Mon, 4 Dec 2017 15:29:04 -0500
Received: from MXHUB309.corp.emc.com (MXHUB309.corp.emc.com [10.146.3.35]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vB4KT3Af031513 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 4 Dec 2017 15:29:03 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB309.corp.emc.com ([10.146.3.35]) with mapi id 14.03.0352.000; Mon, 4 Dec 2017 15:29:02 -0500
To: Valery Smyslov <svanru@gmail.com>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [tcpinc] Resumption safety (was "Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)")
Thread-Index: AQHTaWeKaqBgAqiJTU6Vp2CkSB85m6Ms+8NAgADSxICAAJUEAIABIOEAgAJ1xICAAaVOQA==
Date: Mon, 04 Dec 2017 20:29:02 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362FDD6E73@MX307CL04.corp.emc.com>
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>
In-Reply-To: <B0FB25D40E23475C9259A4C204B327D2@chichi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.105.8.135]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: public, GIS Solicitation
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/NDMPnTZs1JWriARVlh-8VqnCf1k>
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: Mon, 04 Dec 2017 20:29:18 -0000

Hi Valery,

Thanks for contributing to the discussion.

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

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

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.

That said, Kyle has a point in that both the client and the server have to be involved for this problem to happen:

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

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

>> (Note that the situation in which a client suffers from the same VM
>> 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.

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

> -----Original Message-----
> From: Valery Smyslov [mailto:svanru@gmail.com]
> Sent: Sunday, December 3, 2017 8:43 AM
> To: Eric Rescorla <ekr@rtfm.com>
> Cc: Black, David <david.black@emc.com>; tcpinc <tcpinc@ietf.org>; Kyle
> Rose <krose@krose.org>; Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>
> Subject: Re: [tcpinc] Resumption safety (was "Eric Rescorla's Discuss on draft-
> ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)")
> 
> Hi Eric,
> 
> > > 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.
> >
> >
> > 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.
> 
>