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

Kyle Rose <krose@krose.org> Wed, 29 November 2017 23:12 UTC

Return-Path: <krose@krose.org>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AB5CA127866 for <tcpinc@ietfa.amsl.com>; Wed, 29 Nov 2017 15:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vBP5GKvb7373 for <tcpinc@ietfa.amsl.com>; Wed, 29 Nov 2017 15:12:24 -0800 (PST)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 BA0EA1274D2 for <tcpinc@ietf.org>; Wed, 29 Nov 2017 15:12:21 -0800 (PST)
Received: by mail-qt0-x233.google.com with SMTP id g10so6552332qtj.12 for <tcpinc@ietf.org>; Wed, 29 Nov 2017 15:12:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=VizvxO9k/yZ3jEB8JDz5rjhkFM7zZThwiK4/Inpu6RU=; b=bHPXlzJuZDnKONpATn47qmpbZkwhkPCHYnG/3us8OgMzWcL7eLxJnzu0Gpp+K0i78+ aRwPqMiLyJcLVPYThFiqltKAJhMcJAPa6yfZwG5z/TuOeaY1JiN+YVWrAMaFHjgo4Gsl Vvk2MKvMOUgDVzNJj9C8wmt8lMETxrnEibSjE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=VizvxO9k/yZ3jEB8JDz5rjhkFM7zZThwiK4/Inpu6RU=; b=X1SMU+2oG6UlXQA7T/pxmwk9E44kVQNz7bjYVs15AuracTJl+0VmTyLYtlnQL93yo/ ODd7Yt7uuu5aLeihBLbHHjkxhwjylYt7kO1GXMtjGwghWDZ/zWSpwq3X/B6bnDYynj+a M736FHc63PzxXVv0VZvjas7deMLaRKUUVxSGH7MTR2dl3EnKJ6h4Xe9KhlXpKDRqTpGe hvSTWrGKHUUmgEHS/nBnC/h3ljllayN9quujGVJX57oE4CQAm6K+DY19Ak5/zS9BJAD+ AO6sI2sRV/17qH4DUxI1yOstzXZaFl+dI9HFBdaaQePiMb4W2NfOP5rWvpn1Ebi5OLnF LEqQ==
X-Gm-Message-State: AKGB3mK3R0gLE8wPU7HeSkoU9xp3H8Uh1oGQymAiJHIjulkGJJFgQTkU MPMPBFYHpc77v0bx2e6qAKmVaiWGzw2lcEsfJyd4HtBHbfI=
X-Google-Smtp-Source: AGs4zMYEFpIUe/jVrLxHsze7cMtnKBXBh4Ys7DkDrBXzYllHuTILLDpSFHwipdyErtAWRx+q1JCEd9SNEVJ4q1Evg8A=
X-Received: by with SMTP id a7mr878620qtk.206.1511997140445; Wed, 29 Nov 2017 15:12:20 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 29 Nov 2017 15:12:20 -0800 (PST)
X-Originating-IP: [2001:4878:a000:3000:f0c7:5314:ee90:312e]
From: Kyle Rose <krose@krose.org>
Date: Wed, 29 Nov 2017 18:12:20 -0500
Message-ID: <CAJU8_nUUHbmFcPA2obo6q3dLqL1MGE2iKen-0EQ82re=+gtTfw@mail.gmail.com>
To: tcpinc <tcpinc@ietf.org>
Cc: Eric Rescorla <ekr@rtfm.com>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary="94eb2c0447c075445c055f27449f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/Sw5SixaDFyHQbcwuvXOgqDCkLxQ>
Subject: [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: Wed, 29 Nov 2017 23:12:26 -0000

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

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.