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

Kyle Rose <krose@krose.org> Fri, 01 December 2017 19:56 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 4FC08128B51 for <tcpinc@ietfa.amsl.com>; Fri, 1 Dec 2017 11:56:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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, 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 OsEGwZlEflzN for <tcpinc@ietfa.amsl.com>; Fri, 1 Dec 2017 11:56:25 -0800 (PST)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 63D64124D85 for <tcpinc@ietf.org>; Fri, 1 Dec 2017 11:56:25 -0800 (PST)
Received: by mail-qk0-x22b.google.com with SMTP id z203so14657554qkb.5 for <tcpinc@ietf.org>; Fri, 01 Dec 2017 11:56:25 -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; bh=LlMM6GMdnBBCvWU8lFhkzH6qHhljIPQwb4Qofb7KJDk=; b=NhmQcGASv9OFcXm1eYVIUdPFtKd51pjMh0e8JmsLnWkWcxU31R6fh3IabG0kG0hJ7p UiX2h11mKZuQ2vGEXKaOJe1X+rKnHMufd9yrycyiRWHAUqJou1Hy8VPxwL/yMgZTSAS8 E8n5LeXXDClyvMJabmze2fCqFnU/bFwwjvKG0=
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; bh=LlMM6GMdnBBCvWU8lFhkzH6qHhljIPQwb4Qofb7KJDk=; b=E1syAC1Ck7RuMHA6c8XV/EDHzjwej1O69TRsvJ+5ams5+Mksezx4WHZGLzEzGlgVK8 jE5YVPOid7SFL8l6QsJs97zMdNhMirddpL+WjCHlrXDR/j8D+HSY68bim5TwZz0c79Nc q6mmfAA6+TI3Q9vpHPVPjc9KmCuRptObktZFEqGaqAJL8gw8GXqcs3w+Wte/a9u4lugg I2PncRX597EZLemNce4hx0RPOEcqz+3Q9u7tTlYKnrQq5LAI6hSs7pmKfYosNjEPHymw 7WJ6qNWeo+IUcRdQZy1c73YtG+qbbHHbD70aTXAvTR2mFXv6mYBlvMuW5Mx+7UrPekuF 6RJw==
X-Gm-Message-State: AKGB3mIwLIevTZMUXKboaRg+4pd79KQ2HpZttfil6DwGc8aHinLzH2vK Xw5nb/4LPQIikNL6SVjivZK1atdDkA+veKOaMXl0gA==
X-Google-Smtp-Source: AGs4zMaC+GraJYT/OKfam29DmITSovBFX+8Cny9FCYuFb6hZd0+58DW0/U8I2DCHkPYYjviaIovWLP0AA/nZhe71vlk=
X-Received: by 10.55.5.149 with SMTP id 143mr9541139qkf.298.1512158184296; Fri, 01 Dec 2017 11:56:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.195.1 with HTTP; Fri, 1 Dec 2017 11:56:23 -0800 (PST)
X-Originating-IP: [2001:4878:a000:3000:2c15:beda:f806:c94a]
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FDAF297@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> <CE03DB3D7B45C245BCA0D243277949362FDAF297@MX307CL04.corp.emc.com>
From: Kyle Rose <krose@krose.org>
Date: Fri, 1 Dec 2017 14:56:23 -0500
Message-ID: <CAJU8_nWzJ-rZ9SKH+S-BnyzmGR_Q1zjZZz1r89Bi+HbG8t5XBA@mail.gmail.com>
To: "Black, David" <David.Black@dell.com>
Cc: Valery Smyslov <svanru@gmail.com>, tcpinc <tcpinc@ietf.org>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/YuIs9myDMF6E7AxgKHpZu--WFPc>
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: Fri, 01 Dec 2017 19:56:27 -0000

On Fri, Dec 1, 2017 at 9:48 AM, Black, David <David.Black@dell.com>; wrote:
>> 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.
>
> The actual situation is more subtle than that.  The VM is likely to be stored for long
> enough that TCP connections drop - if not, e.g.,  the VM is cloned and the clone
> runs immediately, that new VM likely has to be assigned a new IP address in order
> to not conflict with the existing VM, and that also drops TCP connections.
>
> In both cases, the security protocol resumes or restarts with a new TCP connection,
> providing an opportunity to inject entropy.  TLS injects entropy when it resumes, but
> the current tcpcrypt design does not.  If a restart happens, both protocols (obviously)
> use new entropy.

I'm not sure what you're trying to argue here. Assuming correct client
behavior, ss[i] will never be used twice, so we are necessarily
dealing with a situation in which the client is acting incorrectly.
Preventing fragility means ensuring we are not in a hazardous state,
i.e., that we are two or more uncorrelated failures away from
breakage.

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.

(Note that the situation in which a client suffers from the same VM
clone problem as the server is completely hopeless.)

Kyle