[secdir] secdir review of draft-ietf-tls-rfc4492bis-14

"Scott G. Kelly" <scott@hyperthought.com> Thu, 09 March 2017 17:28 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958B3126D74 for <secdir@ietfa.amsl.com>; Thu, 9 Mar 2017 09:28:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable 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 oequKjKcx2yh for <secdir@ietfa.amsl.com>; Thu, 9 Mar 2017 09:28:55 -0800 (PST)
Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (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 4DF6C129595 for <secdir@ietf.org>; Thu, 9 Mar 2017 09:28:55 -0800 (PST)
Received: from smtp21.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id EF39225D32; Thu, 9 Mar 2017 12:28:51 -0500 (EST)
Received: from app40.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DE71F25D1E; Thu, 9 Mar 2017 12:28:51 -0500 (EST)
X-Sender-Id: scott@hyperthought.com
Received: from app40.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Thu, 09 Mar 2017 12:28:51 -0500
Received: from hyperthought.com (localhost [127.0.0.1]) by app40.wa-webapps.iad3a (Postfix) with ESMTP id CDC21602A8; Thu, 9 Mar 2017 12:28:51 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 9 Mar 2017 09:28:51 -0800 (PST)
Date: Thu, 09 Mar 2017 09:28:51 -0800
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-tls-rfc4492bis.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
X-Auth-ID: scott@hyperthought.com
Message-ID: <1489080531.840519743@apps.rackspace.com>
X-Mailer: webmail/12.7.10-RC
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Nmvh-NgXj2esZqIiSjKOGzhaf9Y>
Subject: [secdir] secdir review of draft-ietf-tls-rfc4492bis-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Mar 2017 17:28:56 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This review is roughly a week late, I hope it is still useful.

I think the abstract is quite clear:

   This document describes key exchange algorithms based on Elliptic
   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
   protocol.  In particular, it specifies the use of Ephemeral Elliptic
   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
   use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards
   Digital Signature Algorithm (EdDSA) as authentication mechanisms.

I currently have little expertise in ECC, so please view my comments accordingly. Security considerations are described throughout the document, and there is also a thorough security considerations section. Yoav and Simon are well known to the IETF security community, and have been actively involved in ECC-related security discussions in cfrg, so with the qualification that I am not expert in this area, I don't see any issues with this document.

--Scott