[tcpinc] Making ECDHE-Curve25519 the only MTI for tcpcrypt (RE: Last Call: <draft-ietf-tcpinc-tcpcrypt-07.txt> (Cryptographic protection of TCP Streams (tcpcrypt)) to Experimental RFC)
"Black, David" <David.Black@dell.com> Tue, 17 October 2017 23:18 UTC
Return-Path: <David.Black@dell.com>
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 245C6132620; Tue, 17 Oct 2017 16:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=Q7dwHH1y; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=MVyiUDrO
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 SJQF2ls5M4DP; Tue, 17 Oct 2017 16:18:24 -0700 (PDT)
Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 1338413247A; Tue, 17 Oct 2017 16:18:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1508282304; x=1539818304; h=from:cc:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ShJdxfQdDmp5S/s+3W9BMp95Kp3UGnBwPwwWpF9Qq8c=; b=Q7dwHH1yaFsU2t2tvpPkE4rV80JYPzDL2ucBWtHa+CZ3BnineqINWInX TD5gfyO7VqYVenZRRzdH3jIvAfjtsLE9bED00lK1mLDDQWZqtK42kgq94 ehqf7fVXnQomCeb8JSbVROcuiKHjeWH4jl/YeP+1wPTgUfAlQlAG6wY2v Y=;
Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Oct 2017 18:18:23 -0500
From: "Black, David" <David.Black@dell.com>
Cc: tcpinc <tcpinc@ietf.org>, "Black, David" <David.Black@dell.com>
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2017 05:18:22 +0600
Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v9HNIKwe014968 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Oct 2017 19:18:22 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v9HNIKwe014968
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1508282302; bh=VGAasZQW7ts8A5DpiaYoBoRNEPg=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=MVyiUDrO8KVxTwGeOn2U1zDjOzx7fCE/1AmhWxed55txruKXaxyYMWsoZ00Iglu1C dTocz0050zdj42hqWRnxyO7xkFfl2TcTYrysTatMjPNWQ0s4CRc/9DzvFri7KxGTMF mHL3EYqUGqgmc7mfCK/8W4qTTyco0ABq1SgsU32w=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v9HNIKwe014968
Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd56.lss.emc.com (RSA Interceptor); Tue, 17 Oct 2017 19:17:52 -0400
Received: from MXHUB311.corp.emc.com (MXHUB311.corp.emc.com [10.146.3.89]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v9HNI6UJ006480 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 17 Oct 2017 19:18:06 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB311.corp.emc.com ([10.146.3.89]) with mapi id 14.03.0352.000; Tue, 17 Oct 2017 19:18:05 -0400
To: "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: Making ECDHE-Curve25519 the only MTI for tcpcrypt (RE: Last Call: <draft-ietf-tcpinc-tcpcrypt-07.txt> (Cryptographic protection of TCP Streams (tcpcrypt)) to Experimental RFC)
Thread-Index: AdNHnixK1MfUEHDyRxisjUupN4sYkQ==
Date: Tue, 17 Oct 2017 23:18:05 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362FCE3C59@MX307CL04.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.44.138]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/mOhV-7BVPu5yA3HqQ7mTT78fKGY>
Subject: [tcpinc] Making ECDHE-Curve25519 the only MTI for tcpcrypt (RE: Last Call: <draft-ietf-tcpinc-tcpcrypt-07.txt> (Cryptographic protection of TCP Streams (tcpcrypt)) to Experimental RFC)
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, 17 Oct 2017 23:18:26 -0000
The message forwarded below suggests that ECDHE-Curve25519 should be the only mandatory to implement (MTI) key agreement algorithm for tcpcrypt instead of requiring both ECDHE-P256 and ECDHE-P521. As a tcpinc WG chair, I'm forwarding this message to the IETF list as an IETF Last Call comment on this draft. Additional messages on the tcpinc list indicate support of this change from: - ianG (https://www.ietf.org/mail-archive/web/tcpinc/current/msg01343.html) - some of the draft authors (https://www.ietf.org/mail-archive/web/tcpinc/current/msg01342.html, https://www.ietf.org/mail-archive/web/tcpinc/current/msg01344.html) - the draft shepherd (https://www.ietf.org/mail-archive/web/tcpinc/current/msg01346.html) There has been no objection to this change so far - I'll watch for any further comments on the tcpinc list and forward any that don't already cc: the IETF list. Thanks, --David -----Original Message----- From: Tcpinc [mailto:tcpinc-bounces@ietf.org] On Behalf Of Gregorio Guidi Sent: Saturday, October 7, 2017 7:34 PM To: Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> Cc: David Mazieres expires 2017-12-29 PST <mazieres-b6y844gfkp899wcr7iwrxxztue@temporary-address.scs.stanford.edu>; tcpinc <tcpinc@ietf.org>; Daniel B Giffin <dbg@scs.stanford.edu> Subject: Re: [tcpinc] new drafts of TCP-ENO and tcpcrypt On 10/05/2017 01:42 PM, Mirja Kuehlewind (IETF) wrote: > Hi Daniel, hi all, > > thanks for all the work and changes. I just realized that I didn’t answer (yet) David’s last mail but the resolution now is fine. Thanks for the additional explanation! > > I’ve just requested IETF last call for both docs and put them on the telechat agenda for Oct 26. Likely there will be more comments from different directorates and the ADs and we potentially need another version then (just before the telechat or right after) but I’m not expecting any real issues. > > Thanks for the good work! > Mirja Hi all, Having followed the standardization of tcpcrypt on the tpcinc mailing list (as a passive observer), I wanted to check with you on a point that was not heavily discussed as far as I can see: the choice of the "mandatory to implement" (MTI) algorithms for key agreement. I explain my concern: tcpcrypt defines ECDHE-P256 and ECDHE-P521 as MTI algorithms, however these are based on the NIST elliptic curves that - while widely deployed and offering great security - have been subject to some criticism in the last years. You have probably seen many times the arguments raised against them. The following is a good summary: https://cr.yp.to/newelliptic/nistecc-20160106.pdf Not all arguments in the paper are relevant for the key agreement used in tcpcrypt, but many are. It is especially relevant the fact that tcpcrypt is "tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable". This means that the usual path to integrate P256 and P521, that is, linking to a big library such as OpenSSL, will be impractical in many cases. This opens up the potential pitfalls described in the paper, since new low-level code will be needed to integrate the primitives into the TCP stack. From a more detached point of view, the choice of ECDHE-P256 and ECDHE-P521 is a "conservative" one that is not likely to do any damage in practice. But still, I would say that as of 2017, the rough consensus is that the choice of the NIST curves does not reflect anymore the state of the art in the field, especially for new applications. Looking back at the archives, I can find an exchange from last year on the topic: https://mailarchive.ietf.org/arch/msg/tcpinc/QWLophMkudMGU_X0_w_8YcRl910 Having ECDHE-Curve25519 and ECDHE-Curve448 as MTI was suggested, but the lack of implementations for Curve448 was mentioned. Unfortunately this is still an issue: there are implementations available but no stable and well-proved implementation of Curve448 is there yet, as shown here: https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Supported_elliptic_curves Nonetheless, in the time passed since that exchange, the adoption of Curve25519 has consolidated further, so the option to have ECDHE-Curve25519 as the only MTI would not look so bad in my view. All in all, I feel that the current choice of algorithm could have a slight detrimental effect on the adoption of tcpcrypt, but how much is difficult to tell. I leave to you to judge whether this could be considered a valid concern or not. Thanks for all the work, Gregorio _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
- [tcpinc] Making ECDHE-Curve25519 the only MTI for… Black, David
- Re: [tcpinc] Making ECDHE-Curve25519 the only MTI… Denis Ovsienko
- Re: [tcpinc] Making ECDHE-Curve25519 the only MTI… Paul Wouters
- Re: [tcpinc] Making ECDHE-Curve25519 the only MTI… Black, David