[secdir] Secdir review of draft-herzog-static-ecdh-05

Brian Weis <bew@cisco.com> Thu, 03 March 2011 06:38 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 2D4C73A6924; Wed, 2 Mar 2011 22:38:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3xVHoQvRPnAc; Wed, 2 Mar 2011 22:38:21 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com []) by core3.amsl.com (Postfix) with ESMTP id 6DC053A6892; Wed, 2 Mar 2011 22:38:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1909; q=dns/txt; s=iport; t=1299134369; x=1300343969; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=pkh2aZybHj2/guHm6i26gceFrISMPr9b2SydaXbfSw8=; b=Azf7mLuhdtp4dLOaPufhyo6vTSylunHd2Jto9gMw3VL2syasXTU1VTJR gcKyIFWvRrq5f2Tv35CyJ1yxF1C0NI9aWOdE4q7+zrH1H4CvLUef8DlDn fSzkvT7do4+G/EmVmXGJ7Y9S91XViv75xufbJSRXPNdrLWu/tVyE6LwwB Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAFLGbk2rR7H+/2dsb2JhbACmdXSiRJt8hWEEhRqHEg
X-IronPort-AV: E=Sophos;i="4.62,257,1297036800"; d="scan'208";a="268599513"
Received: from sj-core-2.cisco.com ([]) by sj-iport-4.cisco.com with ESMTP; 03 Mar 2011 06:39:28 +0000
Received: from stealth-10-32-244-211.cisco.com (stealth-10-32-244-211.cisco.com []) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p236dSDY016733; Thu, 3 Mar 2011 06:39:28 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 02 Mar 2011 22:39:28 -0800
Message-Id: <D858A225-D1D1-497D-BA40-A66D3F55AD57@cisco.com>
To: secdir@ietf.org, iesg@ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Cc: draft-herzog-static-ecdh@tools.ietf.org
Subject: [secdir] Secdir review of draft-herzog-static-ecdh-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 03 Mar 2011 06:38:22 -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 document defines how two CMS agents use static Diffie-Hellman values for Elliptic Curve Diffie-Hellman key agreement. It is well written. I have just a few comments.

1. The Abstract and Introduction use the term "static-static" Elliptic Curve Diffie-Hellman key-agreement, which is a term not in common use. I guessed correctly that it meant the case where both participants in the key agreement were using static DH values, but I think until the term is define (later on in the Introduction) it would be clearer to say something like "Elliptic Curve Diffie-Hellman key-agreement where both participants use static Diffie-Hellman values".

2. Reference [SEC1] is heavily referenced in this document, for both a definition of ECDH and specific methods for using ECDH. But it would be good to also mention RFC 6090, which is the best IETF document describing ECDH.

3. Generally, when two parties use static DH values over different exchanges they will use the same key for each exchange, which is generally not a good practice. I believe this is true for ECDH as well. Sections 2.2 and 2.3 mention "SharedInfo", which when used appropriately will permute the shared key such that the sessions are not keyed identically. But I believe the use of "SharedInfo" is optional, so I was expecting the Security Considerations to describe this scenario and at least say that "SharedInfo" SHOULD be used (or possibly MUST be used). It would be good to add this discussion to Security Considerations.