Re: [tcpinc] new drafts of TCP-ENO and tcpcrypt

dm-list-tcpcrypt@scs.stanford.edu Sun, 08 October 2017 04:56 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5FF13455C for <tcpinc@ietfa.amsl.com>; Sat, 7 Oct 2017 21:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 7ZUKUm9Ev-Eu for <tcpinc@ietfa.amsl.com>; Sat, 7 Oct 2017 21:56:49 -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 3FA641321C7 for <tcpinc@ietf.org>; Sat, 7 Oct 2017 21:56:49 -0700 (PDT)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v984umii040312; Sat, 7 Oct 2017 21:56:48 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v984ulpg060116; Sat, 7 Oct 2017 21:56:47 -0700 (PDT)
From: dm-list-tcpcrypt@scs.stanford.edu
To: Gregorio Guidi <greg_g@posteo.net>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Cc: Daniel B Giffin <dbg@scs.stanford.edu>, tcpinc <tcpinc@ietf.org>
In-Reply-To: <e2ae6028-6ed2-c547-2a1f-f3c170b0fb89@posteo.net>
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>
Reply-To: David Mazieres expires 2018-01-05 PST <mazieres-6hdfzgw6w3qzfz6tfuvy9fuge6@temporary-address.scs.stanford.edu>
Date: Sat, 07 Oct 2017 21:56:47 -0700
Message-ID: <87h8va1blc.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/BpEWeV3ltoSmDTqvqMXxNBpCGFY>
Subject: Re: [tcpinc] new drafts of TCP-ENO and 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: Sun, 08 Oct 2017 04:56:50 -0000

Gregorio Guidi <greg_g@posteo.net> writes:

> Having followed the standardization of tcpcrypt on the tpcinc mailing
> list (as a passive observer), I wanted to check with you on a point
> that was not heavily discussed as far as I can see: the choice of the
> "mandatory to implement" (MTI) algorithms for key agreement.
>
> I explain my concern: tcpcrypt defines ECDHE-P256 and ECDHE-P521 as MTI 
> algorithms, however these are based on the NIST elliptic curves that - 
> while widely deployed and offering great security - have been subject to 
> some criticism in the last years. You have probably seen many times the 
> arguments raised against them. The following is a good summary:

You raise a reasonable question.  There are a lot of trade-offs.  On one
hand, it would be nice to have a scheme with longer than 32-byte keys.
But then it's probably easier to find a P521 ECDHE implementation to
cram into the kernel than a curve448.  Should we have Curve25519 and
P521?  But whatever library supports P521 probably also supports P256,
so it's less work to do both of those.  Also, the best reference for the
two Edwards curves is an informational RFC, vs. IEEE and NIST standards
for the other ones.

One good thing is that MTI is almost irrelevant given the way the
different public key algorithms have been assigned their own ENO TEP
Identifiers.  It's almost as if this document is defining four separate
protocols that just happen to be able to share 99% of the code.  But of
course we need to encourage people to implement the same algorithms
initially...

David