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

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Tue, 24 October 2017 18:26 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 390FE139567 for <tcpinc@ietfa.amsl.com>; Tue, 24 Oct 2017 11:26:35 -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 nSp19jICjATt for <tcpinc@ietfa.amsl.com>; Tue, 24 Oct 2017 11:26:34 -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 7DA4A1386A1 for <tcpinc@ietf.org>; Tue, 24 Oct 2017 11:26:34 -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 v9OIQWaP090184; Tue, 24 Oct 2017 11:26:32 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v9OIQUQI093482; Tue, 24 Oct 2017 11:26:30 -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: <6ae26cd4-2fb3-d571-8189-083120ec3729@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> <87h8uylfgk.fsf@ta.scs.stanford.edu> <87h8upk3we.fsf@ta.scs.stanford.edu> <6ae26cd4-2fb3-d571-8189-083120ec3729@iang.org>
Reply-To: David Mazieres expires 2018-01-22 PST <mazieres-44wmtanvfuzkt4ia26f5spwmtw@temporary-address.scs.stanford.edu>
Date: Tue, 24 Oct 2017 11:26:29 -0700
Message-ID: <87she8h06i.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/DgTh3zl4_ko53FDj7EtECznh2Sk>
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 18:26:35 -0000

iang <iang@iang.org> writes:

> 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.

Point taken.  However, the rationale behind the SHOULD is that:

A) The ADs were slightly uncomfortable with only one MTI, though not
   adamantly opposed to it, and

B) People really should implement Curve448, so why not write the
   document in such a way as to encourage it?

So the SHOULD is a nice compromise between one MTI and two MTIs, where
sure we only have one MTI, but we've encouraged people who want a second
key exchange algorithm to converge on the same one.  This way down the
line, when Curve448 is widely supported in software, people will be more
likely to include it.

Make sense?

David