[tcpinc] Final (I hope) tcpcrypt draft published

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Thu, 06 September 2018 17:14 UTC

Return-Path: <dm-list-tcpcrypt@scs.stanford.edu>
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 2F740130E8A for <tcpinc@ietfa.amsl.com>; Thu, 6 Sep 2018 10:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GYGlPaQ4QdG0 for <tcpinc@ietfa.amsl.com>; Thu, 6 Sep 2018 10:14:52 -0700 (PDT)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 D45BD1277C8 for <tcpinc@ietf.org>; Thu, 6 Sep 2018 10:14:51 -0700 (PDT)
Received: from market.scs.stanford.edu (localhost []) by market.scs.stanford.edu ( with ESMTP id w86HEpZu063636; Thu, 6 Sep 2018 10:14:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1536254091; bh=SGm/C26FRc4vcgzABcVPvKsNadPINZm2EnunNDTwMqY=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=dpyVg4JjjzZAIAnA2gRw5scEqfUNR6CscKAOYtJ62VF3EmyLMBDnceiHceZPVhSed hfbcJuJnP/xos4pL0G6dm9eYnsTh+RZ9+aFLTsMo+1rZGC0gXE3UnckG4mEpQBexmK LihudXwVA1+eztDSMCzwVAevtrPAT0DOPOie1VYw=
Received: (from dm@localhost) by market.scs.stanford.edu ( id w86HEpIi035953; Thu, 6 Sep 2018 10:14:51 -0700 (PDT)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: tcpinc <tcpinc@ietf.org>
Cc: Eric Rescorla <ekr@rtfm.com>
Reply-To: David Mazieres expires 2018-12-05 PST <mazieres-7w3j7q2jygrvn9a5283scceeqw@temporary-address.scs.stanford.edu>
Date: Thu, 06 Sep 2018 10:14:51 -0700
Message-ID: <87y3cebl9w.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/Lcc6ZV2zYpfMvU1qO4jHshKbZt0>
Subject: [tcpinc] Final (I hope) tcpcrypt draft published
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.29
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, 06 Sep 2018 17:14:53 -0000

I've posted what I hope is a final draft of the tcpcrypt spec, at the
usual place:


The main open issue was the length of the resumption nonce, and the
concern that recommending 4 bytes was not a good length, so we have
increased it to 8 for cases where 0 is not safe.  Here is the particular
paragraph to focus on:

   The resumption nonce MUST have a minimum length of zero bytes and
   maximum length of eight bytes.  The value MUST be chosen randomly or
   using a mechanism that guarantees uniqueness even in the face of
   virtual machine cloning or other re-execution of the same session.
   An attacker who can force either side of a connection to reuse a
   session secret with the same nonce will completely break the security
   of tcpcrypt.  Reuse of session secrets is possible in the event of
   virtual machine cloning or reuse of system-level hibernation state.
   Implementations SHOULD provide an API through which to set the
   resumption nonce length, and MUST default to eight bytes if they
   cannot prohibit the reuse of session secrets.