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

Gregorio Guidi <greg_g@posteo.net> Wed, 25 October 2017 07:43 UTC

Return-Path: <greg_g@posteo.net>
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 EC27F13A5A3 for <tcpinc@ietfa.amsl.com>; Wed, 25 Oct 2017 00:43:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] 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 N5YYVWG0R02Z for <tcpinc@ietfa.amsl.com>; Wed, 25 Oct 2017 00:43:38 -0700 (PDT)
Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) (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 7D589139436 for <tcpinc@ietf.org>; Wed, 25 Oct 2017 00:43:38 -0700 (PDT)
Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 433C220C6C for <tcpinc@ietf.org>; Wed, 25 Oct 2017 09:43:35 +0200 (CEST)
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3yMMZZ2Pd6z10Jm; Wed, 25 Oct 2017 09:43:33 +0200 (CEST)
Date: Wed, 25 Oct 2017 09:43:30 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <520c7480-a978-a394-e60a-72ae81f98fb0@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> <87she8h06i.fsf@ta.scs.stanford.edu> <520c7480-a978-a394-e60a-72ae81f98fb0@iang.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: iang <iang@iang.org>, David Mazieres expires 2018-01-22 PST <mazieres-44wmtanvfuzkt4ia26f5spwmtw@temporary-address.scs.stanford.edu>, tcpinc@ietf.org
From: Gregorio Guidi <greg_g@posteo.net>
Message-ID: <905686C9-FBF8-4DD8-80B1-A7125B65BA15@posteo.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/RNp8AkTGsy-cuUB9-DTWlDU1O-w>
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: Wed, 25 Oct 2017 07:43:41 -0000


On October 24, 2017 11:19:33 PM CEST, iang <iang@iang.org> wrote:
>On 24/10/2017 20:26, David Mazieres wrote:
>
>> 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?
>
>
>Yes - makes sense - after this earlier thread I went back and read the 
>earlier comments.  It's what it takes.  Let's do it.
>
>iang

Agreed, the plan looks excellent to me.

Thanks a lot for all your efforts, 
Gregorio