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

iang <iang@iang.org> Tue, 24 October 2017 21:19 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 E978613A044 for <tcpinc@ietfa.amsl.com>; Tue, 24 Oct 2017 14:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 KgLJUTYBfsZ3 for <tcpinc@ietfa.amsl.com>; Tue, 24 Oct 2017 14:19:37 -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 6385213A344 for <tcpinc@ietf.org>; Tue, 24 Oct 2017 14:19:37 -0700 (PDT)
Received: from virulha.pair.com (localhost [127.0.0.1]) by virulha.pair.com (Postfix) with ESMTP id 476646D4EE; Tue, 24 Oct 2017 17:19:35 -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 8CEB06D4EB; Tue, 24 Oct 2017 17:19:34 -0400 (EDT)
To: David Mazieres expires 2018-01-22 PST <mazieres-44wmtanvfuzkt4ia26f5spwmtw@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> <6ae26cd4-2fb3-d571-8189-083120ec3729@iang.org> <87she8h06i.fsf@ta.scs.stanford.edu>
From: iang <iang@iang.org>
Message-ID: <520c7480-a978-a394-e60a-72ae81f98fb0@iang.org>
Date: Tue, 24 Oct 2017 23:19:33 +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: <87she8h06i.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/MbRNfnD7c3gCgjopDGWmmFYSgzM>
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 21:19:39 -0000

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