Re: [tcpinc] Making ECDHE-Curve25519 the only MTI for tcpcrypt

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Wed, 18 October 2017 07:02 UTC

Return-Path: <ietf@kuehlewind.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 670B613219E for <tcpinc@ietfa.amsl.com>; Wed, 18 Oct 2017 00:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 ZYliNJJBV2aU for <tcpinc@ietfa.amsl.com>; Wed, 18 Oct 2017 00:02:47 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11DE127517 for <tcpinc@ietf.org>; Wed, 18 Oct 2017 00:02:46 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=OhxH7SOWpa6YMfMrzhOSE0fdiPIelB7gipPcrgLidZnGFwD5xhv53HDdF4HtjRZWWWuHeg1i6rz++ROqEYt8dDoJPaYxbXXkeM56xqb6gRwVhkqnPoCEMIdZkUhjhoDaGi+1ocOzHyGa2QHjfV4fYt0CwwcVo0yUar1XchsHY7w=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 18419 invoked from network); 18 Oct 2017 09:02:44 +0200
Received: from 178-83-155-34.dynamic.hispeed.ch (HELO ?192.168.220.145?) (178.83.155.34) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Oct 2017 09:02:44 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FCE3BED@MX307CL04.corp.emc.com>
Date: Wed, 18 Oct 2017 09:02:44 +0200
Cc: Kyle Rose <krose@krose.org>, David Mazieres expires 2018-01-14 PST <mazieres-ddragqirgwht7ezx2d39a3jw72@temporary-address.scs.stanford.edu>, tcpinc <tcpinc@ietf.org>, Gregorio Guidi <greg_g@posteo.net>, ianG <iang@iang.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8817380F-9872-4854-82DC-955AD3E633C1@kuehlewind.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> <3879588f-d5ef-43c9-9d2c-7fe9c2657709@iang.org> <87h8uylfgk.fsf@ta.scs.stanford.edu> <CAJU8_nVAw3CJjaV9saKMit3rhvdWaUTZ090vMX3v0jLbAE0CQA@mail.gmail.com> <489870a3-58d1-eb2c-5a57-f9cf9b7f8daa@kuehlewind.net> <CE03DB3D7B45C245BCA0D243277949362FCE3BED@MX307CL04.corp.emc.com>
To: "Black, David" <David.Black@dell.com>
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20171018070244.18410.3071@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/NJMTnDrsqAVZmGHJAunpOzhry9E>
Subject: Re: [tcpinc] Making ECDHE-Curve25519 the only MTI for 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: Wed, 18 Oct 2017 07:02:49 -0000

Sounds like a good plan. Thanks!

> Am 18.10.2017 um 00:58 schrieb Black, David <David.Black@dell.com>:
> 
>>> Mirja and David Black: can you provide guidance here?
>> 
>> Yes, if the change is the right thing to do, you should do it. If there is
>> agreement in the working group to make this change, I don't think we need
>> another working group last call (but that's actually in the judgment of the
>> chairs). So the only question would be, do we need another IETF last call for
>> this? However, the IETF last call is still running. Therefore I would like to
>> ask you to bring attention about this change to the ietf@ietf.org mail list,
> 
> I concur, and I will go do that by forwarding Gregorio's message to the IETF
> list, providing a pointer to ianG's message of support and indicating that the
> draft authors concur, also with a message pointer.  My rationale for forwarding
> Gregorio's message is that it provides solid answers to the inevitable "why is
> this change being made?" question both directly and in the form of a pointer
> to the extensive DJB & T. Lange implementation-oriented critique of the
> NIST curves.
> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: Tcpinc [mailto:tcpinc-bounces@ietf.org] On Behalf Of Mirja Kühlewind
>> Sent: Tuesday, October 17, 2017 10:43 AM
>> To: Kyle Rose <krose@krose.org>; David Mazieres expires 2018-01-14 PST
>> <mazieres-ddragqirgwht7ezx2d39a3jw72@temporary-
>> address.scs.stanford.edu>; Black, David <david.black@emc.com>
>> Cc: tcpinc <tcpinc@ietf.org>; Gregorio Guidi <greg_g@posteo.net>; ianG
>> <iang@iang.org>
>> Subject: Re: [tcpinc] Making ECDHE-Curve25519 the only MTI for tcpcrypt
>> 
>> Hi David, hi Kyle, hi all,
>> 
>> On 17.10.2017 16:13, Kyle Rose wrote:
>>>    Question two, if no one object to this change and some people want to
>>>    see it, is whether it is now too late to make this change without
>>>    jeopardizing the RFC.  Can we still make such a change in last call?
>>>    It's obviously not a lot of text to change, but a fairly big semantic
>>>    change.  We'd appreciate guidance on this question from people with more
>>>    IETF experience.
>>> 
>>> 
>>> Mirja and David Black: can you provide guidance here?
>> 
>> Yes, if the change is the right thing to do, you should do it. If there is
>> agreement in the working group to make this change, I don't think we need
>> another working group last call (but that's actually in the judgment of the
>> chairs). So the only question would be, do we need another IETF last call for
>> this? However, the IETF last call is still running. Therefore I would like to
>> ask you to bring attention about this change to the ietf@ietf.org mail list,
>> meaning one of the authors could reply to the IETF last call email and
>> explain that and why this change is planned. And then we can probably handle
>> this basically like a last call comment and just update the draft
>> respectively. In this case it would also be good if the authors could submit
>> the updated version right at the end of the IETF last call, so this Friday,
>> such that the ADs could review the updated version for the telechat next
>> week. Would that be possible?
>> 
>> Mirja
>> 
>> _______________________________________________
>> Tcpinc mailing list
>> Tcpinc@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpinc