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)

Denis Ovsienko <denis@ovsienko.info> Wed, 18 October 2017 10:45 UTC

Return-Path: <denis@ovsienko.info>
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 AF10A1321B6; Wed, 18 Oct 2017 03:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.8
X-Spam-Level:
X-Spam-Status: No, score=-4.8 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_NONE=-0.0001, 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=ovsienko.info
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 8ZXhy1iUsXpD; Wed, 18 Oct 2017 03:45:05 -0700 (PDT)
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D225513330C; Wed, 18 Oct 2017 03:45:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1508323499; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=2220; bh=q7LChN0ZTqzaHC9jh89LgQM5yLOAUvC4mURF3enGJgg=; b=ZCNgH6Qv+yD13XrKllLwsjDdYaJxi6XRbCmyiGMrbsLBs/+bdtazYZrzOgJctMIo 1P+eGfIVewqz0wDCullF4A3wMZbIvxySVF1bUf9IkG6oQeKEnfXchsCQFhELemgStVq gItzlaM/0lvefpH9ozShjlD/E7XiW5niEsormjlI=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1508323499344831.0485449726434; Wed, 18 Oct 2017 03:44:59 -0700 (PDT)
Date: Wed, 18 Oct 2017 11:44:59 +0100
From: Denis Ovsienko <denis@ovsienko.info>
To: ietf@ietf.org
Cc: tcpinc <tcpinc@ietf.org>
Message-ID: <15f2f161d4c.da16f6be41750.5454868954682835384@ovsienko.info>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FCE3C59@MX307CL04.corp.emc.com>
References: <CE03DB3D7B45C245BCA0D243277949362FCE3C59@MX307CL04.corp.emc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/H8444P4mTYID6SO4ws8DTeAWMuw>
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 10:45:07 -0000

---- On Wed, 18 Oct 2017 00:18:05 +0100  Black<David.Black@dell.com> wrote ---- 
 > 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. 

Let make two points -- one editorial and one technical.

I tried to look for the norm concerned in Section 3.1 (Cryptographic algorithms) first, then searched the document for the words "mandatory" and "MTI" (which it does not contain) and eventually found the MUST at the end of Section 5 (Key agreement schemes). Having to hunt around to find that specific sentence didn't feel quite right.

 > 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 

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.

-- 
    Denis Ovsienko