[tcpinc] Making ECDHE-Curve25519 the only MTI for tcpcrypt

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Tue, 17 October 2017 01:40 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 1E4AD132D53 for <tcpinc@ietfa.amsl.com>; Mon, 16 Oct 2017 18:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Rnqon2Ms6IAG for <tcpinc@ietfa.amsl.com>; Mon, 16 Oct 2017 18:40:17 -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 657C9132949 for <tcpinc@ietf.org>; Mon, 16 Oct 2017 18:40:17 -0700 (PDT)
Received: from market.scs.stanford.edu (localhost []) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v9H1eF71076983; Mon, 16 Oct 2017 18:40:15 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v9H1eDT5017262; Mon, 16 Oct 2017 18:40:13 -0700 (PDT)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: iang <iang@iang.org>, Gregorio Guidi <greg_g@posteo.net>, tcpinc@ietf.org
In-Reply-To: <3879588f-d5ef-43c9-9d2c-7fe9c2657709@iang.org>
References: <D38E22E9-FBB6-40D1-BF85-D5A77F5C2365@kuehlewind.net> <20170830223758.GA73969@scs.stanford.edu> <3a8ac0e0-cd41-57c8-85a4-79c5f179385f@kuehlewind.net> <20170929203434.GA73214@scs.stanford.edu> <D78092B0-4C01-47D6-9B5D-9DB1DA5EFA83@kuehlewind.net> <877ewgrtp8.fsf@ta.scs.stanford.edu> <20171004233140.GB84701@scs.stanford.edu> <BDB8460A-E193-4C9C-BCBA-99B805F93D0A@kuehlewind.net> <e2ae6028-6ed2-c547-2a1f-f3c170b0fb89@posteo.net> <3879588f-d5ef-43c9-9d2c-7fe9c2657709@iang.org>
Reply-To: David Mazieres expires 2018-01-14 PST <mazieres-ddragqirgwht7ezx2d39a3jw72@temporary-address.scs.stanford.edu>
Date: Mon, 16 Oct 2017 18:40:11 -0700
Message-ID: <87h8uylfgk.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/-_KcLfSMb2MWvHjPOdtjasgvVRU>
Subject: [tcpinc] Making ECDHE-Curve25519 the only MTI for tcpcrypt
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: Tue, 17 Oct 2017 01:40:18 -0000

Some of the tcpcrypt authors have talked over the proposal to make
ECDHE-Curve25519 MTI instead of P256 and P521.  We think this argment
has merit if it won't hamper standardization and adoption of the
protocol at this juncture.

One of the original motivations for making P256 MTI was that if P256 is
broken, then the world is in some trouble anyway.  A counter-argument
might be that such trouble could be slightly reduced if people could
turn on tcpcrypt with ECDHE-Curve25519.  Further tipping the balance in
favor of ECDHE-Curve25519 is the fact that it's probably easier to find
safe implementations of Curve25519 than P256 to embed in the kernel.
Certainly Curve25519 is a lot more widely used now than when we started
the tcpcrypt project, making it not unreasonable to revisit the

Question one is whether there's anyone in the working group who thinks
it would be a bad idea to make this change--i.e., to have a single MTI
algorithm, namely ECDHE-Curve25519.  If so, please speak up.

Question two, if no one object to this change and some people want to
see it, is whether it is now too late to make this change without
jeopardizing the RFC.  Can we still make such a change in last call?
It's obviously not a lot of text to change, but a fairly big semantic
change.  We'd appreciate guidance on this question from people with more
IETF experience.