IETF Logo Mail Archive

Re: [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> Wed, 18 October 2017 22:41 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 A7FEF1321A1; Wed, 18 Oct 2017 15:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.5
X-Spam-Level:
X-Spam-Status: No, score=-5.5 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_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=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=lZhAgVJh; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=rsa.com header.b=dWHLr+qF
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 PilF7rcjKMMf; Wed, 18 Oct 2017 15:41:43 -0700 (PDT)
Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 E5DB3132705; Wed, 18 Oct 2017 15:41:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1508366502; x=1539902502; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GkKLy9Gn34ZIju6PKIYFduAbH/umFTXjO5snrDFnZIE=; b=lZhAgVJht4IkBC4FyWuFZ1j8q3eDb8dY7qta6GwNMyDCCFuJ6ZDKFwKT 9LbjbOMU9TxbdBwpLwT0fmsLVYTLQYOCsNw1vrdr6xijvaJfclXcYTeu0 yWnhJ+EMDH8GEfo+SnjV3DXXHuzvomqPR5vqzqDLypzSqptRbkAZ+JlMa E=;
Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2017 17:41:42 -0500
From: "Black, David" <David.Black@dell.com>
Cc: tcpinc <tcpinc@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "Black, David" <David.Black@dell.com>
Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2017 04:40:27 +0600
Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v9IMfclF011869 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Oct 2017 18:41:39 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v9IMfclF011869
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1508366500; bh=Q/BIO/YxN7By7yjHF0pDDeluAQc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=dWHLr+qF+lrvUXzIXgpmtCcKRO+NpddsoEPn+GSAUzodKIrT0n+mmAugECRRg9Gk/ tjtUQurYsKnulZTPHZRD33NQMMgByd1HUoUzKbppRtndOR1Ur5hf6LHrVmPRzsrSP/ Q1E289vqB03nRwKIPBeictrgNDT+CgEU1vnBxjaE=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v9IMfclF011869
Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd06.lss.emc.com (RSA Interceptor); Wed, 18 Oct 2017 18:41:19 -0400
Received: from MXHUB319.corp.emc.com (MXHUB319.corp.emc.com [10.146.3.97]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v9IMfWNc009947 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 18 Oct 2017 18:41:32 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB319.corp.emc.com ([10.146.3.97]) with mapi id 14.03.0352.000; Wed, 18 Oct 2017 18:41:31 -0400
To: Paul Wouters <paul@nohats.ca>, Denis Ovsienko <denis@ovsienko.info>
Thread-Topic: [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)
Thread-Index: AdNHnixK1MfUEHDyRxisjUupN4sYkQAgX+qAABDi+gAAALhmEA==
Date: Wed, 18 Oct 2017 22:41:31 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362FCE6B42@MX307CL04.corp.emc.com>
References: <CE03DB3D7B45C245BCA0D243277949362FCE3C59@MX307CL04.corp.emc.com> <15f2f161d4c.da16f6be41750.5454868954682835384@ovsienko.info> <alpine.LRH.2.21.1710181446400.15731@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1710181446400.15731@bofh.nohats.ca>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/NdBGvKyAN-eS0YG2xQItuf2OwgI>
Subject: Re: [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: Wed, 18 Oct 2017 22:41:47 -0000

> > BCP 201 a.k.a. RFC 7696 (Guidelines for Cryptographic Algorithm Agility and
> Selecting Mandatory-to-Implement Algorithms) Section 3.1 (Picking One True
> Cipher Suite Can Be Harmful) further justifies the need for more than one
> algorithm. The document also makes other relevant points.

Not exactly - section 3.3 (NB: not 3.1) is focused on why it's a bad idea to bake the One True Cipher Suite into a protocol design in a fashion that prevents the crypto from being changed.  tcpcrypt did not do that - the draft specifies multiple algorithms and creates an IANA registry for them, e.g., to enable others to be added in the future.

In contrast, the second paragraph in Section 3 of RFC 7696 appears to be a cogent summary of the concern:

   Ideally, two independent sets of mandatory-to-implement algorithms
   will be specified, allowing for a primary suite and a secondary
   suite.  This approach ensures that the secondary suite is widely
   deployed if a flaw is found in the primary one.

Thanks, --David

> -----Original Message-----
> From: Tcpinc [mailto:tcpinc-bounces@ietf.org] On Behalf Of Paul Wouters
> Sent: Wednesday, October 18, 2017 2:49 PM
> To: Denis Ovsienko <denis@ovsienko.info>
> Cc: tcpinc <tcpinc@ietf.org>; ietf@ietf.org
> Subject: Re: [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)
> 
> On Wed, 18 Oct 2017, Denis Ovsienko wrote:
> 
> > Let me suggest a couple documents.
> >
> > RFC 6709 (Design Considerations for Protocol Extensions) Section 4.5
> (Cryptographic Agility) recommends having two algorithms of "distinct
> lineage" for a few reasons it explains.
> >
> > BCP 201 a.k.a. RFC 7696 (Guidelines for Cryptographic Algorithm Agility and
> Selecting Mandatory-to-Implement Algorithms) Section 3.1 (Picking One True
> Cipher Suite Can Be Harmful) further justifies the need for more than one
> algorithm. The document also makes other relevant points.
> >
> > Even if draft-ietf-tcpinc-tcpcrypt has nothing to do with the problems
> reviewed there (which is not so as far as it seems to me and may seem to
> other readers), it would help to make references and specifically clarify how
> the choices relate with the points made in those guidelines.
> 
> 
> Let me suggest two other documents dealing with Mandatory To Implement
> for IKE and ESP/AH as well as another example on how to specify these:
> 
> https://tools.ietf.org/html/rfc8221
> 
> https://tools.ietf.org/html/rfc8247
> 
> Paul
> 
> _______________________________________________
> Tcpinc mailing list
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc

v2.23.0 | Report a Bug | By Email