Re: [tcpinc] tcpcrypt MTI key exchange (speak now or forever hold your peace...)

iang <iang@iang.org> Tue, 24 October 2017 10:41 UTC

Return-Path: <iang@iang.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 C3F8013F6F6 for <tcpinc@ietfa.amsl.com>; Tue, 24 Oct 2017 03:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 INHTfIlnZgaG for <tcpinc@ietfa.amsl.com>; Tue, 24 Oct 2017 03:41:55 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (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 6311213DD35 for <tcpinc@ietf.org>; Tue, 24 Oct 2017 03:41:55 -0700 (PDT)
Received: from virulha.pair.com (localhost [127.0.0.1]) by virulha.pair.com (Postfix) with ESMTP id DCC376D547; Tue, 24 Oct 2017 06:41:53 -0400 (EDT)
Received: from plata.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id 34BE66D546; Tue, 24 Oct 2017 06:41:53 -0400 (EDT)
To: David Mazieres expires 2018-01-21 PST <mazieres-m3w8362yb4cc5hherzqjdkknf6@temporary-address.scs.stanford.edu>, Gregorio Guidi <greg_g@posteo.net>, tcpinc@ietf.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> <87h8uylfgk.fsf@ta.scs.stanford.edu> <87h8upk3we.fsf@ta.scs.stanford.edu>
From: iang <iang@iang.org>
Message-ID: <6ae26cd4-2fb3-d571-8189-083120ec3729@iang.org>
Date: Tue, 24 Oct 2017 12:41:51 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <87h8upk3we.fsf@ta.scs.stanford.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/39mycgvpF_rg6O-H18ZZDbTqNRs>
Subject: Re: [tcpinc] tcpcrypt MTI key exchange (speak now or forever hold your peace...)
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, 24 Oct 2017 10:41:57 -0000

On 23/10/2017 22:25, David Mazieres wrote:

> We are considering the following proposal for MTI key exchange protocols
> in tcpcrypt:
>
>    1. Implementations MUST support Curve25519.
>
>    2. Implementations SHOULD support Curve448 to the extent that suitable
>       implementations are available.
>
>    3. Implementations MAY support P256 and P521 (particularly since
>       hardware implementations are widely available for the former).
>
> (Obviously whatever algorithms are supported can always be disabled by
> configuration--this is just about what the software MUST support, not
> what everyone must use.)
>
> The security ADs have not 100% signed off on this approach yet, but seem
> receptive to it.  However, given the timeline, we would like to
> parallelize things and find out *now* if there are any objections to the
> proposal.  Based on the working group discussion, I think everyone will
> be happy, so please speak up now if you object.
>
> Thanks,
> David

In general +1.

The only quibble I would have is that 2. Curve448 should be a MAY. 
Firstly, a caveated SHOULD becomes a MAY, at some level of 
approximation.  Secondly, if we manage to convince an enemy to crunch 
Curve25519 then we have won a great victory, and we can upgrade at our 
leisure with newer information.

But it is only a quibble - I wouldn't hold up any vote on this just 
because of an idle bar prediction on consequences.

iang