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

Kyle Rose <krose@krose.org> Mon, 11 December 2017 19:01 UTC

Return-Path: <krose@krose.org>
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 B5D4412726E for <tcpinc@ietfa.amsl.com>; Mon, 11 Dec 2017 11:01:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 mJqDKWOZr66D for <tcpinc@ietfa.amsl.com>; Mon, 11 Dec 2017 11:01:50 -0800 (PST)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 94BDF126D73 for <tcpinc@ietf.org>; Mon, 11 Dec 2017 11:01:50 -0800 (PST)
Received: by mail-qt0-x234.google.com with SMTP id a16so41277956qtj.3 for <tcpinc@ietf.org>; Mon, 11 Dec 2017 11:01:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=g16KJSOFAZ7XsGCsJdpTDUPWWv2d58XczicL3EKDyGk=; b=GTxgsF4259aTu96xaTGXlgvWsaUaB0cd9iIAu/w41cXrPFN8lM3kcMhox4lXJWUZ4B GV7ama1uGEJEvn/DF9F9PArs1UqP1KRr/ywL/YMa586fTVc9+695cuTWOuQEWQ8iN/No T5/jjfPbwepK2K/hUfxtX/eku3FeGr2wKHjss=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=g16KJSOFAZ7XsGCsJdpTDUPWWv2d58XczicL3EKDyGk=; b=LUp+FhhckTDuNGk4NlHimEkLHlXwHsMuNkgEifbygxNeG21HjYziNrggidixfa7Coj ENaxUBOLQiTUh2bF1QfPIrduDBp6sZXsM3XvAbQaSmnzpWB1uraPz7CRUq6tWfzykm+W lzSNjuUsF8Hv+cF6MLAX35h4ab/z94qPkbNYBaNpvl9Qjay6+AKEwxox0+8hD9StU9Wo s8HdTqgl70K5aBWrC+ZZKRpsW5Spu40FRFfCIjOwnZgiW7/rcsqWEvJgzVt0atRaJypL daA+sy9a9kMtguSvF10uTSKFxKV/qDV9Sfn4eBf6kfDUErHuQz6XgTjpDM1K4HZOOSaJ 5WQQ==
X-Gm-Message-State: AKGB3mIOd83GxBFUAJgCTxZZjsYo5UQzIEgicrTbuGsaQpFJsV14LowD Lpq3QV5/3lboUuAYlmOR8wErDJTR/n6IU86pdqznww==
X-Google-Smtp-Source: ACJfBotNNrRBHi1KXiP53/xRRsC2JHlLqVWlLQeuU5/+Q7x9Q34UGhPD5XQAihW7udWAutV0+OTc+iGYniW/Dsb5XZU=
X-Received: by 10.200.49.166 with SMTP id h35mr1953750qte.293.1513018908661; Mon, 11 Dec 2017 11:01:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.195.1 with HTTP; Mon, 11 Dec 2017 11:01:48 -0800 (PST)
X-Originating-IP: [2001:4878:a000:3000:4062:9a1e:a20:4bf0]
In-Reply-To: <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> <CE03DB3D7B45C245BCA0D243277949362FDD6E73@MX307CL04.corp.emc.com>
From: Kyle Rose <krose@krose.org>
Date: Mon, 11 Dec 2017 14:01:48 -0500
Message-ID: <CAJU8_nW9fkn9E=NbKFZ3zy5uSY36WFqRcQpBYdyYuLwzAbqFHA@mail.gmail.com>
To: "Black, David" <David.Black@dell.com>
Cc: Valery Smyslov <svanru@gmail.com>, Eric Rescorla <ekr@rtfm.com>, tcpinc <tcpinc@ietf.org>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/Eyr0cHgRPC_uvAQ8al_Uz1hX7RE>
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, 11 Dec 2017 19:01:54 -0000

Apologies for the radio silence: I was completely hosed by Akamai's
annual tech summit last week. To resume the discussion:

On Mon, Dec 4, 2017 at 3:29 PM, Black, David <David.Black@dell.com>; wrote:
>> 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.

It's not clear that this will make its way into the entropy pool
before use unless the hypervisor and guest kernel have some explicit
interaction to re-seed the entropy pool before resumption. I think
Valery and I agree on the danger here, and on the hopelessness of the
case in which both endpoints are VM clones without such explicit
support.

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

In the absence of on-path state (e.g., connection-tracking NATs), all
state related to a TCP connection exists on the endpoints. Thus, you
still end up in this scenario unless the kernel times out the
connection preemptively upon resumption after a sufficient delay,
something I am fairly confident would *not* always happen based upon
my experience resuming keepalive-free connections after a half hour or
more.

> Independent of why a TCP connection dropped, tcpcrypt resumption from there would be more robust if it injected fresh nonces and new entropy.

Fresh nonces are a function of many things, implementation-defined.
Timestamp would presumably be sufficient to avoid most problems here.
Better still (avoiding clock-handling and time synchronization errors)
would be fresh entropy injected prior to VM resumption. Both are
really outside the scope of the guest's control: I can always
construct a situation in which a system would send different data with
the same key and nonce. That said, I think the discussion here is
about making the protocol *able* to take advantage of newly-injected
entropy, which currently it is not. And on that point, I agree with
Ekr. Fresh nonces from both the client and server, along with support
from the VM infrastructure to make sure those nonces are generated
from fresh entropy, eliminates all but the most contrived scenarios.

Kyle